過去に自分の書いた設計書やコードって破いて捨てたくなるときってありませんか？
私は大いにあります。
多分他の皆さんも幾度と無く経験していることだろうと思います。
そんな私たちに対してか、@ITでキミのコードが汚い理由という記事がありました。
内容としては、リファクタリングやAgile系の本に書かれていることと大差無いのですが、ここで紹介したいと思います。
?
まず、題名からなんとなく分かってしまうのですが--最終的にはコードを綺麗に書く為にはどうすればいいかというのを説明する為に--コードが汚い理由（問題点と背景）が書かれています。
まず、汚い理由として三点
- 時間のプレッシャー
- 勉強不足
- 熱意（周囲のコードに対する熱意のこと）
（非常にありふれた三点（；´Д`A ```。）
次に、コードを汚くしないための対策が三点
- クリーンなコードを書くことを自分のプロセスに取り入れる
- クリーンなコードの書き方を教える
- クリーンなコードを評価する（周囲に評価されるようにする）
?
記事の最初の方に、著者が汚いとしているコードAと綺麗だとしているコードBがある。見た目的に良いコードはBであるが、現在問題として現場で受け入れられるコードはAであると思う。何故か？それはITの現場にはピンからキリまでいるからである。
サッカーを例に取ってみると、バルセロナや少し前のレアルのサッカーは非常に素晴らしい。ただ、同じことを日本代表にやらせようとしたらどうなるだろうか？JFLの選手などに至ってはどんなことになるであろうか？当然不可能である。個々の能力に差があるからである。高い戦術には高い個々の能力が必要とされるのである。正確なトラップ、正確なボールコントロール、正確なポジショニングが要求される。
では、ITの現場はどうだろうか？ITの現場では先ほども言ったとおり、ピンからキリ、バルセロナ級から二部三部級の能力の人が同じプロジェクトに集まり、一緒に仕事をしているのである。レベルを能力の高いの人に合わせてしまうと、能力の低い人が仕事をできなくなってしまうので、レベルは低めに設定することになる。当然受け入れられるコードの質も低下し、最終的には綺麗なコードBよりも汚いコードAの方が現場に多く蔓延る事になる。
?
著者としては、こういう現状を打破すべく--全体のボトムアップを目的とし--プロセスの改善を行うと共にコードの書き方を教えることの重要性、そしてそれらのモチベーションを維持するためにも周囲の理解の必要性を説いているのだと思う。
?
ということで、まずは勉強勉強！ｗ
?
P.S. 記事のコードB。if分の条件判定の順番間違ってるよね。記事の本質とは関係ないけど。