こんにちは！コドモン開発部の加藤です。 すっかり暑くなってきましたね。我が家では猫が換毛期を迎えて、家中毛だらけになりながらも日々なんとか暑さを乗り切っています。
最近コドモンでt_wadaさんにレガシーコード改善ワークショップを行っていただきました。 今回はそのワークショップの様子についてレポートしていきます！
レガシーコード改善ワークショップの概要
t_wadaさんの紹介
エンジニア界隈では知っている方も多いと思いますが、改めて今回ワークショップを実施してくださったt_wadaさんについてご紹介します。
和田卓人さん(通称t_wadaさん)はテスト駆動開発の第一人者として広く活躍されているソフトウェアエンジニアです。書籍『テスト駆動開発』『SQLアンチパターン』『プログラマが知るべき97のこと』などの翻訳・監修をされています。
t_wadaさんといえばあのライオンが有名ですよね。
ワークショップの目的と内容
目的
今回のワークショップは「TDDを開発組織の文化として定着させること」「メンバーがTDDでレガシーコードを安全に改善する技術を身につけること」が目的でした。
コドモンではエクストリーム・プログラミング(XP)を取り入れており、プラクティスのひとつであるテスト駆動開発をよりよく実践し、組織に定着させたいという思いがあります。 現状、TDDを開発に取り入れはじめており、約70%弱のチームで実際に業務でTDDでの開発の経験があります。
しかし、その中でも「基本的に実装はTDDで行う」というように浸透しているチームと、「TDDで行う場合と行わない場合がある」というようにまだ浸透しきっているとはいえないチームが存在するのが現状です。 新規機能の開発では浸透し始めているのですが、特にレガシーなコードの改善については「そもそもテストをいれるのが難しい」などの課題があり、なかなか浸透が進まない状況でした。
開発部全体としてTDDを浸透させ、このような課題を解決するための技術を身につけるために、今回はt_wadaさんにワークショップを依頼させていただきました。
1.午前の部
午前の部は開発部のエンジニアメンバー全員で参加しました。 t_wadaさんに以下のスライドをもとに講演していただきました。
実際にt_wadaさんがレガシーコードに対峙したときに、TDDを用いて設計改善する様子を追体験できました。
当初の仕様の要求を満たしつつ、SDKのサポート終了に対応したり、仕様追加要求に答えたり、テストをいれただけでは設計が変わらない現実に向き合ってリファクタしたり……などかなりリアルな課題に立ち向かう姿をみることができました。
2.午後の部
事前に選出した12名のメンバーが午後の部に参加しました。 PHP製のレガシーなソースコードを題材に、TDDを実践していきます。 途中、t_wadaさんとの1on1も行いました。
- 主な内容
- テストがないコードに対してテストを書けるようにする(スタートライン)
- 自分が書いていないコードにテストが書けるようにする
- 上記を達成した上で、コードをリファクタリングしていく
ワークショップ中のハイライト
午前の部
活発な実況チャンネル🗣️
Slackでワークショップ用のチャンネルを作成して、実況・感想・質問などをわいわい書き込みながら講演を聞きました。 t_wadaさんの丁寧な導入のおかげもあり「ただ聴くだけではなくて、ワークショップに参加する」ための場になっていたように思います！
テストを書いただけでは設計はよくならない、を実感する😬
他人から引き継いだコードにテストを入れることに成功したあと、「設計はよくなっているだろうか？」を自問する、というお話が講演の中でありました。
「ソフトウェアの内部の質は、テストコードを書いても基本的に変わらない」という言葉の通り、テストを入れるとテスト容易性はあがりますが、それだけではコードの理解容易性・変更容易性はあがりません。 「テストはあくまでコード品質をあげるきっかけ、品質をあげるのはプログラミング」と言う言葉も改めて身に刺さりました。 グリーンのテストを大量生産するだけでは不十分で、その先のリファクタリングを行ってこそTDDの価値があると感じました。
質問コーナーではE2E肥大化の課題に注目が集まる👀
コドモンは自動テストがほとんどない状態から、E2Eテストを拡充してプロダクトの品質を守ってきました。 その結果、現状は多くのE2Eがありますが、ユニットテストはそれに比べて数が少ない状況です。
t_wadaさんへの質問でもE2Eの肥大化を防ぎつつ適正なレイヤのテストを増やすには？といった課題に対する質問が多くありました。 受け入れ条件をすべてE2Eで表現しようとしない、というお話やE2Eテストの効果が高い場面・単体テストで保証できる場面についてのお話など、実際に実務で活かせる内容をアドバイスいただきました。
午後の部
最初のテスト作成をライブコーディングで学ぶ💪
課題について認識合わせをしたあと「テストがないコードに対してテストを書けるようにする」状態をまずは目指します。 この部分はt_wadaさんがライブコーディングでE2Eテストとひとつ目の単体テストまで作成してくれました。
今回、コドモンのスタックに合わせてPHPで題材のコードを用意してもらいました。 t_wadaさんもほぼ初見のコードとのことで、どのようにテストをいれるか？を考えながら実装している様子を見られたのがとても貴重でした。 t_wadaさんも悩みながら進めるんだ……！ということに、参加者一同少し安心です。
実践を始めると意外と手が動かない……🥺
テストを入れられる状態になったコードに対して、各参加者がTDDを実践してリファクタリングを試みます。 午前の講演や午後のライブコーディングをみながら、自分もTDD進められそうかも？と思っていたのですが、意外と手が動かない……！という現実に直面します。 それぞれSlackに実況スレを立てて実装の様子や悩みポイントを書きながら、TDDによるリファクタリングを進めていきます。
人が1on1を受けている姿をみられるの貴重👏
一人ずつt_wadaさんに実装中のコードを見てもらう1on1を途中で行いました。 この1on1は全員のいる場で、公開で行われました。
同じ課題に取り組んでいましたが、実装アプローチの方法や、悩むポイントが人それぞれ違うんだなということがわかり、刺激になりました。 コドモンではペアプロを実践しているので、他者と一緒にひとつの実装をする、ということは日常的にあるのですが、同じ課題にそれぞれが取り組むと違うアプローチをするのが目に見えて実感できたのが新鮮でした。
個々人の悩みポイントについて、t_wadaさんに適切なアドバイスをいただきつつ、時間いっぱいまでリファクタを進めていきました。
まとめ
TDDについては書籍などで見知っていた部分もありましたが、今回のワークショップを通してより深い学びが得られました。 t_wadaさんの実際の作業や思考方法を追体験できるような部分が多く、リアルな課題への向き合いかたへの参考になりました。 また、午後の部で取り組んだ課題は実際に手を動かしてみて、レガシーコードでもTDDで安全に改善できるということを体感できました。
TDDはレガシーなコードに向き合っているコドモンにおいて、すぐに実務に活かせる武器になりそうだと感じました。 他人の書いたコードを理解し、よりよい設計を模索することはエンジニア人生で何度も遭遇することだと思うので、「TDDを体得した」と言えるときまで学習・実践を繰り返したいと思います。
t_wadaさん、貴重な機会をいただき本当にありがとうございました！
外部講師を招いての勉強会は、開発メンバーとしていつもよい刺激をもらっています。
他にもどんなことをしているか？が気になる方は、こちらの記事もぜひご覧ください！
tech.codmon.com
