【アジャイル】アジャイルサムライを読む その13 ~ テスト駆動開発 / 継続的インテグレーション

◀︎其の1はこちら
◀︎其の2はこちら
◀︎其の3はこちら
◀︎其の4はこちら
◀︎其の5はこちら
◀︎其の6はこちら
◀︎其の7はこちら
◀︎其の8はこちら
◀︎其の9はこちら
◀︎其の10はこちら
◀︎其の11はこちら
◀︎其の12はこちら

こんにちは！
ラジコード編集部です 😊

アジャイルサムライを読む連載記事その13です！😃
前回は第4部 アジャイルな計画づくりの「第12章 ユニットテスト：動くことがわかる」「第13章 リファクタリング：技術的負債の返済」で、ユニットテストは自動化し改善の基盤を作り、継続的なリファクタリングで保守性を保つとよいということがわかりました。

それでは第5部 アジャイルなプログラミング の「第14章 テスト駆動開発」「第15章 継続的インテグレーション：リリースに備える」を読んでいきましょう。
よろしくお願いします！🙋‍♂️

本シリーズは「アジャイルサムライ − 達人開発者への道」を1〜5部を1~2記事に分け要点を解説していくシリーズです。全13記事を予定しています。

第5部 アジャイルなプログラミング

第14章 テスト駆動開発

テストを先に書く

テスト駆動開発（TDD：TestDrivenDevelopment）は、ごく短いサイクルを繰り返しながら少しずつ設計を進める方法です。

1. レッド：新しいコードを書く前に、まずは失敗するユニットテストを書く
   新しいコードの意図をテストで示し、設計についてしっかり考えます。
2. グリーン：テストに成功するコードを書く
   実装の最終形を想像できるまでは、テストに成功する実装だけで構いません。
3. リファクタリング：実装を見直す
   テストを成功

テストを使って複雑さに立ち向かう

TDDの手順を踏むことで、自身の設計の進め方に自信を持てるようになります。

• 目の前のテストを成功させる → 同時に多くのことを考えなくていい
• 問題の粒度を細かくする → 解決に至る道筋を少しずつ学べる
• 素早いフィードバックを得られる → 正しい方向に進んでいることを確認しながら着実に進むことができる

TDDを繰り返していくうちに以下のメリットを実感できるでしょう。

• シンプルな設計
• 複雑さの低減
• 少ないコード
• 考えるべきことに気持ちが向く
• 最初からコードの質を作り込める

第15章 継続的インテグレーション：リリースに備える

本番環境への反映は、失敗したときのことを考えると不安で胸が張り裂けそうになります。
そうならないためにビルド・インテグレーション・デプロイといった一連の作業を日常にしましょう。
そのために、淀みない継続的インテグレーションの流れとリリースに備える習慣をチームに根付かせる必要があります。

リリースに備える文化

コードは本番環境に置かれているかのように扱いましょう。
本番稼働しているものに手を加えていくように作業を行います。
ただ、スプリントの中で期日に迫られると、ついついコードの質を落としがちになってしまいます。
はやいうちから自信を持って変更を加え、気負うことなくデプロイできる仕組みに慣れておけば、お客さんの要望に応えることができます。

継続的インテグレーションとは

開発者がソフトウェアに加えた変更を取り込んで、ソフトウェア全体として統合する作業を途切れることなく続けていく取組のことを継続的インテグレーションと呼びます。

例えば、ひとつのリポジトリを複数人で作業をしている場合。
ある機能を分担して開発している。ちょっとした変更なら問題ないが、変更箇所がたくさんあり、マージする間隔が開いてしまうと変更箇所の把握が難しくなる。
こういったときはどうすればよいか見ていきましょう。

どうすればうまくいくのか？

• ソースコードのリポジトリ
  GitやSubversionなどのソースコード管理システムを使い、バージョン管理を行う。
• チェックイン手順
  上記の管理システムへのチェックイン手順を明確にする
• ビルドの自動化
  テスト環境、本番環境への反映は、テストを含めて自動で行なえる仕組みを導入する
• 作業単位を小さくしようとする姿勢

次にチェックイン手順でよく見かける方法を紹介します。

チェックイン手順を習慣づける

アジャイルでの開発は、おおむね次のチェックイン手順を踏んでいます。

1. 最新のコードを取得
   作業に取り掛かる前に、リポジトリから最新のコードを取得
2. 変更を加える
   機能追加、バグ修正など必要な作業を終わらせる
3. テストを実行
   自分の変更がコードを壊していないか確認する
4. 作業中に発生した更新差分を取得
   もう一度リポジトリから最新版を取得する。作業中に他のメンバーが手を加えているかもしれない
5. 再度テストを実行
   他のメンバーの変更をマージした上でもきちんと動くことを確認するためにテストを実行する
6. チェックイン
   ビルドもできテストも通れば、手元のコードが最新版となる。安心してチェックインしましょう。

上記の手順に加えて、ビルドを健全な状態に保つためにすべきこと、すべきでないことも確認しましょう。

ビルドを大切にし、いつでも動く状態を保つようにしましょう。

ビルドを自動化する

ビルドの自動化は継続的インテグレーションのプロセスを支える屋台骨です。
コードのコンパイル、テストの実行に止まらずプロジェクト全体のビルドに必要な作業は何でも自動化します。
次にデプロイも自動化します。これができれば多くのヒューマンエラーを解消できるでしょう。

どんなプロジェクトでもビルドの肝は自動化です。手作業が少なければ少ないほど良い。
そして1回のビルド時間をできるかぎり短くしましょう。

作業単位を小さくする

コードの統合（インテグレーション）もこまめに行えば簡単になります。
可能なら10分〜15分。長くても1時間間隔でインテグレーションしたほうがいい。
インテグレーションの統合頻度を高くすればするほど、新しいコードの変更箇所の把握が容易になり楽に統合ができます。

インテグレーションが面倒・厄介な作業にならないためにも、早めにこまめにコードをマージしましょう。

まとめ

以上「第14章 テスト駆動開発」「第15章 継続的インテグレーション：リリースに備える」の解説でした。
テストを先に書くことでコードの質を保ちながら開発ができ、リリースに備えるために自動化が一連のプロセスの鍵ということが分かりましたね。

今回で「アジャイルサムライを読む」は完結です。
アジャイルサムライで学んだ手法をベースにプロジェクトにあったやり方に改善していきましょう😌

月額固定・定額制でアジャイル開発を提供する「サブスクエンジニア」サービスを提供しています。よろしければご覧ください！