Code Craft エクセレントなコードを書くための実践的手法

Code

Code Craft ~エクセレントなコードを書くための実践的技法~
ちょっとしたところからAmazonギフト券をもらったので、前から買ってみようと思いつつも、値段がそれなりだったので躊躇していた一品。
そのなかで、自戒の意味も込めて気になった言葉。


感想としては、こういう内容が書籍になるということは、洋の東西を問わずよくある問題なんだということ。



「コンピュータプログラムにとって最良のドキュメントは明快な構造(Kernighan Plaugher)」



「プログラムの質をただ1つの基準で判断する場合、最も有効な基準は可読性です。読みやすいプログラムは、おそらく良いプログラムであり、読みにくいプログラムは、おそらく良くないプログラムです(Kernighan Plaugher)」



「適切な命名を実現する鍵は、その対象を正確に理解することにある。対象を理解して初めて、意味のある名前を付けることができる。適切な名前を思い付かない場合は、自分は何に名前を付けようとしているのかを本当には理解しておらず、その対象物の存在理由さえ知らないのではないかと自問すべきである。」



「ときには、対象を適切に表す名前を見つけるのが困難なこともあります。優れた名前が思い浮かばないときは、場合によっては設計の変更が必要かもしれません。名前を付けにくいということは、何かが間違っていることを示す兆候である可能性があるのです。」



「意味のある関数名を付ける上でもう1つ重要なことは、「be」「do」「perform」を名前に含めないようにすることです。これは、動詞を含む名前を付けなければならないという意識の強い初心者が陥りがちな典型的な落とし穴です。これらの単語は、いわば雑音のようなものなので、それを付け加えても名前の価値が高まることはありません。」



「外部ドキュメントの支えを必要とするコードを書いてはならない。そのようなコードは内容が薄くて弱いコードである。コード自体を読めばその内容が明確に理解でるようなコードを書くことを常に心掛ける。」



「コードに詳細なコメントを記述するいうもう1つの一般的な方法も、外部ドキュメントに頼るよりもさらにひどいとは言えないものの、やはり望ましくないことにかわりはありません。卑屈に思えるほどに詳細に記された大量のコメントは、優れたコードの実現を妨げるものです。コメントを細かく付けすぎると、結果的には、優れたプログラムどころか、不体裁で読みにくいドキュメントを書いたのと同じことになってしまうでしょう。」



「確かに、適切なコメントを記述することは重要な手法ですが、自己解説的コードはそれだけで実現できるほど単純なものではありません。それどころか、本当は、コメントを必要としない明瞭なコードを書くことによって、コメントの使用を積極的に避けるべきなのです。」



「他の方法ではコードの明確性を高めることが不可能な場合のみにコメントを追加する。」



「コメントは、どれほど重要なものであっても、その説明の対象であるコード自体を上回る意味を持つことはありません。コメントを使用しても、駄目なコードを優れたコードに変えることはできないのです。理想としては、コメントを全く必要としない自己解説的コードを目指すべきです。」



「テストはデバッグではない。これらを混同しないこと。両者は要求される技能が異なる、どんな時にテストを行ない、どんな時にデバッグを行うのか、きちんと認識るる必要がある。」



「ソフトウェアを設計するには2つの方法がある。1つは欠陥のないことが見てすぐわかるように単純に設計すること。もう1つは目に見える欠陥がないように複雑に設計すること。前者は後者よりずっと難しい」



「個々のモジュールは、その役割を明確に定義されなければならず、無関係な機能を何でもかんでも詰め込んだ福袋のようなものであってはなりません（たとえば、Utilsといったまるで無意味な共通名前空間のようなものがよく作られるのはなぜでしょうか？）」



「経験と技能の裏付けがあって初めてよい設計ができます。結局、優れた設計者とは、優れた設計を作り出す人を意味します。二流のプログラマーが卓越した設計を生み出すことはありません。」



「企業世界では、経営側が一時しのぎの解決を期待するのはよくあることです。5トンのコンクリートブロックを脆い旗竿のてっぺんに貼り付けたら、それほど長く立っていないことをマネージャに説明するのは、まあ簡単です。その下に彼を立たせるのは、それよりも大変です。そして話題がソフトウェアとなると、同じメッセージを理解させるのはもっとずっと大変です。マネージャはまず納得しないでしょう。彼らにとって、プログラマーは不可思議な魔法をかけ、限りない力を発揮する魔法使いのようなものです、何をするかを命令し、最終期限を決めて、後は待つだけであり、コーディングのために何日も徹夜しなければならないなどとは関知しないのです。」



「チームに合わせてコードを作成するのではなく、作成するコードに合わせてチームを編成する。」



「また、作業ができるだけシンプルになるように、チーム間にまたがるコミュニケーションはできるだけ少なくすること。この段階で、成功の可能性ができるだけ高まるようにチームを設計するには、煩雑でお役所的な無駄な手続きを排除しておくことである」