巨大プロジェクトの「コード品質」は案外悪くない

いや、僕が見てきたところがそうだっただけなのかもしれないけど…

理想的なコードを10とするとまあ大体5くらいには収まるんじゃないか…え？低すぎ？

まともに動かないコード、というのはよっぽどのアレで、その実装の仕方はさすがにどうかと…と思うのはたまにあるけど、うーん僕ならこう書かないし時間があったら書き直させるけど動作としては問題ないなーというのが大半です。
そりゃこんなコード書いてたらテストの効率も落ちるし大変だろとは思いますけど、それでも大半の問題は詳細設計段階できちんと仕様が取り込まれていないことから生じます。設計がちゃんと出来ていて実装で躓くのって業務システムにおいては仕組みを担う共通部分が中心（それも経験値不足が主な原因）だったりしますよね。もっとも、近年では画面系システムでJavaScriptの取り扱いがわからなくて糞コードが量産されている気がします…あれ、タイトルウソっぽい…

あと…他社のチームのコードを覗いてみたらクソコードだったことが…何度も…

いずれにしても、巨大プロジェクトで問題が多発することに「コード品質そのもの」が起因しているというのはそんなにないような気がしています。とにかくまともな設計さえされていれば巨大でもなんとかなるんじゃないかと思っていますが、巨大であることは設計が難しいということとイコールなのでそこが難しい。もっと言うと、過去のコードは問題が多い（デッドロジックが整理されていなかったり、「念のため」もう使わない仕様が残っていたり）のでそこから仕様をひねり出したらクソになりますね。

銀行みたいなところだと特に単体レベルで完全にテストを通すので本当の問題が出るのは結合テスト以降ですよね。

設計のクソさ加減にも種類があって、特に複数システムを連結する場合の全体のアーキテクチャ設計がダメまたは不完全のまま各システムが設計スタートするような場合は致命的ですし、各システムにおいては実装のアーキテクチャを意識しない基本設計をしてしまうクソSEが全てをダメにすることがありますね。そして実装者が犠牲になります…

基本設計・詳細設計というレベルでシステムが実現したいことの意図を十分に把握した人のレビューがなされれば問題が起きないことも多いですが、往々にしてそういう人がちゃんと実装テクノロジーを理解していないことから悲劇が生まれることが多いですね。