6月 12, 2018

Go言語は突然に(3日目)

GOと言えば

最近はすっかりOculus GOが話題ですが、本記事ではストイックにGo言語の話を続けてゆきたいと思います。いえ実はVirtual界隈、特にバーチャルYouTuberついてなど無限に語り続けたいのも山々なのですが、それでは本連載の趣旨が変わってしまいますのでまたの機会に。。

というわけで久々の今回は、開発環境まわりについてのお話です。

開発環境を整えたい

連載は今回で3日目(2回+勉強会)なのですが、最初の記事でGo言語に触れてから実に7か月以上経っています。

お客様からの超特急案件を「Go言語でいいならやります!」と請けてしまったり(実践経験も積めた上にリリース直前でのプラットフォーム変更があったりして、結果的には大正解の選択となりました)、業務の合間に勉強をしたりして、確実にGo力が上がってきているような気はしているのですが。

怒涛のボスラッシュのような案件がひと段落し、次の案件の立ち上がりで若干の猶予期間ができたので、この機会に開発環境をもうちょっと良くしようと決意しました。

忙しさを理由に後回しにしていたあれこれを、ここで一気に片付けてしまおうという訳です。

ソースコード管理

今までは1人または数名での開発だったので、ファイルサーバでリソース管理をしていました。もちろんよろしくありません。ダメダメです。早急にソースコード管理を導入するべきです。

で、今はもう迷うことなくソース管理はGit一択でよいでしょう。さようならSVN、さようならCVS。VSSはちょっとだけ触ったこともありましたが、もう二度と会うこともないでしょう。。

Gitと対峙する

とはいえGitは難しいです。過去案件で指定されたブランチにcommitしてpushしてくらいはやっていましたが、達人が凄い勢いでブランチをあれやこれやしたり、手動でもりもりマージをしているのを見て、あー自分ちょっと分かってないっすわー無理っすわーと気後れしたものでした。

エンジニアを20年以上やっていて、しかも名の広く知られたシステムの仕組みが分からないと言うのはなかなかに勇気のいることですが、それでもGitは難しいと思います。いきなり理解できたヒトは凄い!あと、いきなりGitを触る人よりも、過去にSVN等のバージョン管理システムを触ってしまった人の方が罠にハマる可能性があるのかもとも思いました。(理由は後述!)

業務案件のお客様環境であれこれ試してみる訳にはいきませんが、社内で構築した環境であれば何の問題もありません。適当なLinuxサーバにGitを入れリポジトリを作り、壊しちゃってもいいやくらいの勢いで弄り倒します。

いろいろ試してみながら、Git初心者のバイブル「わかばちゃんと学ぶ Git使い方入門」を読み返していたら出てきた図で、いきなり目から鱗が落ちました。「Gitって二階層じゃなくて三階層(リモートブランチ、ローカルブランチ、ローカルにある中間のリモート追跡ブランチ)で構成されてるんだ」ということがストンと腹落ちした瞬間、一気に視界が開けいろんなことが理解できました。過去に馴染んだCVSやSVNのようにマスターとローカルの1:1の前提で無意識に考えてしまっていて、「なんかよく分からない!難しい!」という罠にハマり込んでいたようです。

詳しいことはこちらの記事の解説に譲るとして、おかげでブランチを気軽に作ったり破棄したりマージしたり、「どこまでが大丈夫な作業で、どこからがヤバイ作業なのか」というのを肌感覚的でようやく理解することができたのでした。

VSCとの親密度を上げる

Gitがなんとなくわかってきたので、今度は開発環境であるVisual Studio Codeの方も見直してゆきます。使っていて気になっていたのがディレクトリ構成や$GOPATH、$GOROOTなどをどうするのが「正解」なのかということ。

Go言語はできるだけシンプルなパーツを作り、それを連携させてゆくという言語思想があるため、作ったバイナリは他のbinと同列に置くべきなのか。git連携ももちろんさせる。go getしたライブラリのバージョンは誰が担保するのか。チームで作業するときどこまで手順化(強制)すべきなのか。あと、業務と社内試作(遊びともいう)の棲み分けは? などなど、細かい条件をすり合わせてゆきます。

いろいろ試行錯誤はしてみたのですが結局「正解」はなくて「決め」の問題なんだろうと悟り、ある程度の落としどころで手順化してチーム内で共有することとしました。

あと、VSCは非常に軽くてゴキゲンな開発環境なので他言語でも使っているのですが、そうするとどうしてもフォルダが分散してしまいます。でも、まとめるとフォルダツリーが取っ散らかって見づらくなるし、、

という地味な問題も抱えていたのですが、ターミナルで「code <対象パス>」と叩けば新しいVSCが起動するという技を知り一気に解決しました。まとめる必要なかったんですね。これで好きな場所に好きな開発リソースを置けます。

SourceTree

Gitに少し慣れてくると、あの線(ブランチ)がぐにょぐにょとした図が見たくなります。「フォークしたりマージしたり、色々とやっちゃってるんだぜ」感を確かめたいというのは人情だと思います。ということで、わかばちゃん本でも推奨されていたSourceTreeを導入しました。

これです。ここまでくるとGit初心者は脱したと言えるのではないでしょうか。

でも、このSourceTreeやVSCの拡張機能の「GITLENS」なども入れてみたのですが、これらのツールはあくまで参照用なのだなあと。オペレーションはgitコマンドでやるのが結局いちばん分かりやすく、あらゆる状況に対応できるのでコマンドをメインに使っていこうという結論になりました。(ツールが入ってないから使えない、では恰好悪いですからね)

準備万端!

までいけたかどうかはわかりませんが、少なくとも手探りでやってきた今までよりはだいぶマシになったはずです。最初から完璧に準備を整える方法もいいのですが、まずはやってみて少しわかってきたところで一度立ち止まり再整備をするというやり方も、段階的に理解が深まって良いかもしれないなと今回実感しました。

次に控える案型と、あとbotの作成など、やるべきことはまだまだたくさんあります。それでは次回4日目でお会いしましょう!

最後までお読みいただき、誠にありがとうございます。


安藤篤志

  • facebook
  • twitter
  • line
  • このエントリーをはてなブックマークに追加

アットファイブで一緒に働きませんか?

エンジニアをはじめ、複数の職種で仲間を募集しています!