下記のような記事

プログラミング中級者に読んでほしい良いコードを書くための20箇条

をずいぶん昔に書いたのですが、未だにかなりのアクセスがあるみたいです。今考えるとタイトルもなんか恥ずかしくて当時の自分何考えてんだよ、って感じですが、アクセスがある以上何かメンテナンスしなければならないと思ってきました。実際読み返してみると、かなり世の中のトレンドも変わってきて現在ではあまり良くない記述も増えてきたのでアップデートしようと思いこの記事を書きました。

また、自分自身も経験を積み、考え方が変わってきたのでそのフォローもしたいと思います。

全般

オブジェクト指向が前提になっていますが、オブジェクト指向は常に最良の手法では無く、場合によっては（というかかなり多くのシーンで）関数型プログラミングのスタイルを選択したほうがより良いコードが書けます。

前述の記事は「可読性の高い説明的なコードを書く」ということに重きを置いて記したつもりですが、関数型プログラミングは「説明的なコード」をかなり書きやすいと思います。

6. 便利な言語機能を使う について

具体的な例としてLINQやリスト内包表記やラムダ式を挙げています。それに加え、モナドやコレクション／コンテナ操作系の高階関数、Future/Promiseなどといった多くの言語（ライブラリ）で採用されている仕組みも積極的に利用したほうが良いと思います。

11. なるべくテスト可能なコードを書く

これはもうすこし強い表現で書いたほうが良いかと思いました。

まずテストコードを書いてCIツールでプロジェクトを回していくのが普通のやり方で、プロジェクトの納期や予算、性格などを考え、CIツールの利用が適当ではないと判断した場合のみテストコードは書かない、というのが良いのではないのでしょうか。

なぜそう思ったのかというと、私のこれまでの経験も含めて改めて思い返すと、テストコードを書かない、CIツールも使わないというプロジェクトは大体ダメだったからです。複数人が長期的に開発を続けるのならばプロジェクトの予算がどうとか言うのではなくて、「テストコードを書いてCIを回していくための予算がつかなければプロジェクトはいずれダメになる」という前提に立って資金繰りをする時点からそのコストを織り込むよう政治的な調整をする、という程度の気合を入れないとダメだと思います。

CIが不要なケースというのは、たとえば1度しか使わない簡易的なプログラムを書くとか、作ったら最後メンテしないのが決定しているシステムを作るとか（たとえば正式版システムが出来るまでのつなぎのシステムをとりあえず作るといった場合など）、ビジネス戦略的な理由でどうしても短期的な品質を犠牲にしてでも早期にリリースしないといけない場合などが考えられます。

17. コメントアウトしない について

これはタイトルが良くなくて、正しくは「構成管理ツールがやるべきところは構成管理ツールに任せる」とすべきでした。

さらに追加すると、構成管理ツールはなるべくGitを利用したほうがいいと思います。なぜSubversionではダメかというと、単にGitの方が高機能で綺麗な変更履歴を作れるからです。経験上、Subversionでは複数人が並行して新機能を作ったりバグ修正を作ったり複数のリリースバージョンを作ったりし始めるとどこかで限界がやってきます。GitはSubversionに比べれば学習コストが高いのですが、それを支払って余りあるメリットがあるので頑張ってメンバーに覚えさせましょう。

20. オブジェクト指向設計する

これに関連して、21. 関数型プログラミングをするを付け加えたいです。

当時、これは正しくオブジェクト指向設計してほしいと書きました。その思いは今も変わってないですし、オブジェクト指向設計自体が古くなって代替されるべき方法論だ、と思っているわけではありません。正しいオブジェクト指向設計が活きる場面というのは沢山あると思いますが、同じかそれ以上に関数型プログラミングが活きる場面が沢山あります。

「平凡なプログラマにとっての関数型プログラミング」という記事でも書いたのですが、プログラマやSEの本当の仕事というのは「世の中の問題をソフトウェアの力で解決」することであり、プログラミングとは「世の中の問題を数学の問題¹に書き直してあげること」なんです。そのためには、現実の問題をより美しく数学の問題に落とし込むための方法をたくさん知っているべきです。なぜならばたくさんの方法を知っていれば最適な方法を選べるからです（余りにもマイナーでトリッキーな方法や言語はもちろん除きます）。

以上です。

なんかずいぶん昔に書いたので、さぞかし恥ずかしい事書いてるんだなーと思って読み返したら、そこまで変でもなかった（当社比）のでちょっと安心しました。