Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Ähnlich wie Goでのチーム開発とコード管理の悩み
Ähnlich wie Goでのチーム開発とコード管理の悩み (20)
Goでのチーム開発とコード管理の悩み
- 2. About Me • Kentaro Kawano/@kawaken • シナジーマーケティング, TechScore • Go, Python, Rails, swift
- 3. Go歴 • 個人 – 1.2からさわり初めた – CLIツールなどの作成が中心 – Webアプリは作ってなかった • 仕事 – データ作成、チャット用ツールなど – 9月から本格的にプロジェクトに導入
- 4. チーム開発の悩み
- 5. Goのレベル上げ • 学習が必須 – 触ってる人少ない – Go Quiz みたいな教材をほぼ日で提供 • 問題作るのしんどかった – 週1回30分の簡単な勉強会 – 書籍
- 6. 情報収集 • Blog, GoCon, Advent Calendar など • 他社事例はありがたい – 参考になるし「Go増えてる感」は大事
- 7. 開発環境構築 • メンバーの環境 – 基本お任せ • 以前はVirtualBoxのイメージを配布 – よく使うツールのインストールスクリプトを作成 • golang.org/x/tools/cmd/〜 • golint,gocode などコード関連のツール • gom,fresh,gooseなどのプロジェクトで使うツール
- 8. CI/CD環境 • 新しく構築 – 既存環境の流用では上手くいかないことも • コード化を目指す（〜 as a Code） – drone.io(Docker),Ansible,Terraformなど • 静的ファイルの扱いが定まってない – go-bindata? • ホットデプロイが未検証 – 動作確認できてない
- 9. レビュー • gofmt,golintなどツールで些末な部分は回避 – CIでもチェックできる • スキルがコードに現れやすい気がする – スキル差でどうしても悪い方が目立つ • 基本的な部分の記述が増えるから？ – 教育大事ですね、みたいな意識の高まり • Go らしいコードとは何か？ – まだよくわからない – 変なコードにはなりにくい
- 10. コード管理の悩み
- 11. ライブラリの選択 • 枯れてる、メンテされてないの判断が難しい • 単純なベンチマークだけではわからない – Middleware、セキュリティ対策、セッション管理な ど • 迷ったら標準に寄せる（ムリに採用しない）
- 12. Gin • Gin最速！みたいな記事もある • 採用事例も見かける • メンテされているの？みたいなIssueもあった • contribのプルリクが放置されていたり… • 使っている人は多そうだけど、本当に大丈夫 か？ – 最悪自分たちでメンテするという覚悟で採用
- 13. パッケージ構成 • SCMにはGitLabを使用 – サブパッケージの go get ができない • 個別のリポジトリを作って対応 • 実装上の不都合はない • CIの設定などが手間
- 14. Gom • master に問題があると、ブランチの切り替え ができない – gin-gonic/contrib/sessions – aws/aws-sdk-go • 最近、一時的にmasterがビルドエラーに • 一時的にforkして修正 • 修正をプルリクしたいが手つかず…
- 15. データベース関連 • database/sqlとlib/pqで頑張ってる • drone/sqlgenを使ってみた – JSON型で使い方が合わなかった • モデル関連のコードジェネレータを自作 – ER図からモデル作成 • 検索機能などでSQLの組み立てに苦労 – クエリビルダは採用しても良かったかも…
- 16. 名前付け問題 • 冗長で似たような名前の定義が増える – リクエストパラメータ保持用のstruct • HogeRequestParams • FugaRequestParams – コード値管理用のconst • 型名を先につけて回避 – ABSuccess – XYSuccess – 共通化もできない… • パッケージを細かくするしかない？
- 17. テスト関連 • testifyを使ってassertionは簡単に書けるよう • go test – ./... をつけないとダメ • サブパッケージのテストがスルーされていた – -race もつける • 非同期処理で怪しいところが検出できる • 結果がわかりにくいのでどうにかしたい
- 18. GOの感想
- 19. 学習コスト高くない • 高くないと見込んでたけど、実際高くない • 覚えることが多くない • goroutine周りでちょっとハマった程度 – 使い方の問題 – syncパッケージで解決できると思う • 変な暗黙知がない
- 20. 開発効率も悪くない • Railsと比較して – コードを書く量は増えたと思う – 変なハマり方しない – すぐに動くモノはできない • 環境整備に時間がかかった – 最初なので仕方ない – 次からは短縮できる時間 • 今までと比べて遜色ない効率で進んでいる – 最初の方は低迷してたけど乗り切った
- 21. 運用はこれから • 実際やってみないとわからない • コスト削減につながったらという期待 – AWSのインスタンスを小さいモノに変えるとか – 今後のバージョンアップ対応の負荷
Hinweis der Redaktion
- かわのけんたろうと良います。ツイッターでは @kawaken でやっています。 シナジーマーケティングという会社でウェブアプリケーションエンジニアをやっています。 今はGoをメインでやっていて、たまにPythonを触っています。仕事ではRailsが多いですが、Goに乗り換えていきたいと思っています。あと、swiftを触っています。 週2で親会社に出向していて、天気アプリの改修のお手伝いをしています。
- 簡単に私のGo歴をご紹介します。 1.2になった頃から触っていて、CLIツールの作成ばかりで、ウェブアプリは作ってなかったです。 仕事では、データ作成やチャット用のツールなどを作成していました。 9月から本格的にプロジェクトに導入することになり、今に至ります。まだ絶賛開発中です。 JavaかGoか？みたいな紆余曲折もありましたが、なんとか画策して無事導入に至りました。 今日はこのプロジェクトでの悩みについてです。
- まずはチーム開発での悩みです
- Goのレベル上げということで、 まずは学習が必須ということです。触っているメンバーも少なかったですし、教育のためにGo Quizみたいな教材をほぼ日で提供しました。 プロジェクトが佳境に入ってからはやってないのですが、30弱問題を作りましたが、結構しんどかったです。 あとは週1回30分の簡単な勉強会でGoQuizの振り返りとか解答の解説みたいなものをやっていました。 書籍もあまりないですが、昨日、オライリーから新しいのが出ましたね！
- 情報収集は欠かさず行っていて、BlogとかGoConとかにも参加しています。AdventCalendarがちょうど色んなネタが出てきたのでありがたかったです。 他社事例などはやっぱり参考になることが多いです。そのままフィットするということはないので、参考になりそうなものを取り入れています。 外部サービスを使った事例とかすごくうらやましいんですが、自社ではそういうのが使えないのであきらめたりしているモノもあります。 あと、どこどもも使ってますね！みたいな話は上司にもやっぱり受けが良いし、 自分たちが採用したものが増えているというのはメンバーにも安心感を与えるのでありがたいです。
- 開発環境構築についてです 今までのプロジェクトでは、標準仮想環境ってのがあって、VirtualBoxのイメージをプロジェクトリーダーが調整して配布したりしていましたが、そういうのはやめました。 メンバーそれぞれの環境については、基本はそれぞれお任せにしました。 今までと同じ流れでVirtualBoxを使っている人もいるし、僕はMacで直接開発してます。エディタも特に制限無くみんなバラバラです。 golintやgomなどのよく使うツールはインストールスクリプトを作成して、簡単に共通のツールがセットアップできるようにしました。
- CI/CD環境についてですが、 今までのRailsの手法が流用できることがあまりないので、新しく構築しなおしました。 CI環境からデプロイ手法まで、一連の流れの構築が必要になりましたが、できるだけコード化したいという目的があって、 その辺を意識して環境構築を行うようにしました。 まだ運用に乗っていませんので、まだまだこれからですが、Docker、Ansible, Terraformなどで調整しています。 まだ答えが出てないのですが、CSS,JSなどのアセット関連や設定ファイルなどの静的ファイルの扱いをどうしようか悩み中です。 go-bindataでまとめた方が良いかなどうかなーという感じです。 個人で使ったときにgo-bindataでコンパイルがすごい遅くなったこともあって、ムリにまとめなくても良いかとも。
- レビューについてです。 gofmt,golintなどのツールがあるので、些末な部分の指摘は回避できています。 CIでもチェックしているので、「golintに怒られてるから確認して」で済んでいます。 ツールで指摘されない部分については、コーディングガイドを設けています。 例えばreturn値の変数名は定義しないとか。x, y int みたいな定義をしないとか。 あと、goって良くも悪くも愚直にコードを書かないといけないし、薄いフレームワークを使用しているからかもしれませんが 本来のコーディングスキルが現れやすい気がします。 そうするとどうしても悪い方が目立ってしまいます。 goだからというか、プログラミングの根本的な指摘をすることもあって、教育が大事ですね、みたいな意識の高まりがありました。 Railsだと見えてなかったところでした。 あとは、Goらしいコードとは何か？というのを探索しています。 Go自体のコードがGoで書かれているので、気になったことはできるだけコードを読むようにしています。
- 次はコード管理の悩みです。
- ライブラリの選択もかなり悩みました。 githubのスターが多いモノでも、アクティビティがなかったりするものもあって、単に枯れているだけなのか、メンテナンスがされていないのか判断が難しいなと感じます。 とっかかりとしては、フレームワークの比較記事や、こういうライブラリ採用していますみたいな記事になりますが、 単純なベンチマークだけではわからないし「○○が最速なので○○にしましょう」みたいな記事とかに踊らされないように気をつけたり、 何をしたいかによって採用基準は変わってくるので、とりあえずこれ使っとけばいいんだ、みたいなのはやめるようにしました。 あとは、ムリにフレームワークを使わないようにしました。合わないなと思ったら標準でがんばるみたいな。
- 例えば、Ginですが、 Qiitaのフレームワーク比較の記事などで、Gin最速！みたいな記事があるし、採用事例も見かけるのですが、 GitHubの方では、メンテされてるの？みたいなIssueが立っていたり（ちゃんと解答されていましたが）、contribのプルリクが放置されていたり… 絶賛メンテ中だという感じですが、GitHubでは反映されていなかったり、ちょっとオープンじゃない感じも… 使ってる人は多そうだけど、本当に大丈夫か？最悪自分たちでメンテナンスしないといけない、という覚悟で採用
- 次に、パッケージ構成についてです。 ソースコード管理にはGitLabを使用しています。 サブパッケージの go get ができないという問題があって、個別にリポジトリを作って対応しました。 実装上の不都合はないのですが、CIの設定などが手間です。
- パッケージ管理にはGOMを使用しています。 RailsでBundlerを使っていたので使用感が似ているため採用しました。 で、masterに問題があると（コンパイルエラーとか）があると、ブランチやタグの切り替えができない。 gin-gonic/contrib/sessions と、少し前にaws/aws-sdk-go でもmasterがビルドエラーになっていて、 gom installでこけていました。 回避策として、一時的にforkして修正、そちらのリポジトリを参照するようにしています。 対応策をプルリクしたいのですが、手つかずです…
- 次にデータベース関連です。 ライブラリの選定中に、紆余曲折ありましたが、最終的にdatabase/sqlとlib/pqを使用して標準で頑張っています。 drone/sqlgen というモデルからScanメソッドをラップしたようなコードを生成してくれるツールがありますが、 JSON周りでちょっと合わなかったので、使用をやめました。 ER図からモデルを作成できるコードジェネレータを自作しました。 検索機能やインポート機能の部分で、SQLの組み立てに苦労していて、 クエリビルダは採用しても良かったかも、と思いました。
- 次に名前付けの問題です。 これが一番悩ましいのですが、冗長で似たような名前の定義が増えて困っています。 例えば、リクエストパラメータ保持用のstructとか、 コード値管理用のconstで 微妙に違うモノなので共通化もできず… pythonだと1ファイル1モジュールで分けられますし RubyはModuleで明示的にスコープが分けられます Goの場合はパッケージを細かくするしかないのか？悩ましいところです。
- 最後にテスト関連ですが、 素のtestingパッケージだけではつらかったので、testifyを使ってassertionは簡単に書けるようにしています。 go test ですが、最近まで使い方を誤っていて、サブパッケージのテストが実施されていませんでした。 ./... をつける必要があります。 また、 race オプションをしようすると非同期処理で怪しいところが検出できるので、必ずつけるようにしました。 でもテストの結果がわかりにくいので、その辺りをどうにかしたいです。