Motivation Cloud のエンジニアをしています、宮田と申します。
先日、和田卓人（t-wada）さんにMotivation Cloudの開発者向けに効果的なリファクタリングをどう行なっているかに関してワークショップを開催してもらいました。
本記事では、当日のワークショップの様子や、その後の社内の変化をお伝えしたいと思います。
なぜワークショップを依頼したのか？
弊社では複数のSaaSを提供しています。
最も歴史があり大きなMotivation Cloudではテストコードのカバレッジはそれなりに高い数値を維持していますが、ドメイン貧血症に当てはまるコードも出ており新規で参画するメンバーが仕様を把握するのが困難になってきました。
開発者体験を上げていきたいと組織全体で考えておりFour Keys Metricsに基づいて生産性の向上に取り組んでいますが、並行でより良いコードにリファクタリングしていきたいと考えています。
そこで数々のプロダクトをTDDを駆使してリファクタリングしてきたt-wadaさんに安全にコードを改善していく方法についてレクチャーをお願いしました。
当日の流れ
当日は、10人のエンジニアが10時から16時まで座学と実習を受けるという流れで実施されました。
講演編
最初は以下の資料に沿って講演をしていただきました。
テストがないレガシーコードを具体的に改善していくかについて説明されています。
個人的には以下の言葉が印象でした。
- レガシーコードとは「テストコードのないコードのことである」
コードを変更するためにはテストを整備する必要がありますが、テストを整備するためにコードを変更しなきゃいけないデッドロックに陥ってしまうことがある。これがレガシーコードになる
そんな時は「最初に大きく外から包んだテストコードを書く」と「テスト無しで安全な範囲でコードに穴を空けていく」というアプローチで改善してく。
- テストで品質は上がらない。 テストはあくまでも品質を上げるきっかけ。品質を上げるのはプログラミング
テストコードを書いたから品質が上がるわけではない。
実際にテストコードを書いたらt-wadaさんは「よし、これでレガシーコードに戦いに行く準備が出来た」と言っていました。
自分は講演に用いられた資料を過去に見たことがあったのですが、作成者がライブで説明してくれると理解が段違いで捗りました。
また、t-wadaさんが「参加者がチャットで盛り上げることでオンラインはリアルを超える」と話しており、オンラインでも盛り上げる工夫を随所に散りべめてくれていました。
小さなコメントも拾って返信してくれたり、質問の内容をその場で深掘りしたりしてとても楽しい時間でした^^
ライブコーディング編
講演の後はt-wadaさんが実際にレガシーコードをライブコーディングでリファクタリングしていく様子を見学しました。
思考を全て話してくれるので非常に参考になりました！何だか自分でも出来そう気がしてきます。
見学しながら意見を言ったりして前のめりで参加できました。
個人的には以下のシーンが印象的でした。
- テストコードが正しいものであるかの確認が入念
自分の書いたテストコードが本当に挙動を担保するものなのか、開発に入る前のテストのテストを入念にしていました。
とにかく何か変更したら必ずテストを実施していました。
その行動があるからこそ、開発者として自信を持ってコードを世に出していけるんだなと。
- コミットが小さくて丁寧
package.jsonを追加した、テストを追加した、リネームした、など作業記録を残すようにコミットログが打たれてました。
最後に見返した時に綺麗で驚きました。
Conventional Commitsに基づいているそうです。
- t-wadaさんでもちゃんと悩むし、間違える
t-wadaさんほどのエンジニアでも、タイポしたり（指を怪我していました）、テストケースの名前で悩んだり、実装にミスがありました。
どんな卓越したエンジニアでも、ディスカッションや自動テストは必要なんだなと感じました。
開発演習編
午後は教えてもらったことを実践する時間でした。
先輩が残したライフゲームのコードを改善するというお題です。
それぞれが選択したプログラミング言語で、テストコードを書いてリファクタリングをするというものです。
午前の講座で出来る気がしてきていましたが、分かるのと出来るのは全然違うことが体感できました。笑
面白いのがt-wadaさんにコードレビューをしてもらえる & 他のメンバーのコードレビューが公開されることです。
同じ講座をを受けて同じお題でもメンバーによって少しずつリファクタリングのアプローチが異なっていて、お互いに学びを深めることができました。
チーム内でもペアプロとかモブプロもっとやっていきたいですね。
質疑応答編
t-wadaさんには時間ぎりぎりまで質問に回答してもらいました。
一部を紹介します。
Q. テストコード（RSpec）の可読性を向上させたいです。正しくテストが出来ているか分かりにくく、さらに読みにくい修正が重なり、結果がとしてコードが複雑化している気がします。改善のために何から着手していくべきでしょうか？
t-wadaさんの回答
テストコードをドライにし過ぎると痛い目にあう。RSpecが状態の共有をするので短期的には生産性の向上が見込めるが長期的には密結合な状態になりやすい。なので新卒エンジニアのレビューが大事。パッと見で分かるコードにしておくことが重要。長くプロダクトに関わっていると読みにくいコードも慣れで読めてしまう。「読みにくい」の言葉は積極的に言うべきだし、周りはそれを尊重すべき。心理的安全性を含めたテストコードのリファクタリングの文化をつくることが大切。
人の視線移動を考慮して、同じファイルにある、同じエディターにあるということは大切。Googleのソフトウェアエンジニアリングという本でDRY以外の価値観が紹介されているので参考にすると良い。DRYではなくDAMP（説明的かつ意味が分かる言い回し）が良い。ちょっとの冗長性を許容する代わりにパッ見で分かりやすいということ。これをキーワードにするとしてみてはどうか。
Q. 実装工数を見積もる時、テスト実装と機能実装の工数を分けて考えますか？
t-wadaさんの回答
テストを書いていないなら実装は終わっていない。
メンバーの感想
研修後のアンケートは5段階評価で全員最高評価でした！
定性コメントをいくつかピックアップします。
本日はありがとうございました！！ まずハッピーパスを通す→ ロジックを分離していく という、レガシーコードに立ち向かう上での一番肝になりそうな部分についての指針が得られたのが一番大きかったです。 「テスト書いてないってことは実装が終わってない」は胸に刻んで生きていこうと思います。
という声や
講演会、ライブコーディング、実装演習、懇親会、全てで学びがあった。リアルタイムで動くt-wadaさんを見れた。
と言う声や
自分が自信をもてるテストコードを書く。
がありました。満足度の高さが伺えます。
おわりに
ワークショップ実施後、社内ではライブコーディングの試聴会が実施されたり、社内Wikiに個人の学びが投稿されたりしました。
アドベントカレンダーにはワークショップの内容を踏まえた自分で書いたレガシーコードを自分で改善するという記事も投稿されました！
自分自身もテスやリファクタリングに関する関心が大きくなり、以前とは違う観点でプロダクトのコードを見ている気がします。
t-wadaさんが灯してくれた火を消さないよう、大きくテストやリファクタリングの文化を育てていきたいと思います。
t-wadaさん、ありがとうございました！！！
ちなみに社内で評判が良すぎたため年内にもう一度ワークショップが開催されるようです。
