概要

API仕様ファースト開発とTDDを車の両輪として実践する

想定読者

WebサービスのバックエンドAPIを設計・開発しており、テスト駆動開発を組織に根付かせたいエンジニア。特にgRPCを採用しているチームや、API仕様の技術的負債に悩む開発者。

こんな人には向いていない

• プログラミング入門者。本書はAPI設計とTDDの実務経験を前提としており、基礎的なHTTPやRPCの仕組みから学ぶ段階の読者には説明が不足している
• RESTful APIの設計パターン網羅を期待する読者。本書の具体例はgRPCに特化しており、OpenAPI/Swaggerを中心に据えた設計論は扱われていない
• すでにAPI仕様ファースト開発とE2Eテストを本番運用で確立しているチーム。プロセス定着後の最適化や高度なアーキテクチャ選択については本書の射程外となる

読了後にできるようになること

• API仕様に何を書くべきかを、エンドポイント概要・エラー・リストオプションの粒度で具体的に判断できる
• gRPCのprotoファイルを仕様ドキュメントとして機能させる書き方を習得できる
• API仕様ファースト開発の実装順序(仕様→E2Eテスト→実装)を自チームのワークフローに組み込める
• マイクロサービス構成と非マイクロサービス構成の両方でE2Eテストフレームワークを設計・構築できる
• Go言語でcourierライブラリを用いたE2Eテストコードを実装できる
• 既存APIの仕様不備を技術的負債として分類し、返済順序を判断できる

本書のキー概念(章解説)

• 第 1 章 ソフトウェアテストの変遷 — ビッグバンインテグレーションからCIへの歴史的経緯を整理する章。背景理解として有用だが、急ぐ場合は後から読んでも問題ない
• 第 2 章 API仕様 — 優れたAPI仕様の条件とよくある問題点を論じる核心章。本書の判断軸を構成するため最初に精読する価値がある
• 第 3 章 gRPCにおけるAPI仕様の書き方 — protoファイルへの記述粒度をエンドポイント・エラー・リストオプション別に示す。gRPCを使っていないチームは概念の参考として読める
• 第 4 章 API仕様ファースト開発 — 本書の提唱する開発プロセスの全体像。著者が日々実践する手順を開発順序・不具合修正・既存修正の3パターンで解説する実務直結章
• 第 5 章 E2Eテストフレームワークの構築 — マイクロサービス構成と非マイクロサービス構成の両方を扱う。組織のアーキテクチャに合わせた章を選んで読める
• 第 6 章 API仕様の技術的負債の返済 — 既存コードベースへの適用を考える読者に最も重要な章。E2EテストとリファクタリングをセットにしたROI計算の観点が実用的
• 第 7 章 Go言語によるE2Eテストフレームワークの実装 — courierライブラリを用いた具体的な実装例を示す。Go以外の言語を使うチームはフレームワーク設計のパターン参照として活用できる

ハイライト

• API仕様ファースト開発とテスト駆動開発は、いわば車の両輪のような関係にあります。API仕様ファースト開発はWebサービスにおける大域的なテスト駆動開発の実現に必要なものであり、また、API仕様ファースト開発を実現するにはテスト駆動開発が必要です。(本書が提唱する開発方法論の核心。二者択一ではなく相互依存の関係として位置づけている点が本書の独自性)
• 多くのソフトウェアエンジニアが実践できていないことです。そのために必要なE2Eテストフレームワーク、さらには、API仕様がきちんと書かれていないために生まれる技術負債の返済方法なども紹介します。(著者が30年の実務知見から問題意識を語っている部分。実践できている組織が少ないという前提が、本書の購買動機を明確にする)

編集メモ

Qiita言及記事0件、楽天ランキング情報なし。2024年7月刊行で外部シグナルが蓄積中の段階。書誌情報と著者(Merpay/Mercariでの実務経験30年)の信頼性から実務向け良書と判断できるが、現時点のシグナル数ではsupplementaryラベルが妥当

読む前に押さえておきたいこと

• HTTP/gRPCの基本概念とProtocol Buffersの構文読み取り経験
• テスト駆動開発(TDD)の基本サイクル(Red-Green-Refactor)の実践経験
• Go言語の基本構文の読み書き(第7章を実装例として追う場合)

学習のコツ

• 第2章と第4章を先に読み、自チームの現状と照らし合わせてから、gRPCを使っているなら第3章、E2Eフレームワーク構築が目的なら第5〜7章へ進む順序が効果的
• 第6章(技術的負債の返済)は既存サービスへの適用を検討する読者が最も実用的に使える章。新規サービスから読み始めた場合も、ここを先読みして問題意識を持ってから前章に戻ると理解が深まる
• 付録A(Goのテストの並列化)と付録C(防御的プログラミング)は本編の補完ではなく独立した実装知識として機能するため、必要に応じて単独で参照できる
• 著者の30年の実務知見に基づく判断基準を自分のプロジェクトの判断に援用するために、各章の設計判断の根拠部分にマーキングしながら読むと再利用しやすい