エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
API仕様ファースト開発: 柴田 芳樹 (Yoshiki Shibata)
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
API仕様ファースト開発: 柴田 芳樹 (Yoshiki Shibata)
「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」... 「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」を執筆する際に考えた造語です。 全く新規にサービスを開発する場合の開発順序は次のようになります(記事の題3章の図1)。 図1 API仕様ファースト開発での開発順序 これは、私自身が初めてメルペイで担当して、一からマイクロサービスを開発したときの開発順序です。そして、その後、チーム移動により別のマイクロサービスの開発へ移動したり、カウシェへ転職したりした際に、最初に導入したのはE2Eテストフレームワーク(記事の第4章「E2Eテストフレームワークの構築」)でした。 そして、API仕様の技術的負債(エンドポイントの仕様が書かれていなくて、それをテストするE2Eテストもない状態)を返済するために、次の開発順序(記事の第5章の図1)を自分自身も行い、他の開発者達にも行ってもらう