http://creativecommons.org/licenses/by-nd/4.0/
著: あんざいゆき(@yanzm)
アプリのクラッシュやフリーズが多くなるなどの軽いものから、見えてはいけない情報が見えてしまう(ユーザー自身でしか見えないデータが他のユーザーからも見えてしまう)ような情報漏洩に至る重大な問題など、さまざまなインシデントが発生する確率が上昇します。インシデントがセキュリティに関係するものだった場合、社会的信用を失ったり損害賠償等具体的な損失が発生する可能性があります。
うまくオーガナイズされていないコードでは、どこに何が書いてあるのか、どんな処理が行われるのか、どこまで影響範囲があるのかを開発者が正確に把握することが難しく、予期せぬバグを埋め込む可能性が高くなります。
我々の注意力には限界があります。レビュワーを増やせば防げるものではありません。開発スピードがその分落ちたとしても許容できる体制(評価に影響しないようになっているなど)ですか?
他人の書いたコードについて、どこに何が書いてあるのか、どんな処理が行われるのか、どこまで影響範囲があるのかを調べるのは、本来時間のかかるタスクです。
よくオーガナイズされているコードでは、設計やアーキテクチャ、クラスや処理の名前などがこれらのタスクの助けとなります。
しかしそうでないコードでは、処理を実装した本人だけがうまく内容を把握している、という状況になっていることがよくあります。この場合その人がチームから抜けると、開発スピードが急激に落ちることになります。
競合や新興勢力が提供している新しい機能を自社アプリにも取り入れたいとなった場合、実装に著しく時間がかかったり、そもそも実装不可能になったりします。
優秀な開発者は常に良いコードを書きたいと思っているし、良いコードと仕事をしたいと思っています。既存の実装に組み込むために不本意なワークアラウンドコードを書いたり、既存のコードが綺麗であれば負うことのなかった苦労に直面することはとてもストレスがかかることです。
開発者は横の繋がりが強く、退職情報などから結果として採用が厳しくなることがありえます。
「コードの良し悪しの区別がついて改善の方針が立てられる開発者」が在職している間に手を打たなければ、そもそもコードの改善自体できなくなるでしょう。
開発者の教育において、業務で関係する既存コードが学習コンテンツになるのがもっとも効率がよいです。しかし既存コードが見本とならない場合、別の教育コンテンツを用意するコスト、既存コードを真似しないように指導するコスト、既存コードを真似されてしまった場合の対応コストなど、さまざまなコストがかかってきます。
適切なコードベースとなるよう投資しましょう。