Go言語でAPI開発をして得た知見

Go言語を使ってAPIの開発をしたので、開発して思ったことを少しまとめておきたい。 

仕様書の大事さ

仕様書があるならばそれは大事です。仕様書が大事なのではなく、仕様書に書いてある文言が相手に伝わりやすいかが大切。

何か値を編集してjsonとして返却するといったことをする場合に、その編集項目が多くて見にくいとそれが開発に影響する。結果として、返ってくるjsonが仕様書と違くね？ということになりかねない。その時にかかる修正のコストと仕様書を丁寧に書くコストをどう調整するかっていうのは大事だなあと。

伝わる仕様書っていうのは素晴らしいと思う。

編集項目が多すぎるAPIを作った時に、とりあえずテストは後で書こう！と思って開発を進めると後悔する確率が高まります。実装漏れが発生しそうですからね。

細かい単位で実装を行なったら、それに伴うテストを書いていったほうが良いです。そこで実装の漏れに気づくことだってあるんです。この時TDDもありなのかもしれないと少し思った。

ただ、開発期間とかもあるからねえ、難しいよねえ。

多くのエンドポイントが存在している場合や、存在する可能性のある場合はnamespaceを分けないと後がしんどいです。  関数名はまだしも、構造体の名称でぶつかる確率が非常に高い。どんなディレクトリ構成にするのかっていうのは大事ですね。

仕様がほとんど決まってなくて、どんなものをどの程度開発していくか分からんっていう時には最初に決めるのは難しいかもしれんけど。

基本中の基本かもしれないけど、gofmtは素晴らしい。勝手にコードのインデント調整だったりをしてくれます。golintは文法チェックですね。

これらを使うことによって、ロジック以外の部分でコードレビューする手間がなくなるので絶対に取り入れたほうが良いと思います。

CIでは、それらのチェックをするようにして通らなくなるようにすればいいんじゃないかな。

開発する時には、いちいちコマンド打って実行するのは面倒なので、保存した時に勝手に行なってくれるようにすると良いです。

GOを使ってjsonを受け取ったり返却する数が多い場合、構造体がものすごい大きくなると思います。そうするとtypoや漏れが出てくる可能性が大いに出てきます。

コードレビューした時に気付ければいいですが、ロジック部分ではないし、数が膨大なのでそもそもあまり他の人は見ないと思います。

そして漏れがあったものがjsonとして返却するものなら、「あれ、このjson返ってきてなくね？」と気づくことができますが、値の加工のみに使うものだった場合、コードを読んでいかないと気付きにくい。結果として、間違った加工をしたものが返ってしまう。これはやべえ。

その1つがomitemptyです。これをつけることによってそのフィールドが空だったりした場合には、キーごと返却しないようにすることができます。 

適宜オプションは必要な場合はつけましょう。

それぞれの構造体で共通して使いたい構造体、っていうものが開発していると出てくるんじゃないかなーと思います。その時に役立つのが構造体の埋め込みです。共通して使うものはそれぞれの構造体に埋め込んで使おうとします。

ただ、これが進んでいくと後でコードを見た時に「構造体埋め込みすぎててよく分からねえ・・・」という状況になります。なので、どの程度共通処理として扱うかっていうのは考えたほうが良さそうです。

Go言語の良いところの1つは並行処理が割と簡単にできるところかと思っています。処理するデータが多い時なんかにはその効果を大いに発揮してくれるでしょう。  ただ、並行処理ならではの気をつけなければいけない部分もあるので、ちゃんと理解してから使ったほうが良いでしょう。 

  channelとか意味わからん、はあ？とかなった。C言語をやったことがある人であればとっつきやすそう。

 APIを作った後には、必ず作ったものを見返しましょう。扱うデータが多い場合、どこかで漏れがありそうです。特に構造体の中身を仕様書と照らし合わせて確認してみることをお勧めします。

Go言語を使ったのが初めてだったので、本もいくつか読みました。この本が読みやすかったので、最初にこれ読んでおけばまあ良いと思う。