目次
■キャリアとスキルアップ
2022.11.18 2023.12.14 約3分
この記事は、2022年4月発売『実用 Go言語―システム開発の現場で知っておきたいアドバイス』著者陣 による connpass勉強会 を再編集し、記事化したものです。
ぜひ、こちらもあわせてご覧ください。
Go言語はシンプルで学びやすい文法ですが、複雑な要件を実現するために、プログラミング言語が提供する構成要素をさまざまに組み合わせる必要があります。『実用Go言語』には経験に裏打ちされた今どきのGoの使い方が詰め込まれています。今回は著者陣による制作秘話や裏話、視聴者からの質問コーナーをお届けします。
渋川：Goはシンプルな言語です。キーワードが少ないとされる Python の半分ほどのキーワードしかないのですが「シンプルゆえに難しいのかも？」と感じました。（複雑な言語の学習コストは高いですが、記述をストレートに表現できます。Python や Go などのシンプルな言語は学習コストが低いものの、表現が長くなります。）また他言語からのエンジニアが文法リストを見ても「この機能がないんだ……」といったように、イディオムに辿り着くまでの情報がほとんどありませんでした。そこで、どのような組み合わせがあるのか、ベストな書き方のパターン集があった方が Go の学習には良いと考えました。こちらの技術ブログは、周りに聞いた内容をすべて書き出した長文のエントリーです。ぜひご覧ください。Future Tech Blog | Goを学ぶときにつまずきやすいポイントFAQ
渋川：Sphinx は、かなり広く使われているオープンソースです。実行できるソースを参照してソースコードのサンプルとして取り込む機能があって、コピペミスが減ったり、脚注などの書籍で必要とされる表現ができたり、細かい機能や文法要素が充実しています。
渋川：レビューは読書会形式で社内でおこないました。1章ずつみんなで黙読しチャットにコメントを書いてもらいます。これは Amazon が実施しているのを見て面白いなと思い、今回取り入れてみました。出版ギリギリにレビューを実施したのですが「読みにくい」と正直な意見もあり、大幅に書き換えたりもしました。
渋川：日々、書きたい内容が成長するのですが、すべてを書籍に盛り込むことはできません。そこで、まず技術ブログに書いてみて大事な部分をダイジェストにして書籍に入れるようにしました。逆にブログで反応が良かったので書籍に取り入れた内容もありました。とくに苦労した点は、クックブック形式（何が目的があり、それを実現するというストーリに当てはめていく）で進めていたのですが、必ずしもその形式がベストではないトピックもあることに気が付き、最終的に大幅に手直しをしたことです。
辻：サンプルコードを丁寧に書くのは大変でした。なるべく実践に沿ったコードを記載しようとすると、同じパターンになってしまったり。
真野：Go というよりもDockerや周辺のデータベース、AWSのクラウドの知識がないとうまくコーディングできないのですが、そのあたりの話をどこまで盛り込むかは苦労しましたね。
渋川：gRPC はとても興味があったのですが、Webと一緒に使うためにはプロキシを挟むなどアーキテクチャ上の制約があって使いにくかったんです。最近、プロキシがなくても簡単にOpenAPIのように使えるようになったconnect-goという別実装が登場したので、これは機会があれば追加したいですね。
▲ 渋川「GraphQLも5年前に比べると、かなり使いやすくなってきましたね。」
▲ 辻「最新のGo 1.18 から含まれるジェネリクスがとても便利なので追記したいですね。」
真野：真面目にGoで実装していくとテストが肥大化するので、ローカルのモックサービスを使ってテストすることが多いと思います。トレードオフとして（ローカルモックのデータ追加や削除など）テスト時間が長くなるので、分散でテスト実行する仕組みなどはもう少し記載しても良かったのかなと思います。
真野：リリースログや ChangeLog はエンタープライズであるほど用意した方がいいかもと、ここ数ヶ月の学びです。せっかくコードを綺麗に書いてもリリースでミスると終わるので、トレースの仕組みの話は追記したいですね。
渋川：僕の今やってる案件だと、大規模なデータのやり取りがあるので、SFTPやHULFTの話があるとちょっと嬉しいかも。
辻：あとは静的解析も一定の層にささるかも知れないですね。
渋川：やっぱり自分が使うものが一番ですね。「こういうライブラリが欲しい」と思っても実際に業務で使ってみると、いろいろな気付きがあって、拡張したりすると思うので、自分で使うものを触っていくのが良いと思いますね。
辻：自分の趣味や仕事で使うライブラリですね。バグっぽい挙動があると、コードを詳しく調べてPull Requestを出したり、Issueを起票したりしていますね。
真野：自分で使うものをまず汎用的に小さく作ってみるのは良いかなと思います。
渋川：1ファイルが長くなるのは変わらないのですが、関数自体を分けています。例えば、ループの中身が全く一緒でも、正常系と異常系で分けるとか。
真野：パラメータがちょっと違うパターンでいっぱいやるときは、CSVを書いて、それをCSVパースして struct につめなおしてます。
辻：少しマニアックな感じだと、例えばエクセルでインプットとアウトプットデータを用意して、それをテストに使ったりすることもあります。
真野：Javaでいう数値演算クラスが無いので、金額計算のときはイラッとしますね。
渋川：コンパイル後の解析をもうちょっと頑張って、ビルドサイズを縮めて欲しいな。ちょっとした printf でも2MBになったりするじゃないですか。あれが小さくなると使いやすくなりますよね。
辻：少しニッチですが、Goのimport文ってデフォルトだとソート順が決まってないんです。開発者によって空行があったり順番が統一されていないところを直して欲しい。
渋川：mattn（@mattn_jp）さんに Windows 対応を突っ込まれると「やられた！」と感じますね。
一応、Windows を意識してコード書いてるけど、ちょっと自分ではテストしてなくて実際動かしてみたらエラーみたいなときに、すかさずツッコミがくると流石だな……と。
辻：sqlc の作者は自分が思いつかないライブラリを高い品質で実装しているところはすごいなぁと思いますね。
真野：goccy さんが BigQuery のエミュレータを作っていて「これはちょっと真似できないな」と思い尊敬しています。
真野：私はわりと無頓着に、その時一番いいなと思うものを使っています。
辻：プロダクトやチームに合わせていくつかライブラリを比較し、良いものを使うことが多いです。
渋川：OpenAPI や gRPC をフレームワークと呼ぶのかは置いておき、それぞれ自分の好きなものを組み合わせて使うと思いますね。さすがに標準ライブラリだけということはないのかなと。
渋川：単独で動くライブラリを作ったときに、そのライブラリの品質を上げるというか。
Goのプロパティベース・テストのフレームワークはとても良くできているんです。基本的にランダムで値をたくさん生成して実行し、失敗したら報告してくれるのですが、それだけではなく、さらに追加でたくさんテスト回して、失敗する中で一番シンプルな入力のパラメータを見つけて返してくれるのでデバッグしやすいんです。1回使ってみるとなかなか面白いですよ。
—「なぜGoなのか？上司を説得する方法」という見出しが面白いです、とコメントが来ています。
渋川：私は8年くらい前（DeNA時代）勝手にGoでバッチ処理をして怒られたことがありますね。そして「なぜGoなのか？上司を説得する方法」という見出しを付けた理由は、普通に書いても面白くないから。内容的には普通にGoの紹介になってると思います。
真野：「もう全部 Pythonで作られてます！」みたいな状態で別の言語を入れるのは、やっぱりハードルが高いでしょうね。保守運用コストがかかるので、なるべく統一したいのが普通の考え方だと思っています。では、どうやってGoを入れるかですが、やっぱり適材適所なのかなと思います。全部 Python でバックエンドを書くのではなく、例えば IoT系ならデプロイ速度やデバイス側も軽いですよ、と。小さな成功体験を積んで「これはいいものだ」と思ってもらう作戦ですね。
渋川：仕事で使われている方は別として、それ以外の方だと、やっぱり自分が使うツールを作ってみるのがひとつかな。最近ちょっとデータベース力をあげたいなと思って、SQLを生成するGoのコードを作ってみて、Webサービスにしてみたんです。自分でどんどん触ったり使ってみて改良していくと成長が早いと思います。
真野：本当に入門レベルの方であれば A tour of Go のチュートリアルを受講するだけでも良いですし、もうそれだけでプロジェクトにジョインしてほしいぐらいの気持ちです。
渋川：フューチャーは二次請けに丸投げせず、お客様と直接会話をしながら必ず一次請けで仕事をします。グランドデザインなどの大きなビジネスを今後どうしていくかやシステム設計、開発、テスト、運用まで全て請け負っています。興味のある方はぜひお問い合わせください。
