読んだ:達人プログラマー(第2版)

達人プログラマーの第2版を読み終わったのでほぼ個人的な備忘録も兼ねて何が書いてあったかざっくりと。

目次

オーム社の書籍情報ページに書いてあるので割愛。

第1章 達人の哲学

  • 自らの行動に責任を持つこと。欠点は素直に認めること。
  • エントロピーは増大するもの。割れ窓は作らない・放置しない。
  • 変化に対して敏感になること。大局を見失わない。
  • 完璧なソフトウェアは存在しない。どこかで落としどころを見つける。
  • ポートフォリオの更新を怠らないために、定期的な投資を続ける。

技術的な部分というよりはプログラマがどうあるべきかというのを書いた章ですね。
来年はちょっと気になっているElixirを何かテーマを見つけて触ってみたい。

第2章 達人のアプローチ

  • よい設計で作れば変更が容易。
  • DRYは意味で考える。コードの重複があることが直ちにDRYに反するということではない。また、DRYはコード以外にも適用する。
  • 直行性を意識する。モジュール間その他依存関係はできる限り排除する。
  • 曳光弾開発とプロトタイピングは明確に使い分ける。プロトタイピングで作ったコードを本番に投入しない。
  • 見積は根拠を用意する。そのために要求に対してモデル等の作成を行う。また、規模に応じて回答する見積単位(day, week, month)は変える。

技術的な話題に入っていきます。
DRYは普段から意識するようにはしているのですが、意味を考えているか、また、ドキュメント等にも当てはめているかと言われると怪しいので一度反省。
また、曳光弾開発とプロトタイピングの境界を曖昧にして今までプロトタイピングコードを作成していたので、今後明確に切り分けていきたい。

第3章 基本的なツール

  • プレーンテキストは可読性を考えると専用フォーマットよりも強力。単体で意味が分かるように意識する。
  • シェルに慣れなさい。(はい……)
  • エディタに慣れる。理想形はキーボードだけですべて完結。(研究室時代も言われていましたね……実行できていません)
  • あらゆるものをVCSで管理する。各種設定ファイルとかも。(ネットワーク上に利用できる領域がないときはどうすればいいんだろう? ローカルだけでもやる?)
  • デバッグ手法が書いてある。デバッグに困りそうだったら読み直す。
  • エンジニアリング日誌を書くこと。

エンジニアリング日誌はやりたいですね。何をやったか書くとメンタル面でもいい効果がありそう。
現業務ではVSCode使っているのですが、全然使いきれていないのでショートカットキーに慣れないと。(せめてウインドウ分割や移動くらいはマウス使うなよと……)

第4章 妄想の達人

  • 契約プログラミング - Wikipediaの概念を用いて設計すること。
  • catchした例外をそのままthrowしなおさない。想定外の例外をcatchしたら停止させる。
  • 「起こりえない"はず"」を前提としない。そういった部分はassertを用いること。
  • リソースの占有は必要な部分だけ、局所的に。
  • タスクは常に小さく。大きいタスクは事故りやすく、また未来は不確かなものであるため。

assertをUnitTest以外の本コードで見かけたことがないのでそのうち用途は調べておきたい。
invariantとかpreconditionとかは意識することがあるけど、postconditionまで意識することはあまりなかったため今後意識するようにしたい。

第5章 柳に雪折れ無し

  • 第2章でも触れている依存関係の排除について再度触れている。
  • 実世界からのアクションに対するレスポンスを扱うための方法について記載してある。プロセス間や外部通信を考えるときはここを見る。
  • 物事をシンプルなI/Oに分割する。分割したものをパイプラインでつなぐ。
  • 継承を使う前にまず代替手段で代用できないか考える。
  • パラメータでアプリケーションの挙動を変えられるようにする。ただしやりすぎないこと。

一度話題に出た依存関係などに関する話題が再度出てきたということはそれだけ依存関係を持つことが負債を残すことになるのかという印象を持った。継承も依存関係になるというのは確かにそうなのだが、その考えはすっかり抜けていた。

第6章 並行性

Concurrentなプログラムを書くことが今のところないので今のところは割愛。今後必要になったら読み直し。

第7章 コーディング段階

  • 嫌な予感がしたら一度立ち止まる。そしてその解消をする。
  • 偶発的なプログラミングをしない。根拠を出す。
  • アルゴリズムの計算量を見積もる。ただし、現実的に問題になるか? ということを考える。(n数が10^3程度なのにO(n^2)を無理してO(nlogn)にする意味があるのか? とか実装変更で計算量上は減少してもオーバヘッドを考慮できているか? とか)
  • リファクタリングは早めに、こまめに。
  • テストからコードを考える。
  • 現代においては攻撃への対策は必須。攻撃できる箇所は与えないようにする。
  • 名前を決めるのは難しいが、適切な名前を与えること。

普段偶発的なプログラミングしかしていない気がするのでもうちょっと考えるようにします……
リファクタリングは今現場ではできないので、せめて業務外では頻繁に行うようにしたいです。

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

  • 本当の要求は誰も分かっていない。
  • 枠にとらわれないで考える。
  • 一人ぼっちで開発はしない。
  • アジャイルってやつでなんとかして」と言われてお出しできるような定型手法はない。アジャイル宣言はあくまで価値観であり、何をするべきかは状況によって異なる。

顧客が本当に必要だったものというやつですね……要求を出している側も何を必要としているか正確には理解していないという。そこでプログラマが何をして本当に必要な要求を引き出せるか? ということが書いてあり、そのような立場になった際は再度読み返します。

第9章 達人のプロジェクト

おおむねチームビルディングや環境整備の話なのでここも今は割愛。ただ、ユーザを喜ばせることと自身の仕事に責任を持つことは常に意識していきたい。

最後に

その場限りの技術書ではなく概念に対する書籍のため繰り返し読む必要がありますね。
著者が「41 コードのためのテスト」で述べているように「実際にテストを記述することなしに、テストについて考えられるようになっていた」ようなレベルに達するまでは手放すことはできないなと感じました。(もちろん、批判的に考えることを忘れずに!)