はじめに
今回は、『レガシーコードからの脱却』を読んだので、その感想と学びをまとめたいと思います。
『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』の書籍で良書として紹介されており、読んでみました。
1. 本の概要
本書は、どのようにしてレガシーコードを作らないようにするのかを紹介した書籍です。本書におけるレガシーコードとは「修正や拡張、作業が難しいコード」のようです。
2. 学び・新規で知ったこと
本書ではアジャイル開発手法のエクトリームプログラミング、スクラム、リーンからきた要素を取り入れて、９つのプラクティスを提案し、5章以降で紹介していました。
またこれらのプラクティスを適用するよりも、これらの背景や目的を理解することが重要と述べていました。
- やり方より先に目的、理由、誰のためかを伝える
- 小さなバッチで作る
- 継続的に統合する
- 協力し合う
- CLEANコードを作る
- まずテストを書く
- テストでふるまいを明示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
この中で特に勉強になった「CLEAN」コードを作る、まずテストを書くについて紹介します。
「CLEAN」コードを作る
良いコードであるCLEANコードは以下のように定義されていました。
-
Cohesive （凝集性）
- それぞれの関数やクラスが一つの機能のみを果たすこと
- 複雑なものをモデル化する際は服薄のクラスから構成すること(人クラスを作成する際は、歩行、会話。食事と複数のクラスから構成)
-
Loosely Coupled （疎結合）
- それを利用しているコードに対して間接的にしか依存しない
- そのためあるコードに問題が生じても、他のコードに影響しづらい
-
Encapsulated （カプセル化）
- 実装の詳細はインターフェースから切り離すこと
- カプセル化することにより、拡張が容易となる
-
Assertive （断定的）
- コードが断定的とは、自分の責任は自分で管理することである
- オブジェクトがフィールドやプロパティをもつなら、それらを管理する振る舞いを持つこと
-
Nonredundant （非冗長）
- 複数の場所でやり方に関係なく同じようなことをしていること
- 冗長なコードは保守をするうえで問題となる
特に学びになったのは凝集性と疎結合です。凝集性のあるコードならコード理解に役立ちます。また、疎結合なコードなら、テストコード作成やコード拡張が容易になると開発を通じて感じたからです。
まずテストを書く
テストを最初に書くことのメリットとして以下を挙げていました。
- テスト可能なコードを最初から書くことができる
- 実装したコードがテストを通らなかったら、コードをクリーンアップする作業が発生する
- 機能の振る舞いを予め理解したうえでコードを作成できる
- リファクタリングが正しいかサポートすることが出来る
2つ目が特に印象的でした。開発案件に初めて携わったときは実装→テストという順番で作業を進めていたのでテスト駆動開発に違和感を感じていましたが、この章を読んでイメージが変わりました。
またテスト駆動開発では実装前にはテストが失敗し(テスト対象のコードが存在しないため)、実装完了することでテストが成功するということに気が付きました。
レガシーコードをリファクタリングする
リファクタリングのメリットやテクニックとして以下を挙げていました。
- オープンクローズドにリファクタリングする
- 既存のシステムを学ぶことが出来る
- 拡張する必要があるコードに対してリファクタリングを行う
１つめのオープンクローズドにリファクタリングするが学びとなりました。新機能を実装する際は新機能に対応できるような前準備(拡張したいコードのリファクタリング)、新機能の追加といったような2段階のプロセスでコードを変更することによりソフトウェアの変更が容易になると感じました。
おわりに
特に「まずテストを書く」のプラクティスが一番勉強になりました。今までは実装→テストという順番で作業していたため、新たな学びとなりました。今後のチーム内でテスト→実装の順番で作業するため、この変化によって開発がどのように変わるのか楽しみです。