Eureka Engineering
Published in

Eureka Engineering

「事業を止めない技術改善の取り組み」というテーマで登壇してきました

7/20 に株式会社 KAUCHE さん、株式会社令和トラベルさんと合同で開催された「【Backend LT会】3社が向き合う解きがいのあるイシューとは」というイベントにスピーカーとして参加してきました。

当日は私 emahiro が「事業を止めない技術改善の取り組み」というテーマで、また Eureka のインターンとして 2023 年の入社が内定している satorunooshie が「動画合成アーキテクチャを実装してみて」というテーマで発表してきました。

当日発表した資料は以下になります。

satorunooshie は当日発表した内容についての詳細をまとめたエントリも Eureka Engineering に公開してるので動画合成アーキテクチャの詳細については以下のエントリも併せて読んでみてください。

「事業を止めない技術改善の取り組み」についての補足

当日はかなり駆け足で発表を進めてしまったこともあり、少しだけ当日のスライドについての補足を書きたいと思います。

登壇者間でも「ここってどうなってるんですか?」といった登壇内容に関する質問をいくつか頂いたので、Q&A 形式でこのエントリで公開したいと思います。

Q1. 魔改造Ginはどの辺が辛くて、生産性を落としていたのか?

いわゆる “Storing context in structs leads to confusion” (※1) のパターンで実装されていたため、Context がどこから伝播されたものなのかわからない、という問題がありました。

特に Context の中に色んなものが入っており、API のテストが書けない阻害要因になっていました。API の振る舞いのテスト書けない、という状況が続いていたことで、remote の開発環境にデプロイしないと簡単な API の振る舞いも検証できず、開発の生産性を落としていました。(※2)

※1. “Storing context in structs leads to confusion” については以下の Go の公式ブログに記載されています。

※2. 開発環境へのデプロイは当時10分以上かかっていて、待ちが発生してました。現在は CI の改善も入れていますが、それでも時間がかかってしまっており、手元で振る舞いを検証できる E2E の仕組みは想像以上に開発のスループット改善に貢献しました。

Q2. 取り組みに反対するメンバーや他組織はなかったか?どう合意を得たか?

※ これは登壇後の Q&A でもお話しした内容なのでその通りに記載させていただきます。

A 2. 前提として Eureka の Back-end Team には Feature の実装を生業とするチームと今回登壇で発表させていただいた改善を生業とするチームの2つがあります。今回テーマとしてお話させていただいている改善を生業とするチームは、そもそも Pairs のような既に莫大なユーザーを抱えていて、大きな事業を支えてるコードベースそのものに手を加えていくことにモチベーションを感じるメンバーが揃っているので、チームの中で反対といったことはありませんでした。

一方で、仕組みの構築や改善計画立て、といったことは改善チームの方で行いますが、実際に改善作業を行う上では Back-end Team 全体として行う(つまり手伝ってもらう)ことが必要になります。
ここでは、「改善をやっていく」ということをチームの合意事項として決めていたので、モチベーションの有無はあまり関係なく、アサインされた issue を個々人のタイミングを見計らって進めてもらいました。
事業に関わる開発の進捗状況に応じて取れる時間は変わってくるので、改善タスクをいつやるか?はメンバー個人に一任していました。ただ、全体としてのスケジュール管理は改善チームが担当しました。

まとめると「チームの合意なのでやらない理由は特にない」ということになりますが、最小コストで済むような準備は改善チームとして行っていました、という話になります。

また他組織に対してどう合意を得たのか?という話については、「得てない」が解答になります。得てない、というより、そもそもアプローチとしては事業に影響がない範囲(自分たちでコントロールできるリソースの範囲)で進めることにしていましたし、そのために仕組みを作っていたので、わざわざ他組織の合意を得る必要もなかったという話になります。
もちろん CTO の kaneshin さんには予めこういうことするよ、とは伝えていましたし、ORM のアップデートや AWS SDK を入れ替え、といったものになればインフラ基盤に影響が出る可能性があったので、Eureka でインフラ基盤を管理してる SRE チームには頭出しをしておきました。

Q3. Routerを入れ替える時は、全ての handler を標準Interfaceに書き換えてから1度でリリースしたのか?何らかの工夫で handler 毎に小さくリリースできたのか?

静的解析で書き換えるツールを作って一気に置換しました。
ただし、順序としては先に社内で使用している管理画面の API 群を差し替えて、Router を入れ替えても問題ないことを確認した上で、本番の Pairs の API の Router を一気に差し替えました。

Q4. 「ドメインロジックの単体テスト→ControllerレベルのE2Eテストに移行」のところで、単体テストの方は捨てて、E2Eで同じ内容のテストケースを担保したのか?

A4. これは「はい」です。単体テストは原則これ以上書かない(つまりは捨てる)ことにしました。E2E テストの導入時に一緒に単体テストも消すと言ったことはしませんでしたが、今ある以上の単体テストは原則書かないことにして、API のテストに全て寄せました。

既存の API に手を加えるときは API のテストでドメインロジックの単体テスト結果をカバーできる場合に、重複してテストがあっても無駄なので、消す、と言ったことをしています。

Q5. 単体テストは残して、ドメインロジック以外の部分を中心にE2Eテストするなどの棲み分けをしたのか?

Q4 の回答とも重複しますが、重複してる E2E で担保できるよね、というものはテストごと消してます。
テストの実行時間も無駄ですし。棲み分けについては、例えば日時でフィルタしたいと言った細かいロジックについてはドメインレベルで単体テストを残してるものはあります。
ただ、基本的には E2E に全て寄せる、という方針をとっています。

Q6. xormで使いたかった機能が何か気になります。

細かいですが、EngineGroup という仕組みになります。
Wizard で実現したかった仕組みをこの EngineGroup という仕組みで公式の xorm が提供していたので、Wizard を離脱してこの機能を使っていきましょう、となりました。

以上になります。

実は今回発表した内容のベースはスライドの中にもリンクがありますが、昨年の Eureka Engineering で開催された Advent Calendar のエントリにメインの実装者の daisuzu が投稿しています。面白い内容なので併せて読んでみてください。

最後に

登壇した内容についての補足も込みでこのエントリを記載しました。
もっと質問してみたいことや、ここってどうなの?みたいな気になることがありましたら emahiro まで気軽に質問をください。メンションでもDMでも大丈夫です。

今回の登壇内容に限らず、Eureka の Back-end Team についてもっと知りたい方や Eureka のエンジニアリングについて知りたい方も気軽に連絡して頂いて大丈夫です!

ではまた 👋👋

--

--

Learn about Eureka’s engineering efforts, product developments and more.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store