「レガシーコードからの脱却」を読了したが、読了の読了の読了はまだ
「レガシーコードからの脱却」を読んだ。非常に良い本だと思ったので、印象に残った箇所をメモっておく。
プラクティス1: やり方より先に目的、理由、誰のためかを伝える
ここでは「顧客から要求を聞く」という前提になっているが、ゲーム開発では「企画者から要求を聞く」と置き換えて考える。基本は同じ。(まあゲーム開発ではチームの中の誰でも要求は出したりするけど)
ソフトウェア開発者ではない人がどうやって作るかというやり方まで伝えると、ソフトウェアの抽象化がうまくいかないことが起こりうる。
ソフトウェア開発はまだまだ確立されていない分野で、同じ機能を作っても開発者によって全然違う作り方になるし、その違いの中には保守性が全く無い作りになる恐れがある。
良い開発者であれば保守性も重要な関心事として捉えるので、専門家に任せて欲しいという意味でもこのプラクティスがある。
多くの場合開発者は、仕様書やユースケース記述を読みそっくりそのままコードに落とし込んでしまう。そしてそれは解決方法をあとで一般化することを困難にする。
プロダクトオーナーは開発者にやり方を教えるのでなく、終わらせてほしいことに焦点を合わせるように気をつけなければいけない。そうすることによって開発者に裁量が与えられ、より保守性の高い解決方法を思いつくことができる。
「レガシーコードからの脱却」p75より
先日ホットエントリーに入っていた、こちらのスライドでも同じテーマを感じた。
Why?から始めることが人間をどう動かしていくかについて、こちらのTED動画でも述べている。
完了と、完了の完了と、完了の完了の完了
インパクトがあった箇所。
著者は、完了には3つの定義あると言っていて、
- 完了
- 開発者が自分のマシンで結果を確認した状態。
- 完了の完了
- ビルドにも統合されている状態。
- 完了の完了の完了
- ビルドにも統合されていて、クリーンで保守可能になっている状態。
であり、著者が「完了」と言うときは、「完了の完了の完了」という意味で使っている。
対して自分が使う完了はここで言う「完了」か「完了の完了」くらいのことが多く、クリーンで保守可能な状態にするのは後回しにしたり辿り着かないままであったりする。
またこの記事のタイトルにも書いた通り、本を1回読み終わった時もここでいう「完了」ぐらいの状態で、再読やアウトプットによって理解を深めて「読了の読了の読了」の状態にしていくべきだと感じた。
下の記事でも再読の重要性を述べていて、新刊ばかりに飛びつかずに「読了の読了の読了」にしていかないとなぁ。。
CLEANコードを作る
CLEANコードは以下の頭文字を集めたコード品質を示す要素のこと。
今自分がユニットテスト環境をちゃんと作れていないのは、CLEANコードを書けていないからだと自覚している。
これらの詳細については、また別途専門書を読みながら習得していく。
テストに感染する
正直、自分 & チームは、まだまだテストに感染した状態ではないなと思う。
テストファースト開発は設計方法論だ。テスト可能なコードを書くことを強制し、要件を具象化することで、開発者が高い品質のコードを書けるようにするものだ。
「レガシーコードからの脱却」p197より
より高い品質のコードが書けるチームになれるように、自分がテストの感染元となってパンデミック起こしていきたいなぁと思った。
次はレガシーコード改善ガイド
先日書いた記事の通り、最近はUnity開発のテスト自動化に向けて色々試している。
積読している「レガシーコード改善ガイド」にも、テストの無いレガシーコード環境をいかに改善していくかが書かれているので、ちゃんと読みながら今まで自分が産み出してきたレガシーコードを改善していかねば・・・。