サンプルコードを漁りながらとりあえず動くコードは書けるけれど、複数人開発を前提とした保守性や拡張性、可読性などがあるコードをどう書けばいいんだろうと迷っていた時に、これはすごい・・・と思える本に出会いました。

上田勲さんの「プリンシプルオブプログラミング」です。

関連書籍にCODE COMPLETE、達人プログラマー、97のことシリーズ、リーダブルコード、アジャイル奥義など名著がこれでもかと並んでいますが、原著を見ても難しすぎて頭に入ってこないです。。　「プリンシプルオブプログラミング」ではそれら原著もうまくチョップして、再構成してくれているので読みやすい。

そういう意味でこの本は初級プログラマのためのベストアルバムだと思いました。ベストアルバムをまず聞いてから、それぞれのオリジナルアルバムを聞いていく感じで、入門編としてこの本は最適ではないでしょうか。

章立てに合わせて、学んだことを全7記事に分けて書いていきたいと思います。

〜前提編〜　（いまここ）
〜原則編〜
〜思想編〜
〜視点編〜
〜習慣編〜
〜手法編〜
〜法則編〜

前提とは普遍的な事実であり、受け入れなければいけないことである

この本がすごいと思ったのは、章立てが綺麗に体系立っており、毎日Web記事を読んだり、メンバーから教えてもらったりして学んだことが整理されるような感覚があったことです。

第1章は「前提」ですが、前提が一番重要なので、それを受け入れてくださいと言われます。さて、どんな前提があるのでしょうか。

銀の弾丸はない

1つの手法やツールでどんな状況でも解決できる銀の弾丸はない、ということは普段の開発メンバー間での会話でもありましたが、なぜ銀の弾丸がないのか考えたことがありませんでした。

その理由は、ソフトウェアが本質的に困難性を持っているからとのこと。困難性として4つ挙げられています。

1. 複雑性：ソフトウェアは大きくて複雑
2. 同調性：ソフトウェアは複雑な実世界と同調しながら使用される
3. 可変性：ユーザーがソフトウェアを使うとさらなる要求を思いつく
4. 不可視性：ソフトウェアから見ることができないプロセス等が存在する

まずは困難性が高いことを受け入れる必要がありそうです。

プログラミングは設計行為である

弊社にはディレクターやプランナーがいません。会社やサービスの規模もあるかもしれませんが、5年近く会社としてソフトウェア開発をしてきて分かったのは、職種を下手に増やすとろくなことにならないということです。こんな機能が欲しいとか、こんな挙動で、という話はプログラマでなくても定義できますが、実際に開発してみると初めて気づくことが多いので結局要件定義から戻ったりします。

となると、元々の要件で何を満たしたかったのか、どんな価値をユーザーに提供したかったのかをチームメンバー全員が同夢じゃないと、結局何がしたいのかよく分からないものができあがります。それだったら、プログラマが中心になって最初の要件定義から行った方がクオリティが高いものができるので、このやり方が気に入っています。

プログラミングは創造的な行為であること。仕様作成からコードを書き終えるまでの過程が相互に依存し不可分な作業であるため、1人のプログラマの権限を広げるのがうまいやり方であること。コードが設計なら、なるべく早めにコードを書き始めるべきことなどが、この本には書かれています。

コードは変更される、よって読みやすく変更に強いコードを書く

これは経験値の問題もあるかもしれませんが、機能を開発していて後から、こことここはコードが重複しているから関数にしようと気づいて、かなりの量書いたコードを削除することがあります。

シンプルに書けるようになればそれでいいはずなのですが、あれだけ時間かけて書いたのに若干もったいないなあという気持ちになる。。

それについては、コードは無常であるということが書かれていて、なるほどですねとなりました。

ユーザーやビジネス上の要望により、ソフトウェアを変えていかないといけないことから、固執するべきではないし、コードは書いている時間よりも読んでいる（読み直す）時間の方が長いのだから、書くのに時間がかかっても読む時間が短縮できるなら元が取れる、という視点が勉強になりました。

具体的に変更に強いコード、読みやすいコードとは何か、という話は次回以降に出てきます。