プログラマは敵ではなく、身内に殺される

プログラマの辛さはプログラミングが難しいことではない。

劣悪なコードを書くプログラマが沢山いて、彼らがそれを劣悪だと感じておらず、また、それを劣悪だと評価出来る人間もほとんどいない事こそが辛さの極みだ。

ゴミを出す人間がゴミを出していることを自覚しておらず、ゴミが出されていることを認識できる人もいないということだ。

まっとうな人ほど辛いのがプログラミングの世界。

劣悪なコードには２タイプ有る。

１．知識と技術が共に欠如しているいわゆるクソコード

本人ですら、何を書いているのかわかっていない、なんとなく動いているコード。とにかく無駄なコードが多く、整頓もされていない。大抵の場合潜在的なバグを含んでいるので、機能追加や改修の際にその潜在的バグが炸裂したりする。知識が無いために先回りができず拡張性に乏しく、要素が１つなら動作するが２つ以上になる事が全く想定されていないといった、自由度の低い場当たり的なコードが頻出する。

２．知識だけつけて使い方を間違っているコード

本人は何をしているのか理解して書いていたが、知識だけが先歩きして奇っ怪なコードになっている。間違った、あるいは過剰な抽象化がなされることが多い。モデルは永続化データにアクセスするためものとして実装された結果、モデルが呼ばれた段階でトランザクションを開始したりする。結果、ビジネスロジックの行き場所がなくなってコントローラーに詰め込まれることになるのは使い方を間違っている好例。同様に、ビューはモデルを参照してはならない、ビューにはロジックを書いてはいけないというのも間違い。もしそれが正しいならそれはただのテンプレートである。

なぜビューがテンプレートではだめかというと、分業ができなくなるから。テンプレート内で複雑な分岐を行うとデザインを行う非エンジニアがさわれなくなってしまう。これらのために、やはりコントローラーにロジックが書かれる結果になる。分業のためにもテンプレートは必要であり、使うテンプレートを選別したり表示のためのロジックを書く場所としてのビューという立ち位置が必要になる。

モデルクラス毎にそれぞれのDTOクラスを作成してセッター・ゲッターを作りクラス呼び出しのたびに新しいDTOオブジェクトを作ってバケツリレーする、あるいは、DAOのような過剰な抽象化を行ってSQLをビジネスロジックから遠ざけ、コードの可読性を損なわせるのはJava使いのようだ。 コードを書いた時点で少なくとも本人は理解しているが、その複雑怪奇さから半年後には誰も容易に理解できなくなる。

この２タイプは技術力こそ子供と大人ほど違うが、害悪であるという点ではどちらも凶悪だ。

彼らは自分が技術的負債を作り出していることに全く気づいていないし、周りの誰も、それに気づかない。マトモなコードを書いている者だけがそれをゴミと認識して掃除にあたっている。