Tidy First? の第２部「マネージメント」についてのメモ
整理の「マネージメント」と聞いて、ちょっとイメージわかなかったが「ソフトウェア設計者はコードの整理に没頭してしまう」という言葉をみて、確かにと思った
気付いたら「整理」をやりすぎてしまう
この問題をマネージメントする方法を第二部では紹介してくれるみたい
- いつから片付けを始めますか？
- いつ片付けをやめますか？
- 整理整頓、コード構造の変更とシステムの動作の変更をどのように組み合わせるのでしょうか?
16. 別々に分ける
PRが長すぎるのはよくないし、短すぎても無意味である
適切な粒度にするためには以下のステップで考えると良い
- 第一部で紹介した整理手法を使って整える
- コードの修正を「振る舞いの変更」と「構造の変更」に分ける
- 「振る舞いの変更」と「構造の変更」を順番に並べる
・B = 振る舞いの変更、S = 構造の変更 とすると、自分の変更が「BSSBSSSSBB」の順番になるようにする
・慣れてくればコードの修正前に変更の順番が見通せるはず
・例えば、ヘルパー関数を作り処理を抽出することは「構造を変更」することになるが、その後に「振る舞いの変更」をするとテストもしやすいとわかる - 少なくてもこの「振る舞いの変更」と「構造の変更」で別々のPRにする
・「BSSBSSSSBB」を、「B」「SS」「B」「SSSS」「BB」の単位でPRを出す（「SSSS」をさらに分けるかは後述される）
迅速なレビュー鍵で、レビューが遅いとPRが大きくなる
17. 連鎖
片付けのやりすぎに注意
小さな整理を重ねていく
その際に「振る舞いの変更」と「構造の変更」を順番を見通しておく
18. バッチサイズ
16章の「BSSBSSSSBB」を、「B」「SS」「B」「SSSS」「BB」の単位でPRを出すようにする話
「SSS」のように続いたものは、一つ一つ「S」に分けたPRにしなくてもいいのか？
ちょっとずつ行うか、一括で行うかの問題
一括のリスクは承知の通りだが、ちょっとずつも「レビュー回数が増えてコストが増える」と考える人がいるがそれは違う
信頼と強い文化を持つチームでは、整理整頓にレビューは必要なくなる
そのようなチームになるには数か月かかりますので、練習し、実験し、一緒にエラーを確認することが必要
19. リズム
小分けにすることで、何時間もかけてやることはなくなるはず
長い時間かけて整理してもどうせすぐに変更したいと思うようになる性質がある
整理は数分から１時間程度が良い
20. 絡まりを解く
コードの整理を一時間ほどしたあと、コードの整理といくつかの複雑な変更も一緒に行なってしまった時にどうするか
いくつかのよくない行動
- 現場のままレビューに出す
- 時間をかけて整理と変更を別々にしてPR作る
- 全部破棄して最初からやり直す
意識的に整理を始めたばかりの頃は、「順調に変更を加えている」状態から「ああ、いったい何をしてしまったんだ？」という状態への移行を見逃しがち
整理はいつやるべきか（最初？）
21. First, After, Later, Never
タイミングはいつがいいかの話
- そもそもTidy が適さない状況
・２度と変更されないコード
・設計を改善しても学ぶことは何もない - 後々整理するべき状況
・すぐに成果が得られない大量の作業
・最終的には報酬が得られる
・少しずつ整理できる - 最後に整理すべき状況
・次回まで待って最初に片付けると、さらに費用がかかる
・後片付けをしないと達成感が得られない - 最初に整理すべき状況
・理解力の向上、あるいはより安価な行動の変化という形で、すぐに成果をもたらす
感想
第二部の冒頭の「片づけの方法がわかっていてもそれを実践できるだけでは、片づけをマスターしたということにはならない」はその通りで、最近「順調に変更を加えている」状態から「ああ、結構な変更を加えてしまっている？」という状況になったことがあったので読んでいて学びがあった
これを参考に整理のタイミングとPRの粒度に気をつけたい
