達人プログラマーとは
はじめに エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました
心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました
「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています
達人の哲学 ソフトウェアのエントロピーの話は心当たりがありすぎた
エントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく
ソフトウェアも同様に、時間が経つたびに無秩序になっていく
これを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった
窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく
ソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない
こういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった
茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた
あっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話
要するに、いつもメタ認知を意識して行動しようということ
これは仕事に限らずしていきたい
達人のアプローチ 章前半のDRY 原則については膝を叩いて同意できるといった実感があった
また、曳光弾の考え方については目からウロコだった
複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法
シンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた
章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった
「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン
毎回トピックの初めに、名言があってモチベーションが上がる
プログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い
基本的なツール 「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ
- ソフォクレス
デバッグの最初の心構え → 「パニクるな」
妄想の達人 契約プログラミング(DbC) は素晴らしい
仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする
トラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる
Go のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。
確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、
柳に雪折れなし 列車の衝突事故を例にして依存をわかりやすく説明している
１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける
例)割引料金を算出するメソッドの中で、これらの操作を行う。
顧客の注文履歴を参照する 注文履歴から特定の注文オブジェクトを取得する 注文オブジェクトの総額を返す 総額から割引した値をオブジェクトにセットする 次のような考え方がある
照会せずに依頼する TDA(Tell, Don’t Ask)
