[Booklog] ベタープログラマ(O'Reilly)

[備忘のためのメモ]

ch3_少ないコードを書く

※コメントを書くときに意識すること

•コード自身は、何をどのようにしてを説明しているため、コメントでは「なぜ」を説明すること、しかし何故を説明する際にコードがかつて行っていたことを記載しないようにすること。

ch10_バグ狩り

※問題解決を速やかに行う為に

•素早く、バグを特定する為にはバイナリチョップを行う、具体的にはコードのパスをひとつづつ実行するのではなく、事象の連鎖のはじめと終わりから始める。それから問題空間を二分して、中間点が良い状態か悪い状態かを調べる。それを繰り返して二分探索的に問題を特定する。（よくない打ち手としては1ステップずつ実行すること）

ch13_二つのシステムの物語

※優れた構成を産むために

• コードを書き始める前に、意図して事前の設計を行うこと。多くのプロジェクトは、実際に開発する前にこの点で失敗し、そこには対立する緊張がある。設計が足りなさすぎず、その上過剰設計でないこと。

• 開発を進めながら、設計を明瞭に維持し続けること。

• ソフトウェアの全体設計の責任が与えられて、責任を持つチームであること。

• 設計を変更することを恐れないこと。永久に変わらないものは無し。

• チームにふさわしい人々を入れること。そこには設計者、プログラマ、マネージャが含まれる。開発チームを適切な大きさにすること。彼らが健全な関係になるようにする。彼らの関係が必然的にコードの構造へ反映される。

• 設計上の決定を、決定するためのすべての情報を分かっている適切な時期に行う。まだ行えない設計に関する決定を遅らせること。

ch24_学びを愛して生きる

※スキル獲得のドレイファスモデルを読んで要点の抽出

• 初級者
経験が学習を導く、規則を破って独自のやり方を試すが、うまくいかなくなると行き詰まってしまう。関係のない詳細を省くことができない。

• 中級者
全体像を持つことで、未知な問題に対処したり、問題に対する方法論的な筋道を計画できる。新たな規則の限界も把握し始める。

• 上級者
全体像の深い理解、自らの経験からだけでなく他人の経験から学び、理解して吸収できる。問題に対するデザインパターンを持っている。

• 専門家
専門家は理解を極めた結果、直感を持っているので、規則を必要とせずに答えが自然にわかる。

ch31_一生懸命でなく、賢く

※新たな作業が依頼されたら

• 今実際に必要とされているのが、なんであるかを調べること。初期の段階でTooMuchにやることを積み上げるのはやめること。

パレートの法則
https://blog.kairosmarketing.net/marketing-strategy/how-to-leverage-pareto-law-into-marketing-activities/