サイトアイコン ENSAPIA engineering テックブログ

【第 1 回 cocone tech talk・前編】Java開発者のGoプロジェクト1年の振り返り【イベントレポート】

techstaff

こんにちは。cocone tech blog 編集長の N です。

 

https://connpass.com/event/207743/

https://techplay.jp/event/811842

 

先日 2021/03/25 に「Java開発者のGoプロジェクト1年の振り返り / 大規模リファクタリングについて」というオンラインイベントを開催しました。

弊社の『ポケコロ』のクライアントエンジニアから1名、『ポケコロツイン』のサーバーエンジニアから1名が登壇し、各プロジェクトでの取り組みをライトニングトーク形式でお話ししました。

 

本記事はイベントレポートとして、トピックと話していた内容をまとめたものを前編・後編で分けたものの前編になります。

 

 

登壇者について

 

林 賛昊（イム チャノ）さん

サーバー / ポケコロツイン開発リーダー。

NHN Japan 株式会社（現LINE株式会社）からココネに転職。その後、NC Japan を経て ココネに再度入社。

アウトドア系が趣味で、キャンプ・登山・運動が好き。ボクシングやストラックアウトも好き。

韓国のアイドル BLACKPINK が大好き。

 

目次

 

 

Go？ Project アサイン

 

チャノさんの開発言語のボリューム・何をやってきたかを示した図。

薄ら記憶から消えている言語もあるし、Unity を触ったりしていた。

それに比べて、Javaは図に見えるように、比べ物にならないくらいのボリュームになっている。

青い円が Java と言うよりは、背景が Java と言った方が近いかもしれない（経歴として）。

 

 

ある日、CTO の K さん から相談があった。

 

K「新規プロジェクトがリリース直近ですが、開発が足りないのでお願いします。できますよね？」

林「アハハハハ……^___^」

 

魂のない笑いとプロジェクトにアサインされることになった。

林「僕にとってはディープインパクトでしたね。Goという小惑星が直接衝突して絶滅の危機っていうところですね。もちろん頭の中も真っ白になっている状態でした」

 

 

しかし救いの手はあった。

アサインされる1ヶ月前に社内での Go 勉強会に参加して「Go ってこういう風にできるんだ！」と気づいて、他でも触った経験があった。

自身が（Goが）初めてということではなかったし、プロジェクトで Go の開発経験がある人からサポートを受けることもできた。

また、リリースまで1ヶ月残っていたので、CMS 作成でトレーニングを始めた。

 

 

Go の特徴

 

 

Go という壁

ポインター型とバリュー型

どうしてもGoという壁があって、最初に感じたのはポインター型とバリュー型。

Java はプリミティブタイプ以外は全て内部的にポインタがあり、意識しなくても動かせた。

Go ではポインター型・バリュー型を明確に使い分けてコーディングしなければならない。最初は慣れなくて苦労した。

 

 

 

func main() {
	var val1 int32 = 1
	var val2 int64 = 2
	
	val2 = val1 // <- compile error
	
	val3 := val2 // <- ok, 新しい変数にアサイン
	
	println(val1)
	println(val3)
}

 

nil

 

 

func main() {
	var val1 *A = nil
	var val2 *B = nil
	
	equals(val1, val2)
}

func equals(x, y, interface{}) {
	println(x == y) // 結果は false
}

type A struct {
	val1 string
}

type B struct {
	val1 string
}

 

panic

error

 

 

Go と Java の差

interface と interface{} 型

Goでは interface と interface{} 型というものがあって、差がよくわからなくて苦労した。

multiple return value

 

func main() {
	cocolonWelcomeMessage :=  "so cute!!"
	cid, ptData, err := getMultipleValues(cocolonWelcomeMessage)
}

func getMultipleValues(cocolonID string) (int32, *PokeTwinData, error) {
	// return data
}

func PokeTwinData struct {
	CocolonName     string
	CocolonThumbURL string
}

 

package

使わない変数・import はエラーになる

 

 

Goと仲良くなれる近道

 

 

まだ慣れない Go のところ

暗黙的な処理(型推論)

タイプが厳格な言語と紹介したが、暗黙的な処理もある。Go が自動でやってくれるありがたい機能だが、まだ慣れない。

 

 

 

primitive typeのアドレス参照

 

関数型変数

 

Java が恋しくなるところ

Genericsが使えない

いちいちデータのタイプをチェックして、switch ~ caseなどでこの型ならこの処理…を書かなければならない。Javaだったらすぐできる。

高度な抽象化が難しい

interface があまり強くない

interface型のConvert

いちいちタイプチェックから変換が必要……何が入っているかわかってるからやってほしい

 

 

Go で Go! Go! Go!

 

 

担当プロジェクト紹介

ポケコロツイン

 

技術スタック

Server Go
Client Unity(C#)
通信 gRPC
データタイプ protocol buffer

最近メンバーの成長が凄まじい。コードレビューの時にチームメンバーから「ここはこうですよ」という指摘を受ける（若手の成長が早くて慣れやすい！）

 

Tips

 

Q & A

Q1. エラーハンドリングについて、Golang の error 型で扱うのと、Javaのように Exceptionで取り扱うのはどちらがあっていましたか？

A1. Go で panic を ハンドリングするのがあっているのか、errorをハンドリングするのがあっているのかということでしょうか。

 

Java は Exception が発生したら try ~ catch で拾って処理して JVM 側に戻すこともできるし、止めて次の処理に流すこともできます。

Go でも同じく、panicが発生した場合、defer {~ recover{} } で拾って、panic を投げて処理を終了させることもありますが、プロセスが死んでしまうこともあるので、error 型に変えて返すというパターンで実装しています。

 

バッチ処理など、プロセスが止まっても良いものであれば、panic を投げれば処理が終了するのでそれでも問題ないですが、プロセスが死ぬ時に何もログなどを残せないので、あとでなぜ死んだのかを追えなくなります。

なので、panic は処理をしてから error にするのが正しいかなと思います。

Q2. （Q1補足）Goでは panic を使わずに if error で関数から error を返却するのが一般的ですが、panic の方が使いやすかったですか？

A2. わざとpanicを発生させる場合があります。

システムエラーなどの場合はpanicが発生する（処理上発生する）ので、defer ~ recoverを使って error に変換して次の処理に続けています。

panic の方が使いやすいなどということはないですが、プロセスが死んでしまうので、必ず処理しなければならない場合があります。基本的にわざと panic を発生させることは少ないです。

 

スライド

 

 

レポートは以上です。

 

まとめ

今回は Java 開発から Go 開発に移行したエンジニアの 1 年の振り返りをご紹介いただき、レポートとして掲載いたしました。
私は特に「Go の壁」と「Java と Go の違い」を興味深く感じました。ここを抑えていけば Go と早く仲良くなれそうだなと、楽しんで聞くことができました。
これから Go を学ぶ人の参考になると思います。

後編ではポケコロでの大規模リファクタリングについてをご紹介します。
100 万行を超えるスパゲッティコードのリファクタリング……気が遠くなりそうですね。

 

後編：

【第 1 回 cocone tech talk・後編】大規模リファクタリング〜100万行超えのスパゲッティコードからリファクタリングする際やるべき9項目〜【イベントレポート】

 

 

また、ココネでは一緒に働く仲間を募集中です。

ご興味のある方は、以下のリンクから是非ご応募ください。

 

ココネ株式会社 採用情報

サーバーサイドエンジニア（ジュニア）

サーバーサイドエンジニア（シニア）

 

モバイルバージョンを終了