『達人プログラマー第2版』読書メモ

2021/1/28
達人プログラマー第2版を読みました（3/53セクション

p7 技術的負債が返済されることはありません、無秩序に広がっていきます
p8 割れた窓、誤った意思決定をそのままにしてはいけません
p9 放置は他のどのような要因よりも腐敗、負債を加速させるのです
p9 管理上の貧弱な決定はあらゆる崩壊の始まり

2021/1/29
達人プログラマー第2版を読みました（4/53セクション

p11 変化の触媒となり相乗効果を得て全員が勝ち組となるか、それとも...
p12 許可を得るより許しを乞うほうが簡単である
p13 悪い方向にいかないように、周囲の変化を感じ取り、大きな視点でものを見る

達人プログラマー第2版を読みました（5/53セクション

p14 完全なバグのないソフトウェアでなく、十分に良いソフトウェアを書けば生産的でユーザーもハッピーになれる
p14 十分に良いかどうかユーザーにも判断させる
p15 システムのスコープと品質はシステム要求の一部として議論せよ
p16 洗練させすぎても台無しになる、完璧なものなんてない、やめ時を知るべし
p17 使わない多くの機能によってバグや脆弱性があり機能追加しづらいソフトウェア

達人プログラマー第2版を読みました（6/53セクション

p17 知識と経験はプロフェッショナルな日々を支える資産、ただし有効期限つき
p18 金融投資と同じ：分散投資、定期的な投資、再分配が重要
p20 知的資源獲得のために：毎年言語を学習する、月に1冊技術書を読む、技術書以外を読む、チーム外・社外のコミュニティとかかわる、最先端を知る
p23 批判的に分析する：5回の「なぜ？」、誰にメリットがあるか、コンテキストは？、なぜこれが問題なのか？

達人プログラマー第2版を読みました（7/53セクション

p26 素晴らしいアイデアも洗練されたコードも他人に伝達できなければ究極の不毛
p26 日本語をもうひとつのプログラミング言語と考える
p27 聞き手の要求、優先度、好みなどを理解し、こちらの言いたいことを理解してもらう戦略を用意しておく
p30 相手の立場になり、自身も聞き手になる
p30 達人プログラマーはドキュメントを開発プロセス全体とは切り離せない重要なパーツと考える
p31 ドキュメントはコード自体に記述する

達人プログラマー第2版を読みました（9/53セクション

p36 あらゆる設計原則はEasier To Change原則を特殊化したもの：ETC（変更しやすい）はルールではなく価値であり、意思決定を助けてくれる
p40 DRY原則は知識や意図の二重化についてであり、ソースコードの二重化だけにとどまらない
p48 開発者間で発生する二重化は検知が難しい、活発かつ頻繁なコミュニケーションが解決には不可欠

達人プログラマー第2版を読みました（10/53セクション

p49 直交性原則を適用すると品質が向上する
p50 コンピューティングの分野では、ある種の独立性、結合度の低さを指す：片方を変更しても他方に影響を与えない
p51 凝集度が高いコンポーネント＝自己完結した、独立した、単機能の、目的にうまく適合したコンポーネント
p51 直交性の高さ＝生産性向上（開発期間、テスト期間の短縮、組み合わせにより多くの機能を得られる）、リスク低減
p54 統制できない属性に頼ってはいけない：例、顧客の識別に電話番号を使うな
p55 コードを書くたびに直交性を低下させるリスクがある：他のモジュールと重複した機能、同じ知識を複数箇所に作り込む
p56 解決策1：コードの結合度を最小化する
p56 解決策2：グローバル変数を避ける
p57 解決策3：類似機能を避ける
p58 DRY原則はシステム内の二重化を最小限に抑えるのが目的：直交性はコンポーネント間の依存関係を最小限に抑えるのが目的

p371 良い結合のことを凝集という

達人プログラマー第2版を読みました（11/53セクション

「11. 可逆性」
p60 何かを実装する場合、常に方法はいくつもある
p61 「方法はひとつしかない」という近視眼的なプロジェクトは、予想もしない過酷な変更が待っているかも
p61 重大な決定は簡単には元に戻せない：やり直しには多大な出費が伴う
p62 本書の重要なテーマ「柔軟で適合性の高いソフトウェアを生み出すには？」DRY、分離、外部設定などにより、後戻りが許されない重大な意思決定から解放される
p62 不慮の出来事が発生した際の準備を怠ってはいけない：決定は変更されうる
p63 コードだけでなく、アーキテクチャ、デプロイ、ベンダー連携も柔軟性を維持すべき：アーキテクチャへの追従を準備することはできないが、変更を容易にしておくことは可能。流行を追い求めすぎない。

達人プログラマー第2版を読みました（12/53セクション

「12. 曳光弾（えいこうだん）」
p65 曳光弾：弾底のリンが発火し、銃口から着弾までの弾道を光の筋で描く。リアルタイムのフィードバックが得られる。
p65 同じ原則がプロジェクトにも適用できる、今まで開発したことないものを開発する際に有効。
p66 システム開発の要求の段階で、システムの最終形態となるイメージを迅速かつ目に見える形で、何度も提示できるものを探し出す必要がある
p66 最初の曳光弾は「プロジェクトを作成しhello worldを追加しコンパイルして実行する」
p67 次に、アーキテクチャレイヤをまとめて統合して実行できるようなシンプルな機能を実装する（UI/認証/業務ロジック/データモデル/DBなど）
p68 曳光弾で得られたフィードバックを元に肉付けしていく：曳光弾は使い捨てではない。インクリメンタルなアプローチ。
p69 曳光弾型開発のメリット：早いうちからユーザーにものを提示できる、開発者の活躍できる舞台を生み出せる、テスト用のプラットフォームを入手できる、デモ可能なものを手にできる、進捗が明確になる
p70 全て捨て去るプロトタイピングとは曳光弾は異なる
p71 曳光弾はアプリケーション全体の連携を知るため、ユーザーにインターフェースを提示するため、開発者にアーキテクチャの骨格を提示するため。