まとめ記事続きです。
個々のエッセイはクリエイティブ・コモンズでライセンスされています。
19.誰にとっての「利便性」か
優れたAPIを設計するのは難しく、原則を意識していたとしても適切なAPIができるとは限らない。
設計時、本当に使う側にとって「便利」かどうかを考えなければならない。
整合性とボキャブラリーを兼ね備えたAPIを作成できるのが理想。
複数処理を1つのメソッドにまとめられたら便利だと思っていても、それはしないほうが賢明である。
22.1万時間の訓練
「エキスパート」と呼ばれるようになるには、1万時間の、入念に計画された、集中的な訓練を実施する必要がある。
集中的訓練では、自分の現在の能力を少し超える課題を挑戦→分析→修正の繰り返しで反復訓練すべき。
得意なことに取り組むのではなく、まだ得意でないことに取り組む。楽しいとは限らない。
24.変更を恐れない
システムの構造自体に問題があるようなプロジェクトは、いわば「病気にかかっている」状態。
変更・改良を怖がっていてはプロジェクトの容態は悪くなるばかり。
時間や労力はかかるが、投資は何倍もの利益として返って来るばかりではなく、
プロジェクトのメンバーが「システムは本来どうあるべきか」について学び、改良できる知識を身につけられる。
システムの改良では、内部I/Fの再定義、モジュールの再構築、コピペしたコードのリファクタリングなどをするとよい。
改良はゆっくり少しづつ加えていき、改良の都度テストをする。
こうして、システムの「健康」への留意は常に怠らないようにすること。
26.言語だけでなく文化も学ぶ
プログラミング言語には、文法、構文だけではなく、文化がある。
どのような言語でも、一定の書き方に統一できるが、真に言語を理解するには文化も理解する必要がある。
言語の文化を理解することにより、他の言語に応用でき、コードの質が上がる。
新たな言語を学べば、従来から使っていた言語でも、より美しいコードが書けるようになることが多い。
35.超人の神話
いくら超人でも、人間は人間である。
経験から来る勘や知識があっても、現状の状況などが分からなければ答えられない。
人に質問する際には、(相手がどんなに優れた人であっても)何が障害になって物事が進まないのか、
具体的に示すこと。