00:02
ということで、LayerX NOW!第12回ですね。
前回の終わりにも言いましたが、今回もまたyoshikiさんに来ていただいて、
今回はちょっと技術ネタをね、いっぱい喋っていきたいなと思っております。
始める前にですね、まずLayerX NOW!の目的といいますか、
この番組の趣旨についてご説明させていただきますと、
この番組でLayerX NOW!では、LayerXの開発メンバーとか、
その組織の中でどういうことを今やっていて、
その等身大の姿を知ってもらいたいなというところで始めた番組となっています。
特に知っていただきたいのが、ブロックチェーンだけじゃないLayerXという姿をですね、
できればいろんな方に届けたいなというところで、お話をさせていただいております。
今回もですね、前回引き続きyoshikiさん、よろしくお願いします。
はい、お願いします。
yoshikiさん、今回話してもらいたいのが、
僕らのプロダクト、ほとんどがyoshikiさんのコードベースになり立っていると、
言っても過言じゃないと思ってるんです。
そこまでは言いすぎな気もありますけどね。
Goの設計思想とかって、どういうツールを使おうかとか、
特に例えばORマッパーのところとかは、
どちらかというとyoshikiさんがフォークしたものを使ってたりするじゃないですか。
そうですね。
ああいったものを見ていて、我々のGoのソフトウェアの設計思想の
すごく深いところにyoshikiさんの考え方もあるなと思っていて、
その辺をちょっと聞かせてくださいって感じでした。よろしくお願いします。
お願いします。
yoshikiさんから見たレイヤーXの各チャース事業の
プロダクトの設計思想についてまず聞いていきたいんですけど、
どういうことを考えてこのプロダクトを開発進めていったんですか、最初。
そうですね。最初考えたこととしては、
結構隙間駆動というか、隙間ドリブンで開発していけるのがいいなと思っていて、
あとは自分が今まで慣れた開発手法とかっていうのは使っていて、
あとは自分が書いててちょっとこれ厳しいなって思った箇所に関しては
修正を入れながら作り始めたのが去年って形ですね。
割とGoもかなりの年数書いてきたのに、
ある程度自分の中にナレッジが溜まってたっていうのがあったので、
最初はそれをふんだんに入れて開始していったって感じはありますね。
そうか、ずっと前職から考えるとだいぶ長く使われてますもんね。
5年くらいかけてますかね。
5、6年やってる気はしますね。
昔Goの勉強会とかしたの懐かしいですね。
そうですね。前職で一度やったあれはありますね。
03:06
あとは結構5、6年前とかGoカンファレンスとかも何回か行って、
最近はあんまり顔は出せてないんですが。
あの辺はまた行きたいですね。
ですね。ちょっとブランクが空いてしまいましたが行ってみようと思いますね。
やっぱり書いてる量は相当あるんで出せるネタはいっぱいあると思うんですけど。
特にさっき最初に出てきたのがスキー戻り文ってキーワードだったんですけど、
スキー戻り文を取ることにした理由というか目的みたいなところだったんですか?
そうですね。最初に元々考えてたのは人間が書く箇所みたいなのは減らしたいっていうのは1個あったりはしてて、
例えばストラクトなフィールドだったりとか、もしくはJSONのタグとかっていうのを人間がポチポチ書いていってメンテしていくのって結構やりたくないなっていうのは元々思って、
自分でもやりたくないし、絶対自分も書き間違いとかどっかで起こすし、
スイカで入った人ってこれもしかしたら間違ってる可能性がありますみたいな担当ができないとかっていうのもあんまり長く続けていく上で、
良くないなっていうふうには思ってたりしたので、
そこで最初にスキーマークファイル的なものを自分たち考えて定義して、
そこからある程度のコードを生成して開発入っていくっていうスタイルが自分は良いなっていうふうに思っていて、
それは最初に入れようと思って、今も継続してできてる場所かなと思います。
そうですよね、型のシステムを持った言語を使ってることが我々多いので、
スキーマー駆動っていうかスキーマー使って書く型を生成して、
間違ってるところはシステマチックに炙り出そうっていうのは結構スピード速くなるっていう意味でもいいですよね。
ですね、あとはレビューがすごい明確になったりしますね。
このスキーマーでやっていきますっていうのを最初に宣言として書けるっていうのは、
自分の頭の整理もなるし、見る人にとってもこういうことをやろうとしてるんだなっていうのが分かりやすかったりするので。
確かにこういうAPIですっていうドキュメントから先に入るわけですもんね。
そうですね、あとはそういうコードをGoで書くのすごい退屈だったりするので、
そこらへんは生成したものを使うっていうのが一番自分としてはしっくりきてたっていうのはありますね。
GoでこういうAPIのハンドラー的なものを書き始めるとむちゃくちゃタイピングマラソンになっちゃうんで。
もしくはそれをやらないとあまり再利用性のないコードが多かったりして。
結局Web APIがやることってインプットを与えられて、
それをどこかしらのデータストアに扱いやすいフォーマットで保存していくみたいなことがメインの処理だったりするので、
06:05
その入り口になるインプットもHTTPのリクエストだったりとか、
もしくはその出口になるデータベースの設計とかっていうのは先に決めてしまって、
そこに入れるためのGoのデータモデルとかストラクトだったりっていうのはもう自動で作っちゃうっていうのが自分的にはしっくりくるなっていうのは思っていますね。
究極的にはインターフェースに渡ってきたオブジェクトをデータベースのオブジェクトに翻訳してあげて終わりみたいな世界ですもんね。
そうですね。内部の処理はあとはそれを自分で何かを書いていくっていうのが明確になるのでいいですね。
確かにその方がテストもしやすくなりますしね。この型のオブジェクトが渡ってくるっていうのをサーキットレイヤーに渡してみてほしい。
GoのAPIの格にあたって結構クリーンアーキテクチャーっぽいものの設計とかもされてるじゃないですか。あちこちのリポストリ見てると。
そうですね。
この辺の設計思想というかどういうことを考えて設計していくのかみたいなのが結構論争になるじゃないですか。
このGoでどういうパッケージ区切りをしていくんだみたいなところで。
確かにそうですね。
ここら辺はそうですね。自分が書いてきたものが大部分にはあるっていうのと、
あとはあんまり最初いきなり複雑すぎて入るのは、どのプロジェクトでもそうですけどいい判断とは思えないので、最低限でしようっていうのは最初に決めていましたね。
あまりに複雑すぎるというかパッケージを切りすぎるとかそういうことはあんまりやりたくないなと思ってましたね。
はいはいはいはい。これ高谷さんもおっしゃってましたよね。最初はとにかく最小限で作ってだんだんと拡張していくみたいな発想で作るみたいな。
ですね。最初ベースをイニシャルコミット、Gitにイニシャルコミットしていく時にも、
Mosaさんとかにすごい急かされて始めたっていうのは結構あるかもしれないですけど、
まだミニマムな形でスタートさせていくというのは最初からありましたね。
でも思想統一はいいですよね。そうやってみんなが同じこと考えて作ってる。
ですね。ある程度、Goのコードを書き始めてから事業が大きく変わるとかっていう形はあんまりなかったりはしたんですけど、
なるべく早く立ち上げるというか、最初のカスタマーになる自社でどれだけ早く使えるかみたいなのは結構最初から意識されてたところです。
やっぱり未知のものを作ってると、正直完璧に作って無駄になるよりは、多少アラがあっても進めて、
その時に引き返しやすいアーキテクチャであることぐらいを担保するのが大事かなってすごい同意しますね。
そうですね。だから最初書き始めた時は、このサービスってこのドメインというか、
09:04
ドメインでいいんだっけみたいなことを迷いながらでもコミットはしてるみたいな状態で進めていってましたね。
もちろんそれで間違ってる箇所もあったりするので、それは途中で修正して直してみたいなことをやってましたね。
やっぱり最初経理の業務、分かってたコードを書く人が経理の業務についてのドメインがあったわけではなかったので、
その段階からある程度こうだよねっていうのを確かめながら進んでたのを最初は見ましたね。
未知に対して向き合う時に最小構成でさっさと始められるっていうのは、スタートアップの技術選定って大事だと思うんですけど、
その点で言った時にGoってどうなんですかね。サクッと書けるっていう意味では僕はすごく好きなんですけど、
人によってはすごい冗長だみたいな話もあるじゃん。
吉木さんはこれがどの辺が好きなのかなと思って。
そうですね。一番自分がいいなって思ってるのは、Goのコードを読むのがあんまり苦痛な箇所がほぼないっていうのがあります。
困ったらパッケージの中読めばいいし、使うライブラリについてもある程度中身のコードとかを見て、
こういうことやってるんだみたいなことをサクッと読めるので、そこが自分として一番いいかなって。
困ったらコード読めって言えてしまうぐらいのシンプルさっていうのはあるかなと思います。
わかります。表情パッケージすらほぼGoで書かれてるんで、
HTTPパッケージのヘッダー周りで困った時にずっと読んでたんですけど、すぐ読めますもんね。
ですね。なんで一番Googleって解決っていうよりかは、中のコードを見て解決っていうのが自分の中で一番多かったりしますね。
そこら辺はすごいいいなっていうのは思いますね。
でもコード読んで解決するって本当はエンジニアの基本的な振る舞いなのかもしれないなと思うんですよね。
ですね。そうな気はしますね。
いいコードってやっぱそこから学ぶじゃないですか。使われているツールのコード読んで、
こんな感じで書いてこんな感じでテストするんだみたいな発見って、僕Goを始めた頃やっぱそんな印象がありましたね。
そうですね。あいにスタックオーバーフローとかを読むよりも絶対コード読んだ方が早いみたいな感じはすごい感じてて自分も。
なのでGoogleよりもエディター内で定義ジャンプでどんどん関数飛んで遡っていくとかっていうのがメインになってきますね。
書き方のバリエーションが少ないっていうところからやってくる読みやすさですよね。
ですね。
一方で今後GoのGo 2.0とかそれ以降のバージョンってGenerics入ってくるじゃないですか。
はい。
あの辺ってこの環境変わりそうですね。
そうですね。なんかでも1.7のGenericsのドラフトみたいなのも読んだりもしたんですけど、そんなにこうファットというか扱いに困るかなっていう感じはあまり受けなかったりはしたので、
12:07
そこはちょっと2.0の方がどれくらい変わるかは読めないですけど、そんなにこう自分としてはデメリットには感じてないというのはありますね。
まあなんかアレイの処理が簡単になるぐらいだと嬉しいですね。
そうですね。
もうフォーブ回しまくるの疲れたよって。
そうですね。なんか同じこのコードもう何回書いたんだっていうことがやり始めるとすごい増えますので。
なんかアレイの中から検索するとか、フィルターするとかめっちゃ書きますよね。
ソートするとか、ソートはなんかブラッドフィッツさんの書き方が入ってきてからは割と楽になりましたけど、ファンクションを出せるようになったやつ。
はいはい。
5.2.0とか5.1.7とか来たら、1.17とか来たらさっと入れてはみたいですね。
そうですね。
今もそんなに困ってるって話ではないですけど、やっぱりキャッチアップというか追従は絶対必要になるので。
それがもし理由になるとね、ついていかざるを得なくなる時期が後にやってくると辛いですからね。
いやそうですね。それはありますね。
マイSQLのバージョンがどんどん上がっていって追いつけなくなったみたいな辛い話をするのは嫌ですからね。
そうですね。
それで言うとまだこのプロダクトは始まって1年、まだ経ってないぐらいだったりはするので、結構モダンな形では始められたっていうのはありますね。
やっぱり5,6年経ってると痛む箇所はあったりすると思うので、どんなプロダクトでも。
やっぱりパッケージの考え方とかテストの考え方はやっぱり5年でだいぶ成熟しましたよね。
そうですね。すごい変わりますね。変わりましたね。
あと周辺ツールいっぱいあるし。
このGoの開発とか、サーバーサイドとか、プロダクト全般でもいいんですけど、ここから1年、よしきさん的にはこの辺挑戦していきたいなみたいなところってあったりします?
そうですね。やっぱり若干ビジネスロジック、最初に書いたロジックみたいなのが複雑だったりするので、もうちょいそこら辺はリファクタリングの余地みたいなのがあったりはしてて、ただいかんせん今手が回ってないというか、
ここをやりたいけど分かりつつ残したまま新しいところに入っていくみたいなのが、今のメンバー的にこういう形になってたりするので、
どっかで綺麗に今後増えていく人に対しても分かりやすい箇所を作っていきたいなと思いつつ、技術的なところでいくと、今まさにやってたりするんですけど、
もうちょっと、そうですね、さっき最初に話したGoで行動ジェネレートする箇所とか、そういう箇所をだんだんもうちょっとだけ増やせたらなっていうのは考えてたりはしますね。
15:07
今はプロトコルをGraphQLに移行したりもしてるじゃないですか、それ以外のところもってことですか。
ですね。中で使うデータベース、データベースに入れる値ではなくて、多少ビジネスプロジェクトが必要な箇所とかっていうのも、今まさにやってる箇所とかはあったりしてて、そこはもう少し使えたらなって思ってたりしますね。
特定してしまうと、例えばユーザーの権限周りとかのコードの部分とか、どういうふうに権限っていうのを定義して、どういうふうにリソースアクセス止めてみたいなのを設計っていうのを多少やってたりするので、そこら辺は生成したコード一部で使ってたりはします。
確かに、別なドキュメントか何かで定義した権限リストに従って勝手にコードでブロックしてくれてるみたいなのは言われてる。確かにかっこいいですね。
すごい具体を言うと、スペックを定義して、そのスペックでアクセスが許可されているか否かっていうのは宣言的に書いておいて、それでアクセスがあろうになるか否になるかは、生成したコード内の手を使って判断するというか、そういう箇所は今まさにやってたりはします。
具体的にはどのレイヤーにジェネッタコードが入っていくような設計になってるんですか?聞いてる人のイメージを膨らませるために。
レストのAPIとかだと、APIパスによってリソースっていうのが決まっていると思うので、そのリソースパスと権限を先に決めておいて、このユーザーっていうのはこのAPIパス入ってもいいかどうかっていうのは定義から判断されたコードでミドルウェア内でハンドルされるとか、そういう箇所だったりしますね。
じゃあスワッガーの定義ドキュメントから、スワッガー.yamlとかからそういうのをジェネってくるみたいな。
ですね。あとはこのデフォルトの権限ってどういう、どのアクションはしていいんだっけとかっていうのを定義で書いておくっていうイメージですかね。
ここら辺をステック書いたら人に書かせないみたいな思想を感じますね。
ですね。なので最初に吐き出す、ジェネレートするコードの設計を間違うと結構後戻りが大変なことになってしまうので、そこはちょっと頭を使いながらかなと思っています。
それも結局最初にやりたいことが明確に決められるものだったりするので、スペックとして書いておいた方が後々楽だろうなと思いますね。
18:05
あとスペックを見れば振る舞いが予測できて、今度は品質保証にも行かせたりとか。
最近オーティファイでめっちゃ自動化したりしてると思うけど、あの辺にもドキュメントを渡せばすぐオーティファイの方でもどう書いていくべきか理解できるみたいなのはいいですよね。
そうですね。いいですね。スペックファイル書くと人間が読む分にも優しい箇所はあったりするんですけど、一番いいのは機械がそのスペックを解釈できるっていうか、
ここはなんかすごい自分としては書いてて楽しい箇所というか、うまいことこのスペックからGoのプログラミングを使ってまたGoのコードを作るみたいな、そういうことをやる時間は楽しかったりしますね。
ここから多分時間が進んでくるとどんどん人は本当ビジネスロジックそのものに集中していって、それ以外はもうスペック書いたら終わりますみたいな。
ですね。なんかその世界早く来ないかなっていうのはちょっと思いますね。
なんか来ないかなというよりは作ってるあたりが。
そうですね。進んでいくのは。やっぱそこがあるべきというか目指すべき姿かなとちょっと思ったりはしますね。
なんか不要意に人間が書いていくっていう意味ではなくて、ある程度生成したものの中でできない箇所だけ自分が書くとか。
そういう基盤はちょっと整えていきたいですね。
あとはこういうことに楽しさを見出してくれる人には普通に来てほしいですね。
そうですね。あれを考えながら作っていけると思う。
なんか多分3、4年前とかに考えたGoの書き方とは全然違う世界になってるじゃないですか。スペック書いてじゃねって、あとはちょっと乗りづけをするみたいな。
はい。
そういう新しい地平を切り開こうぜみたいなのはどんどんやっていきたいですよね。
結構Goカンファレンスの界隈とかみんなGoジェネレートずっと研究してると思うんですけど、どんどんうちの事業でもやっていきたいですね。
そうですね。なんか本当によくあるHTTPを生成するとか、データベースの隙間からスプラット作るとかっていうのは結構もう汎用というか割とメジャーな手段にはなってきてると思うんですけど。
ある程度さっき話した権限とかちょっとだけビジネスのドメインが関わる箇所も作っていけるのが見たらいいなっていうのは考えてますね。
しかしこうやって話していて、もう全くブロックチェーンの話が出てこないあたりが、ブロックチェーンじゃないよっていう会社になったなって感じがしますね。
すいません。ちょうどお時間が近づいてきてたんで、後ろの予定もあるかなと思ったので、この辺にしようかなと思ったんですけど。
そうですね。一緒にGoでどうあるべきか、我々の設計とはこういう風にあると、よりお客さんの価値を届けることに集中できるよねみたいな。
21:04
そこに集中できるための基盤を作っていくことが面白いと思ってくれるエンジニアだったらすごく楽しいんじゃないかなって雰囲気を勝手に感じました。
最後、吉木さんから伝えておきたいこととか、こういう人来てほしいなとか、こういうポジションが欲しいですみたいなのがあれば。
そうですね。もちろん正社員でのエンジニアの採用とかもあったりするんですけど、ビジネスサイドもエンジニアサイドも最近、ちょうど先週インターンの開始とかもあったりしたので、
ぜひインターンで入りたいみたいな。自分もそうだったので、大学のインターンからエンジニアとかのキャリアをスタートしたので、興味ある人はぜひという風に思いますね。
いいですね。ぜひ一緒にGoを書きたい学生さんでもいいですし、一緒にビジネスやりたい学生さんでもいいですし、インターン来てほしい。
そうですね。
ありがとうございます。
ありがとうございます。
というわけで、レイヤーXNOW第12回、前回に引き続いて吉木さんに来ていただいて、今回はGoのお話をさせていただきました。ありがとうございました。
ありがとうございました。
では。
