はじめに
ITエンジニア本大賞を受賞していて、気になっていた本です。
「レガシーコードを作らないようにするためのプラクティス」が紹介されている。テストやリファクタリングではなく、「よい開発者は机をきれいにしている」といったマインドセットが解説されているのが特徴だ。
学びが多かったので印象に残ったところを残しておきます。
まとめ＆感想
レガシーコードはなぜ生まれてしまうのか、そしてどのようにしたらレガシーコードやいわゆる技術的負債に陥らないのかについて書かれていました。アジャイル開発とテスト駆動開発の関連性、そしてそれらから得られるコード保守性に関する説明が非常にわかりやすかったです...！
開発者として非常に共感する内容が書かれていたり、
開発者がほとんどの時間を費やしているのはコーディングではない。仕様書を読み、ドキュメントを書き、会議に出席するのに時間を費やす。そして、デバッグに一番多くの時間を消費しているのだ。
少し捻ったかっこいい表現があったりと、読んでいて楽しかったです。
私たちは言葉を通じて世界を体験し理解する。ソフトウェアを作るのも、結局言語的な活動なのだ。
個人的には、もっとペアプログラミングをして、知識を伝達しあう営みを行うと、エンジニアとしても満足度が上がるし、プロダクトとしてもより保守性の高いものに出来上がっていきそうだと感じました。
特に印象に残ったところ
レガシーとは
毎日実行され、過去の意思決定をもとに逃れようのない影響を及ぼし続けるが、なんの活力もないコードがある。このコードを丁寧な言葉で「レガシー」と呼ぶ。
第一原理
以下のものが例として挙げられている。
- 単一責務の原則。「クラスを変更する理由は1つでなければならない」
- オープン・クローズドの原則。「ソフトウェアのエンティティは、拡張に対して開いており、変更に対して閉じてなければならない」
この辺の原則は SOLID原則 から取ってきているような気がする。
なぜよいソフトウェア開発のためのプラクティスを知る必要があるか（抜粋）
- 使われるソフトウェアは、必ず変更が必要になる。なので、変更可能であるように書かれる必要がある。
- 何かを正確にモデリングするためには、まずはその対象を理解しなければならない。
良いストーリーを書くための戦略
（アジャイルの文脈でいう）ストーリーとは、「誰のため」に「何を作る」のかに集中しやすくするためのもの。
- プレースホルダーとしてみる
- ストーリーはプロダクトオーナーと開発者の間の会話を取り持つものとして捉える。
- 目的に注目する
- ストーリーは How ではなく What に焦点を当てる。
- 「誰」を擬人化する
- ユーザーを理解する助けとなる。
- なぜ機能が必要とされたかを知る
- ストーリーの「〇〇のために」という部分に注目し、機能開発のためのより良い選択肢を探す助けとなる。
- シンプルに始めて追加は後で行う
- エッジケースを考える
- 受入基準を利用する
実装の詳細ではなく、目的や制約を説明するために、「目的、理由、誰のためか」を明文化する。
ソフトウェア開発を計測するための戦略
- 価値実現までの時間を計測する
- コーディングに使った時間を計測する
- 欠陥密度を計測する
- 機能ごとの顧客価値を計測する
- 機能を提供しない場合のコストを計測する
- フィードバックループの効率を計測する
ペアプログラミング
参考：ペアプロを極めて最強の開発チームをつくる（1/4）ペアの組み方（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社
エクストリームプログラミングのうち、もっとも価値がありながら、もっとも誤解され過小評価されているものである。ペアの組み方には二つの方法がある。
- 開発者の強みと弱みを踏まえて組み合わせる方法。ペアはお互いの得意なところを活かし、苦手なところを補うために協力し合う。これは、性格面でも適用できる。
- 一番経験を積んだ開発者と、一番経験の少ない開発者を組み合わせる方法。これは、経験を積んだ開発者側も教えることによって、新たな学びを得ることができる。
ペアプログラミングを適切にやれば、チーム内で知識を広げて全員のスキルを伸ばし、仕事の満足度を上げられる。
コードレビューとレトロスペクティブのスケジュールを立てる
- ペアプログラミングとは、本質的には「書きながらおこなうコードレビュー」である。
- 設計レビューはコードレビューでは、設計とその設計を選択した理由について議論するべき。
- 設計のトレードオフを理解し、拡張がどれだけ簡単かを議論することがコードレビューの良い議論。
- イテレーションやリリースの終わりごとのレトロスペクティブ（振り返り）も非常に需要。チームの改善を促し、新たな課題の発見を促すことができる。
明日のベロシティのために今日品質を上げる
- 明日のベロシティを上げるためには今日コード品質を上げることが大事。
- 高品質のソフトウェアはデバッグも簡単で、早くデリバリーできるようになるし、コードの保守も簡単になる。結果として、総所有コストが下がり、すばやい改修が可能になる。
- コード品質の向上は変更のコストを下げ、見積もりを予測可能なものにしてくれる。
- 品質のためのプラクティスを共有する。
保守しやすいコードを書く戦略（抜粋）
- コードの共同所有を取り入れる
- チームメンバーの誰もが、コードのどの部分でも変更して良いことを意味する
- リファクタリングを熱心に行う
- 常時ペアで進める
- ペアプログラミングは知識を伝える上でいちばん早い方法である。
- 毎日いろんな人とペアを組んでみて、学習し続けることが必要。
- 頻繁にコードレビューする
- 他の開発者のやり方を学ぶ
良いテストを書く
テストの観点（外部からの観察）と、コードの観点（内部からの観察）を行き来することで、フィードバックをもらいながら堅実に進めることができる。テスト可能なコードを最初に作成しておくのが楽である。
