はじめに

エンジニアとしてコードを書くようになって、もうすぐ２年というタイミングに差し掛かりました

心境の変化としては、がむしゃらに毎日のタスクを通して「動く」コードを書くことから、メンテナンスしやすいコードを意識することが多くなりました

「達人プログラマー」は、プログラマとして次のステップを踏み出そうというときにベストな一冊となっています

達人の哲学

ソフトウェアのエントロピーの話は心当たりがありすぎた

エントロピー とは、物理学の用語で「ある系における無秩序の度合い」のことで、 時間が経つたびにエントロピーは増大していく

ソフトウェアも同様に、時間が経つたびに無秩序になっていく

これを 割れ窓理論 というメカニズムで説明していたのもわかりやすかった

窓が１枚割れているのを長期間放置しておくと、それをメンテナンスする気力もなくなるマインドが 植え付けられて、最終的には建物全体が破壊されていく

ソフトウェアではこれを、悪い設計、誤った意思決定、質の悪いコードに見立てることができて、 放置しておくと潜在的なバグを生み出すことになりかねない

こういった「割れた窓」を発見したと同時に速やかに修復するべきだ、そして時間がなくてもコメントを 残すといった何らかのアクションをしてくださいと言った主張だった

茹でガエルの話は、ある程度精神的に余裕がないと気づくことが難しいと感じた

あっつあつの熱湯にカエルを放り込むとびっくりして飛び出してくるが、 常温の水にカエルを入れて段々と温度をあげていくと、カエルは気づかないまま茹で上がると言った話

要するに、いつもメタ認知を意識して行動しようということ

これは仕事に限らずしていきたい

達人のアプローチ

章前半のDRY 原則については膝を叩いて同意できるといった実感があった

また、曳光弾の考え方については目からウロコだった

複雑なシステムを構築していくときに、各機能を一つずつ作り込んでいくのではなく、各機能を最低限使えるようにするシンプルな箇所を探していくといった手法

シンプルな箇所に最初に取り組んでその他は後回しにする（未実装）というのは初心者視点では至らないと感じた

章後半のプロトタイプ、見積もりの話は現実でも問われることがあるものの、 実際に見積もりが大きく外れるような難しい設計をした経験がないということもあって実感が持てなかった

「言語の制約はそれを使う人の世界を制限する」 - ヴィトゲンシュタイン

毎回トピックの初めに、名言があってモチベーションが上がる

プログラミング言語に限らず、日常使っている日本語にも問題に対する考え方や コミュニケーションに対する考え方に影響を及ぼしているという構造主義的な話もあって興味深い

基本的なツール

「悩んでいる君、そしてその悩みの原因は他の誰でもない、君自身によるものだ」 ということを知るのはつらいものだ

- ソフォクレス

デバッグの最初の心構え → 「パニクるな」

妄想の達人

契約プログラミング(DbC) は素晴らしい

仕様を記述(契約)しておくことで、プログラマにバグになりかねないようなことをさせないプログラミングをする

トラッシュ（メチャクチャ）にするのではなく、クラッシュ（停止）させる

Go のif err != nilで毎回エラーチェックしてるのはこれに則っているのかなと思った。

確かにcatchで新しいエラーがくるたびに分類するのは怠い気もするかな、、

柳に雪折れなし

列車の衝突事故を例にして依存をわかりやすく説明している

１つのメソッドであまりにも多くのことをやろうとすると、 連結されている全ての車両に影響が及ぶように、メソッドと属性が影響を受ける

例)割引料金を算出するメソッドの中で、これらの操作を行う。

  • 顧客の注文履歴を参照する
  • 注文履歴から特定の注文オブジェクトを取得する
  • 注文オブジェクトの総額を返す
  • 総額から割引した値をオブジェクトにセットする

次のような考え方がある

照会せずに依頼する TDA(Tell, Don’t Ask)

つまり、取得した結果でオブジェクトを更新するのではなく、 メソッドに更新や参照を依頼する

デメテルの法則

  • プログラミングはコードについての話であるが、プログラムはデータについての話である

  • 継承は「結合」

継承の代わり以下のテクニックを使用する

  • インターフェースとプロトコル
  • 委譲
  • mixin と trait

ポリモーフィズムを表現するためにインターフェースを愛用する

設定をサービス API の背後に配置する

並行性

時間的な結合を破壊する

並行性を向上させるためにワークフローを分析する

並行処理を考えるときは時間のかかる手順を見つけることが大事

並行処理はソフトウェアのメカニズムであり、並列処理はハードウェアの関心事です　 ← 大事!!

共有状態は間違った状態　 ←泣

セマフォー とは、ある時点で誰か一人しか占有できない「なんらかのもの」

相互排他形式を説明するためのキーワード

アクターとプロセス

アクター とは局所的かつ固有の状態を保持した、独立した仮想プロセッサ

各アクターはメールボックスを備えている

メールボックスにメッセージが届くと、アクターが待機中の場合はメッセージ処理を始める

処理が完了すると、メールボックス内の別のメッセージを処理する

メールボックスが空だと、アクターは待機状態に戻る

メッセージを処理するときに、アクターは他アクターを生成したり、アクター同士でメッセージを送ったりする

次のメッセージを処理する時に遷移する新たな状態をつくることもできる

プロセス とは汎用プロセッサのことであり、並行処理を簡単にするために OS によって実装される

プロセスはアクターのように振る舞う制約が課されている

共有状態を持たないアクターを並行処理で使用する

アクターモデルでは明示的な並行処理が必要ない → 状態を保持しないため

コーディング段階

偶発的プログラミングを行わないこと

新人に対して、コードの詳細をできるか

→ 　できない場合は偶発的プログラミングに頼ってる可能性あり

仮定をドキュメント化する。

他メンバーとのコミュニケーションを効率化したり、心の中にある仮定を明確にする

→ 　契約による設計(DbC)が参考になる

過去のしがらみにとらわれてはいけない。 既存のコードによって未来のコードが影響されないようにする

自分の行った作業が次に行う作業の制約になってはいけない ←大事!!

アルゴリズムのオーダーを見積もること

ソフトウェアは「建築」ではなく「ガーデニング」に近い ←大事!!

リファクタリングはごくたまにしか実行しない特別かつ高尚な儀式的アクティビティ ではない

雑草抜きや落ち葉をかき集めるようなリスクの低い、ちょっとした作業を 日々実施するアクティビティである。

テストとはバグを見つけることではない

テストの利点は、テストについて考え、テストを記述しているときにあり、 テストを実行しているときではない

→ テストを契約と見做せば重要度とモチベーションの変化になるのではないか

象を一頭食べるにはどうすれば良いか

→ 一口ずつ食べる ←大事!!

明確な目的地を心に描けてなかった場合、どのような方法論であっても 堂々巡りになってしまう可能性がある。 ←泣

プロジェクトを始める前に

ひとりぼっちでコーディングに取り組んではいけない

達人のプロジェクト

猫の群れを飼い慣らすことに匹敵するほど、優秀なプログラマーをまとめるのは難しい

50 人はチームとは言わずに「群れ」といった方がしっくりくる

事を成し遂げるにはまずスケジュールする

カーゴカルト的な手法は、開発においてもテストやツールにおいても危険

ユーザーが必要としたタイミングで調達すること

早めにテスト、何度もテスト、自動でテスト

まとめ

このタイミングで１周できたのは幸運でした。

折に触れてて再読したいと思います。

備考

表紙イラスト：Loose Drawing