コード品質のビジネス影響度
2022年の下記論文の解説
コードの品質が低いとバグが増える
低品質なコードに含まれる欠陥は、高品質なコードの15倍
バグ修正という計画に組み込まれていないタスクが増える
見積より遅れ、計画通りにリリースできなくなる
開発時間のばらつきが大きくなり、予測可能性が下がる
低品質なコードの平均開発時間は、高品質なコードの2倍
低品質なコードの最大開発時間は、高品質なコードの9倍
金のことを考えるようになってきて、この辺の難しさがわかってきたmrsekut.icon
売上のことだけを考えると、どうしても技術的改善に時間を割くのが後回しになってしまう
長期的投資の意味合いが強い
リファクタしまくったところで、直接的に売上に繋がらない
直接的に金を生み出すのではなく、
時間を生み出したり、やることを減らす、という立ち位置
攻めというより守り
分散している手間を、最初に時間をかけて仕組み作りをする、という感じのものが多い リリースのたびに手動テストをするのが手間→1度だけ時間をかけてテストコードを書く
そこを修正するたびにバグってムズい→1度だけ時間をかけてリファクタする
そのかかった時間と、将来的にかかるはずだった時間の比較をする必要がある
もちろん、そこで作った仕組み自体のメンテコストも考えないといけない
例えば、テストコード自体のメンテ
これは金を生み出すプロダクトコードとは別の立ち位置にある
将来的に、新規追加・修正する際の速度に大きな影響をもたらす
コード品質の改善の有用性を根拠を持って説明するのが難しい
コード品質の定量化、実装速度、バグの多さ、などの計測や分析が必要になる
ただ、小さい会社でそこまでするか？という感じもする
やったときとやってないときを比べられない
ほら、やってよかったでしょ、というのを示すのが難しい
他者への説得も難しいし、そういう目線で見たときの自身での納得も難しい
ざっくりでも、数字で判断できるようにする
正確ではないものの、勘でやるよりはマシ
他の人とのコミュニケーション材料にもなる
ざっくり時間で分析する
もっと良い方法はあると思うmrsekut.icon
なんか本質をヒットしている感じがしない
定量的に調査する
Gitのcommitから作業時間を計測するとか、そういうデータを収集して定量的に調査する
正確性は増すかもしれないが、これ自体に時間がかかる
新機能を追加する際に、AとBに同じ修正を入れる必要があるとすると、
新機能追加の工数に、その両方が乗っかってしまう
そうすると、そんなに時間がかかるならやる必要はないか、という判断がされてしまう
そこで、まず先に、AとBに同じ修正を入れるという状況をなくするための仕組みを導入する
そうすることで、先ほどの新規の追加の工数自体が減る
リファクタなどの改修は、今後の改修に対して広範囲に小さく影響を与える
https://gyazo.com/90d50723c48b2d191c03af3b75ba7bac https://speakerdeck.com/orgachem/what-is-software-engineer-in-test-and-how-they-works?slide=27
かなり視覚的に伝わりやすいのでは