# チャプター 1 トモとマサとせんちゃんのボイコード ボイシーエンジニアの声と出会えるチャンネルボイコード このチャンネルではボイシーエンジニアの日々の活動をお届けしています さっき幻の生き返りがありましたね オクラ入り 生きると思ったんですけどね、なんか不穏でした 久しぶりな気がしますね なんかオクラ取ったけど辞めた 初めてかもしれない そんなこともあるんですね 一人で撮ってるときはまあまあありますけど 話そうとしたけど難しい方に住んで 定義の話とかしようとしたら 誰も喋れなかった なんだっけこれみたいな よく分かんないって感じになりましたね 別で撮りましょうそれは 確かにちょっと勉強して リベンジマッチしましょう そんなわけで今日は 技術ワードトーク リアキテクトを話していきます 最近ちょうどせんちゃんが記事を書いていましたよね 確かに あれ個人的にめっちゃ好きで 技術技術って感じで最高でした そうかな あれ?違う? 割と思想と技術の境目ぐらい まあまあ確かに なんか結構あれじゃなかったっけ 参考にしているものとかを 丁寧に紹介はしてくれていたなっていう 印象があったんで こういうところから着想を得てるんだ みたいなのとかが なんか人から聞く機会そんなにないなと思ったんで すごくありがたいなと思ってました かなりエネルギーを消費して書いたんで まああれですもんね 人が書いてますもんね温かみのある AI使ってない AI使わずに書くっていうのをやってるんで 今回8000字ちょい書いたんですけど 全部手書きで書きました 原稿用紙20枚 確かに 結構それで言うとありますね それ聞くとめっちゃ量ありますね 個人的な話であれなんですけど 考え深いな 小学生の時とか 感想文とか書くのが 何よりも嫌いで いやー分かるな なんか図工とか音楽の感想とかも書けないし 後休みの宿題 読書感想文ずっと最後の方まで残して 母にめちゃくちゃ怒られながら 文字通りなんか泣きながら 文字通り泣きながら なんでこんなの書かなきゃいけないんだ みたいな感じでやってた子だったんで なるほど それちょっと意外です 考え深いです 中身の話いきますか その時どんな内容だったのかを聞いていければ この記事で書いたのは VCのバックエンド サーバサイドアプリケーションのリアキテクトと データベースのマイグレーション マイグレーションって言うと語弊が データベースでマイグレーションって言うと 他の意味に取られる場合もあるかもしれない なるほど データベース以降 オーロラを前に使ってたのをタイDBにしてましたって話と これからそのタイDBがどう使えるかって話 あとは実行基盤のインフラ Kubernetesの話とか AWSの話を含めたバックエンド全体の リアアキテクトの話を書いてますが リアアキテクトが何か話してないな リアキテクトって何なんだ ソフトウェアの構造自体を変える 裏側の仕組みをガッと置き換えて より今後の開発がしやすくなったり ユーザーさんが増えたりして 必要な対応が すごく量が増えたりしても対応できるようにしたり するみたいなやつです リファクタリングと言うべきか リアアキテクトと言うべきか 曖昧な時ありますよね 曖昧な時か ないですか あるんですね 今僕がやっていることとか どっちなんだろう リファクタリングなのかな ガッツリ下がってません 構造自体は全部バコッと書いてる 全部じゃないですけど 挙動が変わってないことを どれくらい自信を持って保証できるかによって 微妙に使い分けるかな 自信薄い方がリアアキですか 自信薄い方がリアアキ 挙動が変わる場合は明らかにリアアキなんだけど リファクタリングはソフトウェアのコンポーネントの 挙動を変えないまま中身だけを メンテナンスしやすい形に変える メンテナンスしやすいだけなのかな パフォーマンス改善とかも含まれてたら それってリファクタリングなのかな 詳しい人が教えてくれるかもしれない お任せします ちなみにこれなんで リアーキテクトがメインのテーマなのかな ってタイトル的にも思ったんですけど DBの話とかも入れようって思ったんですか リアーキテクトそこまで含めないと 意味がないというか 片手落ち感がすごいあって 僕が主に今社内で任せてもらってるのは アプリケーション部分の 内部アーキテクチャの改善ではあるんですけど それだけやってもあんま そこだけ見てそこだけ良くするとか ちょっと難しい どっちかというとサービスに関わってる全般の 最適化というかより良い方向に リアーキテクトしていくっていう そのニュアンスを込めたかったからっていうか やってることがそうだからっていう感じですかね 確かに データベース せんちゃん詳しいからな 詳しくないです やめてください 詳しいには怖いな じゃあちょっと分かるにしておきます 社内では詳しいです 社内ではっていう枕言葉つければ 怖がらずに言える 社内では間違いなく詳しいです なんかあれみたいですね 今までノアの話 今度のアプリケーションボイシーでは ノアという名前になってると思うんですけど ノアの話するの実はこれが初めてらしいですね 外向けに ノアっていう言葉自体を隠してたわけじゃないから みんな 例えばボイシーの個人チャンネルで コボイ構造の過去の妄想で ボソって言っちゃってるのは 隠してないから言っていいんですけど 前置き抜きで言ってるのはあったはずで 聞いたことあるんですけど ちゃんと説明しているものはなかったですね そうですよね 確かに 名前も勝手におしゃれだなって思って これは めめめみんなでするの楽しかった マサもいなかった 僕まだいなかった 多分僕が入る数ヶ月前に決まった そうなんだ みんなで募集して 投票とかしたりして 最後はエンジニアリングマネージャーたちと あとテクリドで最終決定するみたいな 感じのことがありましたね なんか ノアっていう名前もそうですし ノアで使ってる それこそこれ多分言っていいと思うんですけど コンパスとかっていう名前も結構リンクしてて なんか統一感があっていいなっていう ありがとうございます ノアは僕が付けたわけじゃないですけど この記事に書いてるコンパスとか あと何でしたっけ ゴフェルカ とかは僕が付けたやつ よくそんな関連性出てきたなって 最初からそれを見越したかのように なんかちょっとしっくりくる感じになってて 個人的にめっちゃ気に入ってる あとオリーブっていう別のプログラムありますね 創世記で出てくる オリーブどう関係してるのか 今語れないからあれですけど # チャプター 2 はい。ちなみにこのノアというのは、 どういう辛みと戦ってきたんですか? リアキテクトしているってことは、何かいろいろ辛みがあって、 それを乗り越えるリアキテクトなのかなと思うんですけど。 あんまり言うと、過去のソフトウェアに対する 恨み辛みになっちゃうんですけど。 それはそうだな。 すごい詳細話すようなもんでもないくらいあるんですけど。 逆にどういう思想で作ったのかの方がいいかもしれないですね。 やっぱ、言葉を選ぶな。 意外と難しいな。 そうですね。 言える言葉って話そうとすると、 すごい当たり前なことを言うだけになっちゃうんですけど。 いわゆる責務の分離がされていないっていうのが一番大きくて。 大体、これは前誰かが言っていたんですけど、 プログラムの挙動がうまくコントロールできないときって、 予想に反した動きをしてくるように作られているときで、 例えば名前を見たときとかに、 これデータベースアクセスしそうだなとか、 これ計算してるだけだなとか、 そういうのが明らかになっているような作りになっていて、 それを部品のように組み合わせてうまく書いてくるから、 それはAI目線とかも一緒なんで、 読みやすい方がいろいろ。 これも何してるかわからないからこれの中身を見に行って、 これも何してるかわからないから一応確認しといて、 みたいなのって人間にとってもAIにとっても非効率で、 どれがどんなことをしてるのか聞いたらわかるという状態を目指している。 そうすると忘れてよくなるんですよね。 このひとまとまりをこの名前一行に込めて、 中身を忘れていいという状態になると、 同じことやってますけど、読みやすいプログラムになる。 読みやすさがどれくらい重要なんだという話はありつつも、 人間が課題ですから。 確かに、いい絵がやってくれますからね。 でもリファクタリングしたらトークン消費量がすごい下がったみたいなのも出たりしましたもんね。 社内で共有されてましたよね、そうする話も。 そうだから意味はあると思っているんだけど。 それをすると、とプラス、 DIの話しようかと思ったけど、説明がややこしいからやらない。 自分でシンジェクションをするとか、 テストコードを書きやすくするとか。 あとは、いろんなところに同じことが書かれているので、 それを一箇所で管理するようにするとか。 それが結構つらかったところ、記憶はありますね。 今、本当に。 今も? まだです。 もうちょっと先で多分、また苦い記憶が甦ってくる。 今やっているプロジェクトで、まさにそれを直そうと想定している。 微妙に違うとかあるんで。 なるほど。 どっちが合ってるんだこれ。 確かに、後から見たら分からないですもんね。 最終的に結果は同じだけどとかも。 複雑。 途中でやっていることが全然違っているとか。 そういうこともありますね。 その話も込めてありますね、記事には。 どうしてもリポジトリが元々分かれていたから仕方ないみたいなところは あったりすると思いますけど。 確かに。 サービス向けに対してとか。 確かに。 複数のところで同じことを実装してみたいなのがあると、 必ず常に同じ状態を保つのって結構大変ですもんね。 そうですね。 冷蔵庫から汚れが出ちゃう。 確かに。 それはあるな。 なるほど。 書いてないですけど、 本質的には違うのにちょっと似てるから、 共通化されたもの。 それは。 いい加減にしてほしい。 いや、それ本当そうですよね。 これはあれですね、 トモさんがやってくれてたやつとかで見ましたね。 確かに。 僕もそういうので、 思ってた動きと違うことをしているなとかっていう感じになってしまって、 っていうのは何度か経験しているので。 そこ集約されると思ったのと違うっていう。 確かに。 ちょっと例外を設けるためだけに、 めちゃくちゃ大掛かりなことが必要になるみたいな。 確かに。 共通化した方がいいよねの時ももちろんあるけど、 目的が違うものを共通化すると結構辛いから、 そこら辺をちゃんと見極めたいなっていうのが難しいところですよね。 最近はやっぱり名前のこだわりがだいぶ強くなってきた。 確かに。 確かに。 僕雑に、 名前は全然こだわってないとかはないんですけど、 まあまあまあみたいなところはあるかなと思ったんですけど、 最近自分が思ってた以上に気にしてるなってことに気づいて、 あ、こんなとこも見てんだ自分みたいな。 やっぱり結構名前気になる人だったわっていう経験があって。 それも予想に反したことをやってくるとか、 それぞれにつながりますよね。 一番嫌いなのが何かを指し示してない子が最近嫌いになってきて。 むずい。 確かに。 ふわっとしてるとか。 あと文脈ありきの名前とかが、文脈が失われるというか知らなかったりすると見たときに、 結局一番最初から最後まで全部見ないと何をやってるかが、 何を指し示してるかがわからないみたいなのが。 すごい苦手で。 確かに。 それってコードが読めてないのか何なのかがわからなくなるなって自分の中で、 結構頭がグワッとなっちゃうんで。 最終その変数、 その変数イコールプリミティブ型のこのメソッドを使って完結してるぐらいだったりするんですけど、 この変数名イコール何かのメソッドを読んでいる、 メソッドの中を見に行く、また複雑なことをやっている、 その中のメソッドでもまた複雑なことをやっているみたいな感じだったりすると、 結局あれ?俺は今何を読んでいるんだ?みたいな。 確かに。 それが言ってた、さっきせんちゃんが言ってたあれですよね。 何をしているのか分かりやすくするというか、 そうですね。 明々に凝縮して、 あんまり深く、必要がないのに深くまで読まなくて済むようにというか、 挙動が分かりやすいようにっていう。 結構その具体的な例を言えない感じの制約のもとで今喋ってきたんで、 分かったよね。 結構これ具体であったら結構喋りやすいと思うんですけど。 ふわっとしてたと思うんですけど、 なんかそういうのを全部こうやって、 なんか要点抜き出して話すと、 結局巷にある格言に全部落ち着くだけで、 でもなんかその格言を先に見たときって、 実際どういうことしたらいいのかあんまり分からないじゃないですか。 私そんなの当たり前じゃんってなるというか。 僕が結構最近ずっと思い返してたのは、 一般的にソフトウェアとしてこうあるべきだよねっていう格言を見ただけでは人間は理解できないから、 その格言を知ってたとしても、 その格言の意味をちゃんと理解してコードに落とすっていうのは結構差があるなというか、 そこら辺にはやっぱりなんか実際に具体的にいろんなコードを見て、 自分でいろいろ考えてとか修正してみたいなのがないと、 なかなかその格言の意味がちゃんとわかんないなっていうのが結構、 自分の中でもやっていうか引っかかってたというか、ありますね。 そんな感じでいいかな。 いいですかね。 はい。 僕ら入りにした話よりは良かったと思います。 良かった。 ギミックで。 じゃあ今週はこんなところで。 次はどの声とつながりますか。 引き続きVoicyでお楽しみください。