はじめに
最近(2019年10月)、よく話題に挙がる書籍「レガシーコードからの脱却」を読んだところ、とても素晴らしい書籍でした(ベストセラーになってました)。多くのプロジェクトが、この書籍を参考に、レガシーコードを作らないようになるといいなと思いました。
本稿は、私が書籍「レガシーコードからの脱却」を読んだ結果、特にプロジェクトに適用すると良さそうだと思った事をまとめた内容です。
本稿が対象とする人
本稿は、以下のいずれか1つ以上を実施していないプロジェクトが対象です。
- アジャイル開発
- 嬉しさが分かる最小単位のユーザーストーリーで開発
- 自動ビルドおよび自動テスト
- ペアプログラミングまたはモブプログラミング
- テスト駆動開発
- 開発中の機能のリファクタリング
- レガシーコードのリファクタリング
プロジェクトに適用すると良さそうな事
書籍の目次は公開されているので、適用すると良さそうな事が、どの章に書いてあるかのみ記載します（書籍の内容はぜひ購入してご確認ください）。
アジャイル開発
ウォーターフォールで開発しているプロジェクトは、1章～3章の内容を皆で共有すると良いと思います。ウォーターフォールが、失敗確率が高いこととその理由がよく分かります。
また、「着手したけどテスト完了しなかったら無駄になる」という認識は、プロジェクト全員が共有した方が良いと思います。私の経験では、複数機能のテストを最後に残すと、だいたい期限までにテストが終わらないため、いくつかの機能を外します。そうなるくらいなら、最初から1つずつテストを完了させた方が良いと思います。
嬉しさが分かる最小単位のユーザーストーリーで開発
私は過去に、作った機能が顧客の欲しかったものと違ったことがあります。また、頑張って多様なバリエーションに対応する機能を開発したものの、実際のユーザーはそこまで使いこなさず、シンプルな機能だけで十分だったということは多々あります。
そういう経験があるプロジェクトは、5～6章を読んで、ユーザーストーリーを用いて開発する方法を適用すると良いと思います。
嬉しさが享受できる最小限のシンプルな機能の開発をすることで、もっと早くもしくはもっと多くの機能をリリースできるようになると思います。
自動ビルドおよび自動テスト
私は過去に、開発終盤にプログラムを統合してみたら、予期しない問題が色々出てきて大変な目にあったことがあります。そういう経験のあるプロジェクトは、7章を読んで自動ビルドおよび自動テストを適用すると良いと思います。
ペアプログラミングまたはモブプログラミング
下記のいずれかに当てはまるプロジェクトは、ペアプログラミングを検討した方が良いと思います。
- クラスや関数や変数の名前が不適切なコードが多い
- コーディング後のレビューやテストで大量の不具合が検出される
- コーディング中に他人に話しかけられて、集中が乱されることが多い
本書の8章では、ペアプログラミングに懐疑的な人が、そのメリットを論理的に理解できるだけの十分な論拠が記載されています。
私のチームでも、ペアプログラミングとモブプログラミングをやっていますが、生産性は上がりました。とてもお勧めのプラクティスです。
テスト駆動開発
コーディング後にそのコードのユニットテストをどうやれば良いか困ったり、後からリファクタリングしようにもユニットテストがないからできないという経験があるプロジェクトは、10～11章を読んでテスト駆動開発を適用すると良いと思います。
ただし、「常に100%のカバレッジ確保」については、世の中に様々な意見があります。著名なMartin Fowler氏は テストカバレッジはおそらく80%台後半か90%台になるだろう と言っています(私のチームも100%は目指していません)。
開発中の機能のリファクタリング
私は、開発した機能をリリースした後に、その機能の設計をふと見て、冗長性や不適切な責務分担に気付いたことがあります。リリース前に気付いておけばと後悔しました。そういう経験のあるプロジェクトは、9章と12章を読んで、「設計は最後に行う」というプラクティスを適用すると良いと思います。
私たちは神様ではないので、コーディングをする前にクラス図を書いて考えた設計には、不適な部分があると思います。いったんコーディングを終えた段階ならば、それを通して得た新しいドメイン知識などを元に、よりよい設計ができると思います。そういうタスクを予め計画しておくと良いと思います。
レガシーコードのリファクタリング
保守が困難なコード(レガシーコード)が増え続けていくプロジェクトは、13章を読んでレガシーコードをリファクタリングするためのいくつかのパターンを適用すると良いと思います。
保守が困難なコードは、生産性を大きく低下させます。従って、今後も変更し続ける部分はリファクタリングした方が良いと思います。
まとめ
プラクティスをプロジェクトに適用するには、チーム全員が価値観を共有していると、取り組みやすいと思います。そういう意味で、以下の記事の手法でチーム全員が同じ書籍を読んで価値観を共有するのも良いと思います。
毎朝15分の勉強会で若手の行動が驚くほど改善した話
ちなみに私は Lightning Review というレビュー支援ツール を開発しています。
Twitterでも開発に役立つ情報を発信しています → @kojimadev