いってきた
メモ
リファクタリング
レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。
レガシーコード改善ガイド読書メモ - Anger Driven Development
まさにこれが出た。
方法としては２つあって
- テストが無いままで安全に変更できる状況を考える
- 振る舞いを変えること無くテストできるか検討する
バグを直すということ
バグを直す===振る舞いが変わる
また自分がバグと思っているものは実は仕様かもしれない(途中からプロジェクトに参画して、ドキュメントなどが無い状況など)
動いているコードがすべての事実。コードの振る舞いを保つことを考える。変わりそうだったら上長に相談。
KPT
Keep
- テストに保護されるの最高。これで変更のたびに「どうか壊れていませんように」と祈らなくてすむ。
- リファクタリングの実践的な手法を学べた
動いているコードをリファクタする時はまず振る舞いを保つように保護する。その時も、 - ペアプロの楽しさを体験できた
他人のコーディングを間近で見れる(IDEやエディタのホットキーなどのこだわりが垣間見れる、優秀なプログラマのコードの書き方、思考ステップなどの知見が得られる)
Problem
- ペアプロの難しさを体験できた
- 役割分担(ドライバー、ナビゲーターがなかなか交代できない)
- 意識合わせ(今回だと、どういう思考でリファクタしていくかというのを逐一確認し、二人がその思考に合わせて行くのが難しかった。一人だと思考を柔軟に変更できる。)
- コードを壊したくなる
- 破壊衝動に駆られる。
すぐにコードの振る舞いを変えるような変更を加えたくなったが、ナビゲータの方が制止してくれた。まだTDDが体に染み付いていない。
対策：既存のコードの振る舞いを保証することを念頭に置く。焦らずTODOリストに落とし込む。現在動いているコードが絶対。２年前の先輩*1に敬意を表する。
- 破壊衝動に駆られる。
- TODOの粒度
要件定義===テスト設計だと思うのだけど、その落とし込みが難しく感じた。どの程度の粒度で考えるか。粒度が細かすぎるとテストがやりづらいという話も上がった。
Try
- 写経(TDDはセンスではなくスキルなので高めることができる)
- TDDBCの途中になっている課題を終わらせる
- テストファーストで作ってみる
雑感
１日目の深夜まで語り合ったり遊んでたりしたみたいで、早く寝ずに参加すればよかったと少し後悔。。。
朝１からクソコードレビューしたり、夜にこだわりのホットキーの話したり、エンジニアが集まってワイワイ話すのはほんとに楽しい。
是非また行きたいと感じた。
*1:動くクソコードを残して去った先輩のこと、合宿の会話中に何度も出てきた
