今日話すこと 21新卒 Garoon開発の羽田です。 Garoon配属後にやったことと、そこで感じたことについて話します。

名前 羽田 智史 (はねだ ともふみ) 出身大学 会津大学 大学時代 SI企業で4年間アルバイト Java/SpringでWEB業務システムを開発 趣味 筋トレ サイクリング ゲーム カメラ 最近ハマっていたこと 自作キーボード mint60 つくりました、ついでに無線化しました

配属 7月からGaroon Odangoチームに所属 改善や技術のタスクのハンドリングをするチーム 配属を希望した理由 新規開発はアルバイトで経験してきたので、経験したことのない改善系や大きめの タスクをやってみたいと思った

配属後にやったこと Garoonチュートリアル (7月上旬~中旬) 簡単な画面を作る オンプレ版のインストール, アップデート Garoonの機能を触る はじめてのおつかい (7月中旬~8月末) 同期メンバーとモブでタスクを行い、一通りの開発プロセスを学ぶ バグ修正3つ, +α UnitTestの副作用修正(後述)

はじめてのおつかいの所感

バグ改修

レガシーなコードが残っているために、問題のコードを探すのが大変な場合がある 1メソッド, 1ファイルがとにかく長い 変数に何の値が入っているか分からない 変数の生成先がめっちゃ深い メソッドを呼んでいる -> 200行くらいのメソッド -> さらに入れ子でメソ ッドを呼んでいる -> 以下ループ コードは読まずに、デバッグして実際の値, 動作を見た方が早い 既存のコードがテスタブルではないため、UnitTestが書きづらい global変数, static変数, コードが長い など 小さなバグを一つ直すのでさえ、Garoonだと数日かかる場合がある

UnitTestの副作用修正

CI上では問題ないが、ローカルでは失敗するUnitTestが存在した ローカルでUnitTestを全体実行した時、同じプロセスで実行するため、あるテストの副 作用が別のテストに影響を与えてた 副作用が起きるケース: あるテストでグローバル変数がモックに置き換えられていた。 継続して実行される次のテストではモックではないグローバル変数であること を前提としている。 だが、前のテストでモックに変わっているために後続のテストが失敗した。

CIでテストを全体実行しているが、独立したプロセスで実行されるため問題は起きてい ない 独立したプロセスで一つ一つ実行するため時間がかかる もし副作用による問題を修正できれば、CIでも同一プロセスで実行できるため、実 行時間が大幅に減る 副作用を起こすようなコードはよくない クラス, インスタンスが状態を保持する, グローバル変数を使う 副作用が起きてしまう場合は、後処理をする テスト用に値を変更したのであれば、元に戻すことが大事

結果どうだったか 数日かけて副作用を治して、ローカルでUnitTestが動くようになった CI上ですべてのテストを同一プロセスで動くように設定を変えたところ、テストが 動かなかったため、実行時間の短縮はできなかった 期限も来ていたので諦めた Garoonは甘くない

まとめ Garoonで開発をするのは大変 その分やりがいがある 大変だからこそ、Garoonをもっと良くしていくためには？ということを常に考えるよう になった 良いコードの書き方, レガシーコードの改善について探求していきたい プロダクト全体で改善に対する意識が高く、先輩たちのテクニックや考え方が勉強 になる

これからもGaroonで頑張っていきます！！！ 終わり