Tidy First? 読んだ共有

Tidy First? を読んだ共有
翻訳される前に、原書を読んで日本語に訳している部分があるので、日本語訳と違う部分があると思います。
こういう内容書いてるから読んでねという共有なので1章の技法部分の要約になっています。

Transcript

1. 共有 1
2. 読んだ本 2
3. Tidy First? 著: ケントベック TDD XP JUnit 3
4. 影響 次の本が「Tidy First ？」というタイトルなので、私はkonmari メ ソッドがソフトウェア設計にどのように適用されるか、されない かについての記事を書きました。 予期しない副作用: 物を整理したくなる強い欲求 “ “ 4
5. 構成 3 部構成 Tidiyings Managing Theory Tidy のテクニック どのように 片づけていくか 背景 5
6. Tidy とは 数分から数十分で終わる、本当に簡単なリファクタリング コードの整理のみ if(str != null){ if(!str.isEmpty()){ System.out.println(str); } } if(str != null || !str.isEmpty()){ return; } System.out.println(str); 6
7. テクニック 7
8. Tidiyings ガード節 マジックナンバー デッドコード 明示的なパラメータ Normalize Symmetries( 正規化) 適宜改行を入れる Reading Order( コードの順番) Extract Method Cohesion Order( 凝縮の整理) One Pile( 分散しすぎない) 宣言と初期化を一緒に わかりやすいコメントを 変数の説明 不要なコメントは削除 8
9. ガード節 いわゆるealry return if(str != null){ if(!str.isEmpty()){ System.out.println(str); } } if(str != null) return; if(!str.isEmpty()) return; System.out.println(str); 9
10. デッドコード 動作に不要なコードは保守性が悪く 認知が負荷があるため出来るだけ消す 小さく几帳面に消していく -> 複数をまとめて消すのではなく、見つけたら消す 10
11. Normalize Symmetries( 正規化) 同じ処理でも書き方が複数ある 書き方をそろえよう public String formatMessage(String name, int age) { return "Name: " + name + ", Age: " + age; } public String formatMessage(String name, int age) { return String.format("Name: %s, Age: %d", name, age); } public String formatMessage(String name, int age) { StringBuilder sb = new StringBuilder(); sb.append("Name: ").append(name).append(", Age: ").append(age); return sb.toString(); } public String formatMessage(String name, int age) { return MessageFormat.format("Name: {0}, Age: {1}", name, age); } 11
12. Reading Order( コードの順番) 人間がわかりやすいように順番に並べる write() read() process() read() process() write() 処理の流れとしては入力( 読み取り) -> 処理 -> 出力 12
13. Cohesion Order( 凝縮の整理) 意味が関連するものは、近い場所に書かれていたほうがいい 同じクラスファイル内 同じディレクトリ内 同じリポジトリ内 ※ 本の中でcoupling (coupled) という定義が出てくる 13
14. 宣言と初期化を一緒に よく言われるやつ int a // some code that doesn't use a a = ... int b // some more code, maybe it uses a but doesn't use b b = ...a... // some code that uses b int a = ... // some code that doesn't use a // some more code, maybe it uses a but doesn't use b int b = ...a... // some code that uses b 14
15. 変数での説明 これもよく言われる return new Point( (int) (Math.random() * 100 + Math.sin(Math.toRadians(45))), (int) (Math.random() * 100 + Math.cos(Math.toRadians(45))) ); int randomFactor = 100; double angle = Math.toRadians(45); int xCoordinate = (int) (Math.random() * randomFactor + Math.sin(angle)); int yCoordinate = (int) (Math.random() * randomFactor + Math.cos(angle)); return new Point(xCoordinate, yCoordinate); 15
16. マジックナンバー よく言われるマジックナンバーを避けて定数 return price * 0.1; private static double TAX = 0.1; // some code return price * TAX; 16
17. 明示的なパラメータ 配列や連想配列をそのまま渡すのは良くない params = {a: 1, b: 2} foo(params) function foo(params) function foo(params){ foo_body(params.a, params.b) } function foo_body(a, b) 17
18. 適宜改行を入れる 複数行ずらーっと並んでいるのが見づらい -> 適宜改行を入れよう シンプルだけど効果的 “ “ 18
19. Extract Helper 再利用性が高いものは、独立した処理として切り出す リファクタリングでよく言われるもの。 public void process(){ // ... 変わらないもの ... // ... 変わるべきもの ... // ... 変わらないもの ... } public void process(){ // ... 変わらないもの ... helper(); // ... 変わらないもの ... } private void helper(){ // ... 変わるべきもの ... } 19
20. One Pile( 分散しすぎない) あまりにも細かく分散されすぎているよりは、1 つのクラスでまとめ て記述のほうがいい 肥大化した巨大なクラスを作れば良いというわけではない ソースコードの一番のコストは、可読性の悪さ 書きにくさではない -> 可読性の高いコードを書いていく必要がある 20
21. わかりやすいコメントを 文字通り、適切なわかりやすいコメントを入れよう 21
22. 不要なコメントは削除 適切なコメントは必要だが、不要なコメントは削除 ソースコードを見れば何をしているか明確だが、自然言語で書いてい るだけ // AとBを足す return a + b; 最悪の例: getX() // xを返却 return x 22
23. カップリング ある変更をすると別の部分も変更が必要 一番簡単なのは関数名を変更したら呼び出し側も変更が必要 public void foo(){ // 変えたらmainも // some code } public static void main(String[] args){ foo(); } 23
24. カップリングの問題点 1-N 1 つの要素は、変更に対して他の要素と幾つでも結合できる ツールで解決可能 カスケード 変更がある要素から別の要素に波及 その暗黙の変更がまた別の変化の引き金に... 問題で変更のコストはべき乗になる 24
25. カップリングとデカップリング カップリング自体は問題ない カップリングのコストを払うのか デカップリングにコストを払うのか 25
26. 例 sender(){ senderFeild1(); senderFeild2(); } receiver(){ receiverFeild1(); receiverFeild2(); } format = [ {field: "1" type: "string"}, {field: "2" type: "int"}, ] sender(){ writeFeild(format); } receiver(){ readFeild(format); 26
27. 例 カップリングがなくなった訳ではない 実装によってはカップリングは存在する 27
28. 注意点 正確なコストがわからないし、時間と共に価値は変化する カップリングのコストを払うか、デカップリングにコストを払うかを 選択していく ソフトウェア設計が難しいところ 28
29. Managing 29
30. 別々に片付ける B: behavior S: structure 30
31. 別々に片付ける 31
32. 別々に片付ける ビヘイビアの変更と、Tidy は別のPR に。 32
33. chain ガード節 -> 説明ヘルパー、説明変数 デッドコード -> コードの並び変え( 読む順、結束順) Normilze Symmetries -> コードの順番、凝縮の整理 読む順番 -> Normize Symmetries 凝縮の順序 -> ヘルパーオブジェクトの作成(Tidy の範囲外) 変数の説明 -> 説明ヘルパー、冗長なコメントの削除 etc... 33
34. サイズをどうするか Tidy とビヘイビアの変更を一緒にしない -> 全てのTidy を一緒に行うのか、別々に行うのか、その中間なのか? 34
35. サイズをどうするか Tidy の回数が増やすと増加するコスト Collisions 結合までが長く -> 他の誰かの作業と衝突 Interactions 誤って動作を変えてしまう可能性 相互作用がある-> マージコストが高く Speculation 回数が増えると、Tidy するだけになりが ちで、あらゆる追加コスト 35
36. レビューコスト バッチが多くなるとレビューコストは上昇 1 変更のreview & marge コストは相当なもの このコストを感じているため、 Collisions Interactions Speculation のコストが上昇しても、トレードオフの中で 右往左往する 36
37. どうすればよいのか tidy のコストを削減し、Tidy を増やしたい なら、レビューのコストを下げる 信頼と強力な文化を持つチームでは、Tidy にレビューは必要ない Tidy の見直しをなくすために必要な安全性 と信頼性のレベルに到達するまで 練習する、実験する、一緒にエラーを見 直す 37
38. Tidy をいつするか? Never 片づけをまったくしないこと コードの振る舞いを二度と変えない -> 本当に動作を変更する必要がないのは稀 38
39. Tidy をいつするか? Later 「後で」は、今できないことを正当化するために使われる あとですることもできる 散らかってるものをリストアップ ( お楽しみリスト) 合間の1 時間とかで消化していく 整頓によってシステム動作に対する将来の変更が容易になる -> 隙間時間でやる意味がある 39
40. Tidy をいつするか? After 後片付けのような意味 振る舞いを変えて、その後整理するか？ すぐに同じとこを変えることがあるなら整理した方がいい 後日すると整理を容易にする文脈を忘れてるかも 今やった方がコストが安い 40
41. Tidy をいつするか? first タイトルの内容 Q. 最初にするのか？ A. 場合による 41
42. Tidy をいつするか? 効果がすぐに現れるならした方がいい 変更の準備が出来ていない -> 整理することで理解がしやすくなる 整理することで効果が出る自信があるなら 散らかってるのが無くなれば変更が簡単になる 整理すれば理解しやすくなる ( 今理解出来ていない) 42
43. 注意 tidy 自体が目的にならないように 難しく考えない 出てきたtidy は小さいものなのであまり難しく考えない 成果が出なくてもコストは小さい たいていの場合は報われる 43