読了 - レガシーコードからの脱却 - バナナでも釘は打てる

Ryuzee.comで紹介されてたこともあって以前から読もうと思ってたのですが、たまにはIT屋らしい書籍を、と取り上げてみました。

この本を最初に手に取って思ったのは、装丁が見たことのあるような…です。

f:id:ino-agile:20191103094212p:plain

似てませんか？

アジャイルというと、なんか渦っぽいものをイメージに使うことが多いような気がしたのですが偏見ですかね。

ジャブはその辺にして本書の話にしましょう。

本書のタイトルを全部書くと「レガシーコードからの脱却ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」。

いま既に存在するレガシーコードをどうにかしよう、みたいな印象を受けたのですが、中身はむしろ「レガシーコードを生み出す悪習からの脱却」です。

原題を見ると「Beyond Legacy Code - Nine Practices to Extend the Life (and Value) of Your Software」なので、「レガシーコードを踏み越えて」の方が近い感じですね。

諸説あります w

本書では、

過去の意思決定をもとに逃れようのない影響を及ぼし続けるが、なんの活力もないようなコードがある。それを丁寧な言葉で「レガシー」と呼ぶ

これを読んで思わず「うまい！デービッドさんに座布団10枚あげて」とか思いましたね。

私はこれに加えて、何を目的に、どういう条件のもとで、そのような設計、実装になったのか、それが残ってない。残ってても曖昧だったり、欠けてたりすることが多いのがレガシーだと思います。

そんなレガシーコードを生み出さないためのプラクティスをまとめたのが本書です。

やり方より先に目的、理由、誰のためかを伝える

小さなバッチで作る

継続的に統合する

協力しあう

「CLEAN」コードを作る

まずテストを書く

テストでふるまいを明示する

設計は最後に行う

レガシーコードをリファクタリングする

本書は、アジャイルプロセスであるスクラム、XPを中核に書いてはいるのですが、挙げられている9つのプラクティスは、アジャイルでなくても「そうあって欲しい」ものです。

9つのうち「8. 設計は最後に行う」だけが引っかかる人も多いのではないでしょうか。

趣旨としては「ソフトウェアの保守性を設計するのに最適なタイミング」が、コードがすでに書かれていて、テストでサポートされている状態だ、ということです。

私はエンタープライズ系の開発を続けてきた中で「設計には3つの役割がある」と教えることがあります。3つの役割とは、

実装指示書としての設計はプログラマーのスキルやコミュニケーションの密度によっては簡略にできますが、1と3は省けません。

特に「顧客が投資価値を判断するためのもの」は無いとダメだと思うので、どのように考えるべきかは解説して欲しかったところです。

本書の中で幾つか出てくる「7つの戦略」は一読の価値がありますので、ちょっと多いけど挙げてみます。

いずれも、実際に取組む時に悩むさじ加減の参考になります。

ところで、本書が高いという話がどこかに出てたんでしょうかね。

個人のお小遣いから3000円出すのは高いという話かなとは思いますが、SEの作業量が1日分改善できるなら破格のコストパフォーマンスですよね。

ぜひ1冊お手元に！