ちょっと古い記事だけど。それっぽいようにとっても論理的じゃなく書かれてておもろい。
論理はクソだなという姿勢ですね。大事。
ということじゃない。
ここに書かれてることの問題は、バグ数/KLって指標を使ってることじゃ全然なくて、
指標値と閾値を間違ってつかってること
っすね。
なんで指標自体が悪にされてるのかな。
>プログラムの可読性を向上させようとするとステップ数が増えることは当たり前のようにあります
ぬーん。一般的にライン数多いと可読性落ちると思うんだよな。
適切に改行入れましょ、とかメソッド化しましょ、とかそういうレベルの規模増の話？
ある程度コードの基準に則ってるのはプロの世界では当たり前のことなんだよな。あたしコーディング規約大嫌いだけど。
その上での可読性って、もはや設計的な話になると思うけど、大概ライン数の削減にも寄与すると思うんだな。
適切に改行することや、変数名ちゃんとつけよう、とかを否定するものではないよ。超大事。
そのことと規模増は関係ないよ、って意味ね。マクロで見たら全然関係ない。
>プログラムの拡張性を向上させようとするとステップ数が増えることは当たり前のようにあります。
これも、ちゃんとやれば実現対象のスコープにも恩恵あるから、多くの場合ライン数下がると思うんだけどな。
百歩譲って、妄想レベルの要件に対する拡張性を求めてオーバースペックなものを作って規模あげちゃったとしたら、おっきくなっちゃうのもまあわかるけど。
#嫌味ですね、それが要求されるのはもはや機能要件ですね
だとしても、そうした作り込みにもバグを埋め込む可能性は同様にあるんでないの？ と思う。
拡張性を上げると、可読性を上げるとバグを作り込まずにプログラムを書ける？
すげーな。
バグ密度指標ってのは、人が人だから、組めば組むほどバグを作り込んじゃうよね、っていうこと以上のものではないのよね。
それが、それなりに大きな規模の開発ならば、経験則としてこんなもんだよね、ってのはあるよね、ってだけなの。
FWによって、ツールによって、要件によって、難易度によって、メンバーによって、体制によって、期間によって、日によって、言語によって、気分によって、体調によって作り込みバグ数が変わるのは当たり前で、
それをどのように評価するか、っていう評価軸が指標値なんですよ。
だから一定なんすよ。
言語ごととか、カテゴリ単位にいくつかあってもいいんだけどね。
指標意味ないって言ってるのは、人によって身長は違うから、違うスケールの物差しで測るべき、って言ってるのと同じ。
そうじゃなくて、指標に対して、何がどう違っているのか、その要因は何か、って考えるためにあるのが指標なんですね。
大きな開発でマクロ的な品質分析をしたことないとかなのかな。
スケールが小さいほど、指標に対する変動が多くなって扱いにくくなってしまうからね。
対象が大きいほど、定量分析は有効。
そういう批判ならわかるかな。
とはいえ、閾値ではないんで、そういう評価になるだけだけどな。
対象規模に自動生成含むってのは論外。頭悪い。閾値と履き違えてるからそういうことするんですね。
そういう意味で、指標信仰やカバレッジ信仰＝ゲッタセッタのテストコードね、それは悪ですね。
そこはそう思う。
ただ、品質管理ってのは一定であること、という立場も全く分からないではないので、一分の理も無い、ということもないと思うけど。
マネージメントの立場としては、工数かけてやることじゃないよ、だな。
