『レガシーコードからの脱却』の学びを本業へ活用したい

レガシーコードからの脱却を読みました。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

学び・気付き

1. コードは書いた瞬間に時代遅れになる。
2. 常に自動ビルド自動テストを行うべき。
3. アジャイル開発はベターだが、無理に実践する必要はない。

手に取った経緯

前年度まで担当していたモジュールは、誰の目からも明らかにリファクタリングを必要としていました。しかし圧倒的工数不足やデグレ地獄が容易に想像できるため、誰もやろうとはせず…

結局私はそのモジュールの担当ではなくなってしまったのですが、かなり後ろ髪を引かれていました。

そんな中この本の存在を知り、もしあれをリファクタリングするとしたら、どうやれば良かったのか…何かしらのヒントが得られるかもと思い、読みました。

結果的に、今担当しているモジュールでもすぐに実践できるようなプラクティスが得られたので、それをまとめます。

まずは個人的に重要だと思ったことをまとめます。

レガシーコードとは？

ズバリ、全てのコードです。 レガシーコードからの脱却とはつまり、常にコードを改善し続けよ、ということです。

単一責務の原則

これはいろんな本で取り上げられている考え方です。

一つのモジュールは一つの責務を背負うべきである。

この原則を大前提として、カプセル化や疎結合などの考え方が発展していくわけです。

仕様書は最後に作る

この世には、全ての実装が最初に決めた仕様通りに行われたプロジェクトがあるんでしょうか？

少なくとも私は経験したことがないので、仕様書→実装より、実装→仕様書の方が自然であるように感じます。

『コードは嘘をつかない』

優秀な先輩が良く口にしていました。

仕様書は最後に作る。それ自体は非常に良い考えです。

では、仕様書がなければ何を参考に実装をするのでしょうか？

仕様書を最後に作る代わりにストーリーを定義し、ストーリー通りに実装をすべきと主張しています。

ストーリーは、

• 何が（目的）

• 何のために（理由）

• 誰のためにあるのか

という定義で構成されます。

大事なのは、最初から全てを網羅するつもりでストーリーを作るのではなく、開発の中で見つけて拡張していくことです。

テスト駆動開発はダメ？

あまりいい評判を効かないテスト駆動開発。本当に実践に耐えられない開発手法なのでしょうか？

• 筆者の主張

必ずしもそうではなく、 プロジェクトによりけりだろうとのことです（こういう結論が一番困りますよね）。

結局は実践して知見を蓄える必要がありそうです。

ローマは一日にして成らず、ということです。

• テストは『ふるまい』を記述する

それでも、汎用的に活用できる知見も紹介されています。

コードベースでテストを書こうとするとコードの修正とテストの修正が延々とループする状態に陥りかねません。 テスト駆動開発では往々にしてこういう状態に至ってしまうと聞いたことがあります。

テストは、コードベースではなく『ふるまい』の単位で記述しましょう。

『ふるまい』単位でテストを書くためには、そのコードを利用する側の視点に立つことが必要です。

もし利用する側が外部ユーザーでなく、内部の他モジュールだったりする場合は、そこのチームにレビューしてもらったりするといいかもしれないです。

• テストはいつ実施する？

常に実施するべきです。

バグを治すタイミングはいつがいいか。それは作り込んだ瞬間に決まってます。

せいぜい翌日であれば書いたコードを思い返す時間がほとんどいらないので、迅速にバグを治せます（…よね？）

ウォーターフォール（笑）

以上より、

• 実装に取り掛かる前に仕様をかっちりと決め、
• 各モジュールでUTを終わらせてから統合テストを行い、
• 一度統合したコードはバグが発生しない限り変更しない（できない）

ウォーターフォールではレガシーコードからの脱却などできはしないよ、という衝撃の事実が。

（全てのプロジェクトがそうだというわけではありません。あしからず）

実戦投入

今は新しく発足するモジュールの実装部隊の取りまとめを担当しています。

この開発において、レガシーコードからの脱却を図るため、以下のようなことを検討しています。

• テストコードは仮説と捉え、テスト駆動開発というより仮説検証という形で開発を行う。
• 無理やりアジャイルを取り入れる必要はない。ウォーターフォールの中であがく。
• コードを常に改善し続けるため、自動ビルド、自動UTを常に行う環境を構築する。

おそらく、もっと感度の高い企業などでは当たり前に行われていることだとは思います。

ただ、うちはうすのろで、開発もウォーターフォールが律速なので、なかなか難しいところではあります。

その律速があるなかで自分のモジュールを守るため、色々やってみようかなと思っています。

実際に開発が始まり効果のほどが見えてきたらまた記事にしようと思います。