今まで10以上のプロジェクトを転々としてきて、さまざまなシステムのソースコードを見てきました。綺麗ですっきりとしたコードがあったり、どうしてそんな実装になった？と思わず目を疑ってしまうような汚いコードもあったりしました。
そんな経験を重ねていくうちに、ソースコードの汚さにはなんとなく傾向があるのが見えてきました。その傾向をここでまとめてみました。
品質重視のシステム
基幹系やインフラ系が相当します。設計書などのドキュメントが充実しており、かつソースコードは設計書の準拠度合いが強いです。なので、設計書がダメダメだとソースコードもダメダメになりがちです。効果的なコードはいらない、ただ設計書に則ることが正義の世界です。
どの会社に製造を任せようか？
品質重視のシステムは自ずと開発規模が大きく、複数の会社が関わっていることが多いです。そして、製造に関わる会社の担当領域によってコードの汚さの傾向が違ってきます。担当領域が機能別か工程別かで傾向が大きく違うように思います。
担当領域が機能別（共通化面倒くさい）
A社にX機能を、B社にY機能を担当といったやり方です。A社、B社それぞれが担当する機能の設計からテストまでを行います。発注元が取りまとめないと、各々が独自のコードを書き出します。もし、発注元が取りまとめられないと、共通化した方が保守性上がるのにっていうコードが散在することになります。
例えば、AとBという画面があって、AとBはほとんど同じUIを持った画面だとします。それを一次請け会社がAの画面はA社に、Bの画面はB社に発注するものがだから、UIは同じでも、ソースコードの実装が大きく異なったりします。その結果、保守工数が大きくなるといういたたまれない結果になります。
担当領域が工程別（コミュニケーション面倒くさい）
設計はA社、製造はB社というような役割分担です。会社が違うため、設計者と製造者とのコミュニケーションが億劫です。そのため、設計者の設計がダメダメであった場合でも、その指摘が面倒くさいので、B社はその設計を我慢して素直にコーディングします。
また、開発者は設計曖昧な箇所があったとしても、それを設計者に確認せず「それっぽく」動くようにつくり込む傾向があります。特にプロジェクトが燃えているときはそうなりがちです。製造も余裕がないので、設計曖昧な箇所は結合テストで気づいてね、という問題先送りのスタンスです。そして指摘されて急いで直して、結果コードが汚くなったりします。
Web・モバイル系
ECサイトやモバイルアプリなどが該当します。一般消費者がメインターゲットということもあり、見た目や納期重視の開発だったりします。また、機能拡張やバージョンアップが頻繁に行われるので、ウォータフォールよりもアジャイル寄りな開発が主流だと思います。
絆創膏を貼るような修正
納期重視ということもあって、本当はコア部分を修正した方が良いのに、小手先技で対応する修正が多かったりします。例えばMVCモデルのシステムで、コントローラで正しいデータ処理をさせた方が良いのに、ビューで処理させようとします。このような修正を「絆創膏を貼るような修正」と揶揄していました。
細かい仕様は開発者に任せた
顧客は最低限の要件さえ守ってくれれば良いようなスタンスが多いと思います。要件定義書がきっちりとしていないため、一次受け、二次受けがここはこうだろう！で細部を作り出します。そのためか、少し複雑な機能は顧客が仕様を把握しておらず、開発者に仕様を聞きにきたりします。
たいていはOKですが、受け入れNGとなるものも少なからずあります。そして、修正インパクトが大きくなるものは悲劇になります。とりあえずリリースを間に合わせようと「絆創膏を貼るような修正」を行います。
データベースの専門家がいない
データベースに詳しい人が少ない傾向にあると思います。初期構築ではDB専門家が設計に携わっていることが多いですが、機能追加の場合は開発者任せなことが多いと思います。
データはアプリ側で加工しよう
データはアプリ側で加工する思想が蔓延していたりします。例えば、テーブルAとテーブルBがあって、それらを結合したデータが欲しい時、JOIN句を用いたSQLで取得するのではなく、テーブルAとテーブルBのデータを別々に取得してビジネスロジックでそれらを結合する処理になっていたりします。こうして、データ加工ロジックが肥大化していきます。
データベース設計がざる
データベースに詳しくない開発者がテーブルやカラムを新規追加する場合、とって付けたような設計となりがちです。例えばXXフラグとか、意味の似たようなカラムとかがいっぱい出来がちです。マスタデータなのに数十万レコードあるデータを見た時は驚愕でした。
研究支援系
新技術が使えそうだから市場に投入したい。新技術をパッケージ化したり、プロトタイプを作成したり、何かしらの形で利用できるようにするプロジェクトがこの系統に入ります。研究に必要なデータを集めたり、ちょっとしたツールを作成したりといった研究支援活動も含みます。
苦労する点のひとつとして、オリジナルのソースコードを読み解くことが挙げられるかと思います。研究者がトライアンドエラーで作成したようなコードを読み解かなければなりません。ソースコードは、情報工学に詳しい研究者と、情報工学に詳しくない研究者の二系統で傾向が違うように思いました。
情報工学に詳しい研究者（ギーク）
とてもハッキングなコード
メモリとかスレッドとか、そのあたりを考慮してコーディングされているため、外側から見るとメモリの使用率や処理性能などがやたらと良い傾向にあります。けれど、その性能を実現するためのコードは複雑な傾向にあり、ぱっと見で「なんぞこれっ？」と思うことが多々あります。（でも、勉強になります）
短いコード大好き
保守性よりも「いかにコードを短く書くか」に重点がおかれているような傾向があります。そのためか、三項演算子がよく登場したり、ブラケットとか改行なしのif文とかが所々にあったりします。
妥協しないぜ
研究者のプライドといいますか、少しでも性能の悪いコードは性能を良くしようとします。それはもう妥協しないレベルです。例えば、たかだか100件くらいしかないと分かっているデータ群の中から1件探すというサブルーチンを二分探索のアルゴリズムで書いたりします。
まとめ
システムごとに違う「ソースコードの汚さ」の傾向をまとめました。汚いコードがなくなることはないので、せめて傾向を掴んでしっかりとした対策を練ろう。
