★★★☆☆

 

文章を書くノウハウ本は多数ありますが、プログラムを書くノウハウ本もいくつか出版されています。本書は比較的新しく、かつ定番となる本だそうですので前々から興味がありました。

プログラムの抽象的な大構造やデザインパターンと言ったマクロな話には立ち入らず、変数の命名規則といったミクロな範囲～関数・テスト設計と言った中程度の規模の話に集中して、「どうやったら他人が読んで理解できるコードを書けるか」「パッと見て意味が分かるか」というテクニックと思想を詰め込んだ本です。

命名規則には特にうるさく、「tmpという単純な名前はやめなさい、抽象的すぎるから」「getMean()のような関数は、getという名前で軽い処理を行うと解されやすいから、重い処理を詰め込むのはやめよ」などなど、日常業務に即適応できそうな内容ばかりです。

ただし後半になってくると、職業プログラマーをやっていると当然のようにぶちあたる課題と解決方法の繰り返しになるので、自分としては得るものが少なかったのが残念です。ここのところ本業が佳境に入って時間が取れないにもかかわらず、ものすごく早く読み終わってしまいました。逆に考えると、日常の業務の遂行方法が本書出版時の2012年現在でもだいたい有効であるということですので、うれしいです。

また、翻訳のクセが私には鼻について全然合わない（Amazonではみんな褒めてますけど）のと、巻末の解説が冗長すぎて「読みやすい」を目指すはずの本書の趣旨と合ってない、最終章のサンプルコードが無駄に複雑でここだけ難易度が跳ね上がっていて初級者には絶対読めないのとで、★-1としました。

 

プログラム本を読んでいていつも思うことがあります。発達障害者はプログラマーに向いている、ビルゲイツもアスペだったとよく言われます。私は嘘だと思います。私の書くコードはきたないです。なかなか一発で本書のような綺麗なコードは書けません。なぜなら良いコードは「他人が読んでわかりやすい」コードであり、それは文章や会話と原則的に何も変わらないからです。私は自分にしか意味の分からないようなコードを大量に生産しています。これはコミュ障と同じです。

さらに現代で優れているとされるプログラム手法は「オブジェクト化」「疎結合」ですがこれも、高度な抽象化が必要になる作業です。私は実はこれ、すっげぇ苦手です。どうしても直接的でベタ打ちのコードを書いてしまいます。同じ機能をまとめて抽象化して、より高次の問題だけを取り扱うのが現代プログラミングの基本ですが、全然できません。経験を積むほど自分がプログラミングに向いてないのが分かります。

だからプログラミングが得意な人間とは本当は、コミュニケーション能力があって空気が読め、何でもすぐに抽象化して上位概念を操るのが上手い人間なんだろうなぁと思うのです。たぶん私とは正反対に位置する人間ですこれ。

 

 

 

 

参考書籍

分厚い類書です。これもいつか必ず読みたいと思っている本です

 

正直言って会社で書いてるコードはきたないものばかりなので、リファクタリングも学ばないとなりません。

 

巻末に紹介がありました。気になるけど、すごく。。やばそうな本です