APIファーストによる開発 - IoTシステム構築のIT工房Z

何だか最近暖かくなって来て、ちょっと外で遊ぼうと気力の湧いてきたmi2yo4です。

あぐりログサービスも開始から少し経ちまして、次に向けての開発が既にスタートしています。
今回からは少し開発方法を変えてみようという話になっていますので、その違いについて少し書いてみます。

これまでの開発方法

これまでの開発方法を振り返ってみますと、「泥団子型開発」という言葉がぴったりとしているかもしれません。
泥団子的にサーバ―クライアント間の通信インターフェースを作成していた訳です。
「おっ、クライアント側にデータが足りないな…サーバのスクリプトをちょっと書き換えてここにデータを追加しまおう (ペタペタ)」
といった感じですね。

本当はあまり宜しくない方法ですが、これはこれで利点もあります。
サービス開始するまで、とにかく突っ走って成果を出したい、という場合です。よく考えた設計で何かしらのサービスを設計し、実装したとしても、そもそも「そのサービスがユーザーにウケなかった」場合、結果的に設計して実装した時間というのは全くの無駄に終わることになります。

泥団子型開発はある意味、サービスを開始するには最速の方法です。なので、現在まで取りうる戦略の中では良かったのかなと思っています。
(おかげさまであぐりログサービスに需要があると言う事が早く分かりました ^^)

ですが、先ほど「宜しくない方法」と書いたとおり、欠点ももちろん有ります。

見通しが悪い・データの重複が多い

泥団子的にその時点で必要と思われるデータをペタペタと追加したので、あちこちに同じ事を示しているデータが多くなってしまいました。これは通信量の増大にモロに響きますし、どのデータを使えばいいのか分かりにくい事にも繋がります。

設計思想が分からない

泥団子型なので、ドキュメントがあまり有りません。なので、実データを見て何がどうなっているのか判断する事が多くなります。

分業に向いていない

一人でサーバ、クライアント両方のコードを泥団子でペタペタしますので、他の人と協業して行う事が難しくなります。
仕様は作っている本人の頭の中のみ、と言う状態はまずいですし、時間が経ってしまえば、そのコードを開発した本人も理解できなくなる可能性も…有りますよね?

これからの開発方法

そんな際に、あぐりログサービスを弊社の外、外部サービスから使いたい、という話も春の兆しのごとくちらほらっと出てきたような気がします。
となるとAPI(Application Protocol Interface)の整備が必要となって来ますね。

どうせなら、サーバ―クライアント間のやりとりについて、全てAPIを定義して実装すれば良いのでは？という事で今作業をしています。
APIをベースに開発を進める、APIファーストによる開発ですね。

分業に向いている

メリットについては、先に上げた泥団子型のデメリットを全て裏返しにしたものとなりますが、一番大きいのは「分業がやりやすくなる」事だと思っています。
APIを定義しておけば、それを元にクライアント、サーバ側の開発担当者がそれぞれのペースで作成する事が可能となります。

例えばこんなケースも。
「クライアント側を実装していてるけど、サーバ側の実装が終わっていないのでテストが出来ない。」

→「サーバ側の実装を待たずにAPIに基づいたダミーのサーバ(モックサーバ)を立ち上げて、それでクライアント側の開発、テストを進める」

境界となる部分のAPIさえしっかりと定義してそれぞれ開発していれば、クライアント・サーバのプログラムを一緒に合わせて通しでテストした場合にも問題は少なくなります。

事前にしっかり考えることが出来る

あともう一つ、大きいメリットとして「事前にある程度考える事が出来る」事だと思います。
やはり、考えるより先に試してしまう(=コードを書いてしまう)事が多くなりがちですが、コードを書く前に考えをまとめておくことはとても重要ですね。
特に分業体制の場合であれば、お互いの認識を事前に擦り合わせておく事は、モノが出来上がってから擦り合わせるよりもコストが格段に低いです。