達人プログラマー 第2版はいいぞ
名著中の名著である達人プログラマーの第2版が2020年11月に出版されました。
原著であるThe Pragmatic Programmerは、1999年の出版で、第2版（英語版）の出版が2019年なので20年ぶりの改定ということになります。
この書籍にある個人的に響いたTipsと、ちょっとした感想をこの記事に書いていますので、書籍購入の参考になれば幸いです。
個人的に響いたTips8選
本書にはありがたいTipsがたくさんありますが、その中でも自分に特に響いたTips8つを紹介します。
割れた窓を放置しない
環境犯罪学の理論で有名な「割れ窓理論」はエンジニアリングの世界でも
当てはめることができるようです。
この書籍では悪い設計や質の低いコードを「割れ窓」とみなし、
それを放置することはクリーンなシステムの崩壊を加速させると言及しています。
これに関しては自分の心のなかで「割れ窓」が種となって、言い訳へ成長するときがあるので非常に響きました。
変化の触媒たれ
ポルトガルの「石のスープ」という民話をもとに、自分が変化の触媒（現状を変化させるためにチームメンバーを導く存在）になるための方法をざっくり示しています。
その方法というのは、変化によって得られるメリットを提示してチームメンバーを変化の輪に入れましょうということです。
組織やシステムを変化させる際に、コトがうまく進まない場合もあるので少し参考になりました。（といっても人間そんな単純かな～？と疑問もある）
良い設計は悪い設計よりも変更しやすい
このTips周辺ではETC（Easier To Change）原則というものを用いることで、将来発生するであろう変更に耐えるコードを書くことができるとしています。
結合を最小化するのも責務を単一化するのも、命名にこだわるのも、全てはETC（変更しやすくする）原則のためだということです。
別のTipsに
最終決定などというものは存在しない
とあるように、不変的なコードは存在しないので、ETC原則は重要なのです。
自分も「変更容易性」は非常に大切だと思っています。なので、このように改めて重要性が書籍上で明記されるのは良いことだなと思います。
Don't Repeat Yourself（繰り返しを避けること）
DRYの原則は非常に有名です。
同じコードを繰り返し書いてはいけないということですが、加えてこの書籍では「同じコードでも表現している知識が違う場合は、繰り返し書いても良い」と補足しています。
目からウロコでした。よく同じようなコードを見ると共通化するべきか悩みます。
共通化した部分は複数のコンポーネントから参照されるので、変更しづらくなるためです。
しかし表現している知識が同じもののみ共通化することで、変更の影響を局所化できるのではないかと推測できます。
契約を用いて設計を行うこと
契約（制約）をコンポーネントに定義することでコンポーネントのコードをシンプルなものにでき、
コンポーネントに定められた処理を確実に行えるということが示されています。
この契約というのは
コンポーネントを呼び出す側がコンポーネントを呼び出すための事前条件（引数の値の制限など）を満たさない場合は、コンポーネントを呼び出すことは許されず、
逆に事前条件を満たしてコンポーネントが呼び出された場合は、コンポーネントは正しく値を返さなければなりらないというものです。
このような契約を定義することで、コンポーネント内部で考慮すべき問題が減るので、コンポーネント自身のコードをシンプルに保つことができると気づきました。
ちなみに制約を満たさずにコンポーネントが呼ばれた場合はコンポーネントは例外を出すなどしても良いようです。
爬虫類脳に耳を傾ける
「そもそも爬虫類脳って何？」ということですが、ググれば出てくるので各自調べてください。
要は「本能に耳を傾けろ」ということです。
コーディングや設計中に理由もわからず作業のモチベーションが低下することがあります。
これは本能が今の作業に間違いがあることを訴えているから起こる現象だそうです。
そういったときは一度問題から少し距離を置いて、まっさらな環境で問題を解決するためのプロトタイプを作ったりしてみると、直面していたぼんやりとした不安が鮮明に浮き上がることがあるよ！と書かれています。
確かにモチベーションが上がらないときは、ノートに雑なフロー図を書いたりモックを作ったりするとモチベーションを取り戻すことがあります。
なのでこのTipsには非常に共感できました。
ポリシーはメタデータである
一見要求に見えるものでもポリシー（方針）とするほうが適当な場合は、メタデータ（設定ファイルやマスタテーブル）の更新によって挙動を変更できるようにすべきであるとのことです。
本書上にある例を引用すると
上司と人事部門だけがその従業員の記録にアクセスできる
こちらは要求のように見えますが、
権限のあるユーザーだけが従業員記録にアクセスできる
このように言い換えるとポリシーになります。
この見極めは非常に難しいですが、要求を要求として思考停止で受け入れてはいけないという気づきを得ました。
要求も別のもっと適切な文章に置き換えるとポリシーになり得るようです。
流行を追いかけるのではなく、効き目があるものごとを実行すること
ここでは流行しているものが自分のチームにおいて有効であるかは
コンテキスト（文脈）によると記されています。
そして有効かどうかを知るためには、実際にそのものごとを試してみることが重要だとしています。
最新情報を取得するべくネットで情報収集をしていると、多くの技術や手法の流行り廃りを目の当たりにします。こういったことに流されそうになることがありますが、やはり流されずにPDCAを回して吟味すべきだと再認識しました。
読みきった感想
この書籍は実務経験1年以上の方から、中堅エンジニアに刺さる書籍だと思いました。
学生だとなかなかピンと来ないような内容も多いので学生にはオススメしにくいです。
本書は初心者から脱した人が気づけないような知識がたくさん詰まっているので、非常に有用な書籍だと思いました。
中堅エンジニアの方は本書に書いてある内容で、知っているけど実践できていないことを見つけることができるはずですし、忘れたいたことを思い出すことができるという面で読む価値があります。
個人的には曖昧な知識を改めて定義するという意味で本書は非常に有益でした。そして、自分と本書の達人プログラマーたる人物像を比較して憂鬱になりました・・・ｗｗ
というわけで第1版をお持ちで無い方は読んでみてください！
ちなみに
自分の勤務先で「達人プログラマー 第2版」のダイジェスト読書会をやるので、
もう読んだよ！という方は是非ご参加ください：）
Discussion
繰り返しについてはコンテキストが違えば再利用するメリットは小さくなるとプログラマが知るべき97のことの「共有は慎重に」でも言われていました。