クソコードあれこれ

箇条書き部分に記載しているが、

生産性が低い

安心して変更/拡張できず、身動きが取れない

変更した場合の影響箇所が未知数/膨大

課題に対して手段が適切でない

シンプルな解決方法が存在するのに対して複雑な、奇想天外な対応をしている

出川イングリッシュの例え、言い得て妙

何をやっているのかはわかるが、なぜそうしているのかが分からない

コード見ればわかることがそのままコメントやコミットメッセージに書いてあるのに、肝心の理由/意図が書いていないというのはよくある

コピペコードの散乱

本質的に違うものだから許されるコピペもある

これについては、クソコードの中では軽症だと思っている

仕様を正しく反映していない(と思われる)にもかかわらず、「コードが仕様」になっている

クソコードはなぜ生まれるのか

個人プロダクトでもない限り、コードを書いた個人の責任ではない。レビュー体制、タスク分割、役職、労働条件や待遇も含めた組織設計自体が問題

クソコードを責めることは個人を責めることにはならない

が、個人が責められるように感じてしまう人が多いので配慮をする必要がある

レビューで止められるのに止められなかった人、体制も悪い

その人に割り振られたタスクは本当に適切か？

能力、量、得意/不得意、役職等を考慮して最適を目指したか？

期待した成果が本当に妥当か？

その成果を求めて然るべきと言えるような報酬、もしくは成果に応じて報酬を適切に挙げる評価制度がないのであれば成果を上げるインセンティブがない

あるいは成果が上がらなければクビになる、減給されるという負のインセンティブもあるが、日本だと厳しい

安い人材を拾ってきて高い成果を要求し、実現しなかったら文句を言うのは正直子どものわがままレベルのないものねだりだと思う

クソコードをどう解決するべきか

テストがクソになる場合もあることも考慮すべきだが、ないよりマシは常に成立する

報酬を上げる/高い人材を用意する

クソコードが擁護されるとき

間違ってはいないと思うが、クソコードについて批判するときの場面/論点は大体、今までであったクソコードを話題にして茶化す/クソコードの生産を予防する/既存のクソコードへの対応策を考える、等だと思うが、これらの論点について話しているときに上記の擁護をしたところで論点ずらしとしか思えない