理系でお願いします
この記事の内容は理解できます。しかし、ぐだぐだな IT（というかコンピュータシステム開発）の現場には圧倒的に理系（というより工学かな）的な発想が欠落していると思います。
とにかくシステマテックではない。理にかなっていない。
「設計」という名の決め事で走り始め、「規約」という名の束縛のもとに造り、「試験」という名の泥沼にはまる。
「仕様書」と「設計書」を混同している現場があるのがそもそもいけないのか、「設計する」とは言っても「仕様する」とは言わないように、仕様は決め事ですが、設計は方法論に基づいて「すること」なのです。
「コーディング規約」などに代表される「規約」ももちろん一種の「縛り」ではあります。縛りはできればないほうが楽です。なければないほうがいい。なのになぜあるのか？ これをちゃんと考えていないところも多いですね。たいていはこういう返事が返ってきます。
「コーディング規約がなければぐちゃぐちゃなコードになる」
「人によって違うコードになる」
この程度の意識ならないほうがいいですよ。工数を増やすだけです。ここでいう工数はコーディングの工数だけではありません。もっと長い目で見た工数も含みます。
結局、これらの低意識のコーディング規約を作成する現場の根底にあるのは「コーディング規約の充実によってソースコードレビューの手間を少しでも減らしたい」ということです。これがアマい。読みづらく、メンテナンス性の低いソースコードというのは、人から言われたいくつかの言葉で直るようなものではありません。逆にベテランは、規約によって縛らなくても素晴らしく読みやすいコードを書きます（求められれば）。
私の考えるコーディング規約の意義は以下のとおりです。
- ケアレスミスによるバグや、非効率的なコードを書かないようにするための示唆（なので狭義には規約ではないですね）
- さぼりの抑制
- protected、public の Javadoc は書きましょう。
- 管理性の向上
- 看板の書き方（コピーライトなど）
これを念頭にできるだけ「軽く」作ります。変なコードを抑制するのはあくまでソースコードレビューです。
常になぜ、どうして、今もそうなのか、これからもそうなのか。そういう発想がなければ、いい開発なんてできないと思うんですよね。
