達人プログラマー 第2版 熟達に向けたあなたの旅

アンドリュー・ハント(著者), デイビット・トーマス(著者), 村上雅章(訳者)

• 販売会社／発売会社: オーム社
• 発売年月日: 2020/11/21
• JAN: 9784274226298

商品レビュー

2025/11/12

良質なエンジニアを定義し、見極める事ができる本。全てを完璧に実践する事は不可能だが、年に1回は読み返し達人プログラマーを志していきたい。チームで議論する時等に今のアクションをユーモアと共に言語化できる気がする。

「調べたこと」
- 無秩序 （ムチツジョ）：物事が整理されておらず、乱雑で、統制が取れていない様子

「メモ」
- 「割れた窓」：悪い設計、誤った意思決定、質の悪いコード。ネガティブな考えは伝染性がある様。
- 「早起きした鳥は虫にありつける」：早く行動を起こす人ほど、仕事や勉強などで有利になる
- 迷惑（annoy）：アンニュイ、つまり退屈
- DRY原則：知識や意図の二重化についての原則。異なった場所に同じことを表現するという問題を避けるための原則。

2025/11/12

開発者たるものさまざまなTipsが散りばめられている。色々な設計技術書などの重複があり、振り返りもできた気がする。しかし、和訳故の分かりずらい例が多々あり、そこは日本人向けに変えて欲しいところ。

2025/05/06

プログラマ向けの自己啓発本。昔から、本のタイトルは聞いたことがあって気になってはいたのだけど、ようやく読んだ。
もっと早くこの本を手にしておけば、もうちょっとマシな開発ができてきたのだろうなと思う。
DRY原則がこの本で誕生したというのは聞いたことあったけど、ラバーダック・デバッグもこの本からだったのか。

割れ窓理論とかまさにそうだよね。自分もつい、割れた窓のようなコードを書いてしまったことがあり、その後に若いプログラマに保守を任せることがあったのけどいい書き方になってなかったりした。
それをコードレビューしても、元がよくない書き方なので指摘するのに躊躇したり。

ETC原則という言葉は初めて知った。「Easier To Change」の略で、変更をしやすくするという意味らしい。この考え方は、確かに大事だよなと思う。
初めて知ったと書いたけど、この言葉は第２版で作られた原則だろうと思う。検索しても、第２版が発売してからの記事しか見つからなかった。

DRY原則は、自分もコードの重複をしないようにするという意味だと数年前まで勘違いしてしまっていた。そうじゃないんだよね。
コードの重複をしないようにと考えてコードを書いてしまったせいで、かなり煩雑なコードになってしまったので、本当に悔やまれる。

知識はプレインテキストに保存するというのは、AIでコーディングしてもらうこともある今には特に重要だろうなと思う。ついつい、Excelで書いてしまったりするけど、プレイテキストのほうが検索もしやすいしね。
今後はもっとMarkdownで文章を書くようにしていきたい。Mermaidとかも、書けるようになりたい。

JavaScriptにパイプライン演算子(|>)を追加するという議論が進んでいるという話は初めて知った。
ただ、この本が発売されて５年たつけど、いまだ議論中らしい。結局、追加されないような気もする。

継承の代わりに、「インターフェースとプロトコル」「委譲」「mixinとtrait」を使うほうがいいとのこと。ついつい継承は便利だから使ってしまいがちだけど、確かに結合度があがってしまうしね。気を付けたい。

テストコードについて、著者の一人は今は書いてないというコラムが面白かった。テストコードを書き続けた結果、テストコードを書かなくても、テストコードが書きやすいコードを書けるようになったからということらしい。
そろばんに慣れたら、なくても計算できるようになったみたいなイメージに近いのかも(少し違うか？)。

後、「ココナツでは解決できない」という話も面白かった。飛行機を見ても、ココナツで同じものは作れないという話なのだけど、確かにそれはあるよなと。
この本でいいたいのは、他の企業でやっているやり方を見様見真似で行ってもうまくいかないということだと思うのだけど、既存のソフトウェアと同じようなソフトウェアを作ろうとする時にもあてはまるよなと思った。
仕様が分からない、説明者があるわけでもない、別会社が作ったプログラムを真似して、プログラムを作ることになったことがあるのだけど、どういう概念で作られているのか全く分からず、かなり苦労した思い出。まあ、今となっては要件定義自体をもっとちゃんとすべきだったとは思うのだけど。