Showing 2 Result(s)

レガシーコードからの脱却 まとめ – 12.10

12.10 本章のふりかえり 内容 設計は最後にして意図を示すプログラミングをすることで複雑さを減らせる。 品質は作り出すものだ。保証はできない。 読みやすく理解しやすいコードが、柔軟で、変更しやすい(ゆえにコストパフォーマンスも高い) 意図を示すプログラミングは観点の凝集につながる。抽象のレベルがそろい、読みやすく、理解しやすくなる オブジェクトの生成と利用を分離することで、テスト容易性を改善し、依存性を下げよう 創発設計は初心者向きではない。品質とテスト容易性に不断の注意を払う必要がある 学び 創発設計は初心者向きではない!ペアでのフォローが必要だ。 学びを活かすアイディア・行動 現場のコーディング規約づくり

レガシーコードからの脱却 まとめ – 12.9.2

12.9.2 コードをクリーンにする7つの戦略 内容 コードをクリーンにする7つの戦略を紹介している。 戦略 説明 コードに語らせる 何をしているかわかる明確な名前をつけよう。不要なコメントも減るよ。 テストを足すために、接合部を作る ? メソッドの凝集性を高める メソッドがやりすぎているから名前がつけづらくなる。小さく分けよう。 クラスの凝集性を高める クラスがいろいろやりすぎているから名前がつけづらくなるし、設計が理解しづらくなる。意味が明確に分かれているところは、分けよう。 判断を集約する ビジネスルールは集約させたほうが、理解しやすいよ ポリモーフィズムを導入する 条件パターンが増えそうなところはポリモーフィズムを使っておけば、そのクラスは変更しなくて済む。 生成をカプセル化する ポリモーフィズムを使っているクラスではインスタンスは生成させない。ファクトリーを使うかスタティックメソッドを使ってインスタンス化しよう。 学び メソッドもクラスも名前をわかりやすくつけて、ポリモーフィズムで条件を減らせば、コードはだいぶわかりやすい。そのためにはテストファーストで創発設計しながら適切な設計にしていこう。 学びを活かすアイディア・行動 現場のコーディング規約づくり