読者です 読者をやめる 読者になる 読者になる

Anger Driven Development

備忘録でございます

TDDBC Toyama #1 2日目

いってきた

tddbc.connpass.com

メモ

リファクタリング

レガシーコードのジレンマ コードを変更するためには、テストを整備する必要がある。多くの場合、テストを整備するためには、コードを変更する必要がある。

レガシーコード改善ガイド読書メモ - Anger Driven Development

まさにこれが出た。

方法としては2つあって

  1. テストが無いままで安全に変更できる状況を考える
  2. 振る舞いを変えること無くテストできるか検討する
バグを直すということ

バグを直す===振る舞いが変わる
また自分がバグと思っているものは実は仕様かもしれない(途中からプロジェクトに参画して、ドキュメントなどが無い状況など)
動いているコードがすべての事実。コードの振る舞いを保つことを考える。変わりそうだったら上長に相談。

KPT

Keep

  • テストに保護されるの最高。これで変更のたびに「どうか壊れていませんように」と祈らなくてすむ。
  • リファクタリングの実践的な手法を学べた
     動いているコードをリファクタする時はまず振る舞いを保つように保護する。その時も、
    • 手で行わずIDEのリファクタ機能を使う
    • Lintをかける
    • 静的解析ツールを使って複雑度などを調べる
      などなるべく機械的に変更できる手段から実践していく。
  • ペアプロの楽しさを体験できた
    他人のコーディングを間近で見れる(IDEやエディタのホットキーなどのこだわりが垣間見れる、優秀なプログラマのコードの書き方、思考ステップなどの知見が得られる)

Problem

  • ペアプロの難しさを体験できた
    • 役割分担(ドライバー、ナビゲーターがなかなか交代できない)
    • 意識合わせ(今回だと、どういう思考でリファクタしていくかというのを逐一確認し、二人がその思考に合わせて行くのが難しかった。一人だと思考を柔軟に変更できる。)
  • コードを壊したくなる
    • 破壊衝動に駆られる。
      すぐにコードの振る舞いを変えるような変更を加えたくなったが、ナビゲータの方が制止してくれた。まだTDDが体に染み付いていない。
      対策:既存のコードの振る舞いを保証することを念頭に置く。焦らずTODOリストに落とし込む。現在動いているコードが絶対。2年前の先輩*1に敬意を表する。
  • TODOの粒度
    要件定義===テスト設計だと思うのだけど、その落とし込みが難しく感じた。どの程度の粒度で考えるか。粒度が細かすぎるとテストがやりづらいという話も上がった。

Try

  • 写経(TDDはセンスではなくスキルなので高めることができる)
  • TDDBCの途中になっている課題を終わらせる
  • テストファーストで作ってみる

雑感

1日目の深夜まで語り合ったり遊んでたりしたみたいで、早く寝ずに参加すればよかったと少し後悔。。。
朝1からクソコードレビューしたり、夜にこだわりのホットキーの話したり、エンジニアが集まってワイワイ話すのはほんとに楽しい。
是非また行きたいと感じた。

*1:動くクソコードを残して去った先輩のこと、合宿の会話中に何度も出てきた