CodeZine(コードジン)

特集ページ一覧

脱レガシーコード!すべての開発者が単体テストを書く文化を作るまでの取り組み【デブスト2021】

【A-2】脱レガシープロダクトに向けて開発環境にCIを整備し単体テストを布教した話

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2022/02/10 12:00

 マイケル・C・フェザーズ著の『レガシーコード改善ガイド』によると、「単体テストのないコードはレガシーコード」だという。大手企業に広く支持されている人事システム「COMPANY(カンパニー)」を開発しているWorks Human Intelligenceも、これまで結合テストに頼った開発フローを採っており、製品開発はザ・レガシーコードと言えるものだった。だが、そんな開発環境が改善され、今ではすべての開発者が単体テストを書くようになったという。Works Human Intelligenceではどのようにして脱レガシーコードを実現したのか。DXエンジニアの寺尾拓氏が2年間に及ぶ開発環境の改善への取り組みを語った。

目次
株式会社Works Human Intelligence DX Engineer 寺尾 拓氏
株式会社Works Human Intelligence DX Engineer 寺尾 拓氏

レガシープロダクトをリファクタリングするために単体テストを整備

 「プロダクト開発部門に配属されてから取り組んで来た開発環境の改善の話をしたいと思います」

 冒頭でこう語り、寺尾氏のセッションは始まった。

 寺尾氏は2019年4月に新卒でWorks Human Intelligenceに入社した後、プロダクト開発部門に配属され、1年間、開発環境の改善に取り組んできた。2020年12月より半年間の育休を取得した後、現在はDXエンジニアとして、開発部門全体のDX改善チームの立ち上げに参画している。

 Works Human Intelligenceが開発する「COMPANY」シリーズは大規模なソフトウェアだ。「20年間保守しており、ソースコードは数百万規模。それを5~10人からなる、オフショアを含めた複数のチームに分かれて開発している」と寺尾氏は説明する。40~50人の開発者がソースコードを共有して開発しているのだ。

 このような大規模プロダクト開発に携わった寺尾氏は、「ソースコードが大規模かつ依存関係が複雑」「ビルドやサーバ起動などに時間がかかる」「テスト自動化が難しく手動テストに頼らざるを得ない」などの問題により、つらさを感じていたという。だが「これらのつらさの原因は、レガシープロダクトだったから」ということに気づいた。

 そこで大規模プロダクト開発を楽しくするために、寺尾氏は「脱レガシー」に取り組むことにしたという。

 「まずはモノリス分割が必要だと考えた」と寺尾氏。モノリス分割とは全体が複雑に絡み合っている1枚岩の状態から依存関係を分割することだ。こうすることで、開発体制も変わる。

 「共有していたソースコードがチームごとに分割されるので、独立したチーム開発が可能。モジュール間の依存関係がシンプルになり、ビルドも高速になる。またチームごとに趨勢するモジュールが独立しているため、責任範囲が明確になり、どこに修正すべきがわかりやすくなる。そのためチーム間の協調も最小限になる」(寺尾氏)

 モノリス分割をするために必要になるのが、システムの振る舞いを変えずに内部構造を変えることができるリファクタリングである。リファクタリングをするには、正しい振る舞いであることを保証することが必要になるが、レガシープロダクトでは正しい振る舞いが明確ではない。またそれを保証するのに必要なテストの工数が確保できなかったりするからだ。

 いきなりリファクタリングを行うのではなく、そのための第一歩として、「プロダクトコードに単体テストを整備することから始めた」と寺尾氏は言う。

 単体テストの整備に乗り出したのは、新卒で配属された2年前の2019年。当時の開発環境について寺尾氏は「セットアップに時間がかかる、コードレビュー時に自動チェックがなく、ビルドが不安定など、問題が山積し、どこから手につけたら良いか分からない状態だった」と振り返る。

 そこで「まずはモダンで快適な開発環境の整備しようと思った」と寺尾氏は続ける。具体的には開発者全員が共通の設定のIDEを利用したり、ファイルの編集のたびにフォーマッタやLinterを実行したり、コードレビュー時にビルドやフォーマッタ、Linter、単体テストの自動チェックを行い、その結果をすぐ確認できるように整備していったという。

 その際に「快適に仕事ができる仕組みにもこだわった」と寺尾氏。例えばIDEのセットアップの自動化や、自動チェックに時間がかからないよう、実行時間の目標値を設定したり、自動チェックの誤検知が少なくなるような対策を施したりしたという。

 しかし「1年かけてモダンで快適な開発環境が整備できたのですが、これだけでは脱レガシーはできませんでした」と寺尾氏は語る。なぜなら単体テストの数がなかなか増えなかったからだ。寺尾氏はその理由を探るため、JUnitダッシュボードで可視化、分析したという。こうすることで、どの部署でテストが書かれているか、概ね把握できたが、「テストを書いていたのは一部の部署だけで、残りの大部分の開発者は単体テストを書いていなかった」と言う。その背景には「単体テストを書いてもE2Eテストもするので、二度手間では」「単体テストをどういう観点で作ればよいかわからない」「データベースがないと動かないテストが多すぎる」などの理由があったという。

 当時の開発チームの状態は、「単体テストをどう書いていいかわからない」「習得する時間も無いから今回は手動テストでいいかな」という考えの人が多く、単体テストが書ける人はほんの一握り。中でもレガシーコードに単体テストが書ける人はほとんどいなかったという。多くの人が単体テストを書けず、メリットも感じられていなかったのだ。そんなチームの状態で、いきなりレガシーコードに単体テストを書くのはハードルが高い。

当時の単体テストに対するチームの状態
当時の単体テストに対するチームの状態

  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブスト2021】セッションレポート

著者プロフィール

  • 中村 仁美(ナカムラ ヒトミ)

     大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5