第90回 Ruby関西勉強会で登壇&会場提供した

こんにちは！@shutooike です！

今更ですが、2023/3/25 に開催された第90回 Ruby関西勉強会で登壇&会場提供した話をします。

rubykansai.doorkeeper.jp

登壇

弊社の内部品質を向上させるための泥臭い取り組み（FactoryBotを整備したり、自動テストを書いたり、ライブラリをアップデートしたり、リファクタリングをしたり）について話しました。

先にまとめを置いておきます。

まとめ

自動テストは書かないと上手くならない
- 勘所を掴むまでクソテストコードを書いて書いて書きまくれ
- 幸いテストコードは書き直しやすい
レガシーコード改善に銀の弾丸はない
- カバレッジも可読性、メンテナビリティも突然上がることはない
- 理想に向けてロードマップを引き地道にやっていくしかない
レガシーコードを愛する
- ユーザーの課題を解決し、売上を立てるレガシーコードは偉大
- なりたくてレガシーコードになった訳じゃない
  - その時々の最適解だったはず
- 恨みではなくリスペクトを持って接する

興味があれば登壇資料もご覧ください。

speakerdeck.com

質疑応答も覚えてる範囲で残しておきます。

質疑応答

テストを書いていくのは辛いと思うが、どのようなモチベでやったか？
- 自分たちの理想に辿り着くための重要なステップとして進めていった
- ある程度テンプレート化して頭を使わなくても書けるようにした(＝作業化した）
機能開発との配分はどのように進めましたか？
- 最初は毎月第1週を負債返却週間とする制度があり、その中で自分はテストを増やしてみた
- スライドにもあるプロジェクト発足してからはチームを組成（自分+週2日稼働の業務委託1名）
- （いつの間にか負債返却週間は立ち消える...👋）
- その後開発組織の拡大に合わせてチームメンバーも2人増えて合計4人（自分+週2〜3日稼働の業務委託3名）
- ふりかえってみると結果的にどの時期も全体のリソースに対して20％ぐらいが割り当てられていた
POや経営層とどのようにコミュニケーション取りましたか？
- うちの場合は経営層も技術に明るいのであまり説明コストが掛からなかったのは有り難かった
- 開発組織に求められているもの（品質とスピード）は内部品質を上げることによって獲得できるよというスライドを作ったりはした
始めたモチベーションは？
- Rails チュートリアルのTDDからソフトウェア開発に入門していたので、テストが書かれていないのがカルチャーショックだった
- コードの変更に対する心理的安全性が低すぎた