きれいなソースコードを書くために読んでおくべき本10冊

なんか、プログラマとして必要な本をあげるのが流行っているようなので、自分も書いておこう。きれいなソースコードを書くために読んでおくべき本10冊。
最初はリファクタリング

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

以上。終了。10冊じゃないか(^^;
きれいなソースコードを書きたければ、一にも二にもリファクタリング、それしかない。


後は、良いソースコードを読みながら自分でも、実際にプロダクトを作ってみること。OSSとして公開すると、自然と良いコードを書こうというモチベーションが上がるのでオススメ。


読んで欲しいと思うソースコードは、JUnitのソースコードとテスト。JUnitのダウンロードサイトに行くと下の方にあるzipのやつがそうです。
﹁きれいな﹂というのは、かなり主観的なものなので、きれいなソースコードというものを客観的に言うのは実は難しいんだけど、﹁きれいなソースコード﹂というのを﹁テストしやすいソースコード﹂といいかえることで、客観的に話ができるようになると思います。


﹁きれいなソースコード﹂=﹁テストしやすいソースコード﹂に、違和感を持つ人もいるかも知れないけど、自分の経験上これはかなりの確率で当てはまります。
なぜかというと、テストしやすいコードというのは、モジュール同士は、疎結合であることがほとんどです。密結合だとテストしにくくなるから。
疎結合なコードは、必要なコードは一箇所に集まりやすくなるので、読みやすくなるのです。疎結合かつ高凝集ってことですね。


だから、ソースコードを読むときには、テストコードも一緒に読んでほしい。テストしやすくなることが、きれいなソースコードにつながることを実感して欲しい。それには、JUnitのソースコードとテストを読むのが一番です。


本を読むことも重要だけど、たくさんソースコードを読んで、テストしやすくすることを意識しながらたくさんソースコードを書いたほうが、きれいなソースコードがかけるようになるということです。


実は、自分は、kisのところに書いてある本は一冊も読んだことがありません(^^;
2010-11-25 2010-11-26 まぁ、プログラマとして実力をつけることときれいなソースコードがかけるようになることはイコールじゃないけどね。


勘違いしてほしくないのは、本を読むことが重要ではないということではないことです。
本を読むことも重要だけど、たくさんソースコードを読んで、テストしやすくすることを意識しながらたくさんソースコードを書いたほうが、きれいなソースコードがかけるようになるということです。


自分の書いているソースコードはこんな感じですね。
http://code.google.com/p/slim3/source/browse#svn/trunk/slim3/src/main/java/org/slim3/datastore


きれいなソースコードをかけるようになるためにデザインパターンも知ってたほうがいいんじゃないのという人もいると思いますが、デザインパターンはきちんと学んだ上で、いったん軽く忘れたほうがいい。
軽く忘れるというのは、コードを書いているときに、そういえば、このパターンはデザインパターンのあれに似てるなぁと思い出せるくらいに忘れるということです。思い出せたらそれは使うようにしましょう。
デザインパターンが常に頭に常駐している状態でコード書くと、無駄に複雑になっちゃうんだよね。
デザインパターンは、ある程度複雑な問題をきれいに解くために考えれたものですが、もともと簡単なものに適用すると無駄に複雑になってしまうためです。


たくさんソースコードを読んで、テストしやすくすることを意識しながらたくさんソースコードを書くと、きれいなソースコードがかけるようになります。


大事なことなので三回言いました(^^;