｢レガシーコード改善ガイド」読んだ

べちか @bechica

スルーと思ったけど、抜書きしとくか・・・ 責務を基に抽出するって書いてある でも意味がわかんない

べちか @bechica

とりあえずAPIをラップする方法は、APIガ比較的小さい、サードパーティのライブラリへの依存を完全に分離したい、テストがなく、ＡＰＩを通じたテストが不可能なときに有効らしい

べちか @bechica

逆にこの方法が使えないのはＡＰＩが複雑で 安全にメソッド抽出したり手動で安全にメソッド抽出する自信あるときはそうしろって書いてある

べちか @bechica

２２０ページ読んだ。 あと半分。

べちか @bechica

第１６章 Ｑコード変更できるほどコード理解してないんだけど Ａ地道にやれ ・・・ひどい・・・

べちか @bechica

第１７章 私のアプリケーションには構造がありません もうタイトルで笑わすのやめろや

べちか @bechica

そのシステムの振る舞いに着目して適切にリファクタリングしろ 以上のことが読み取れない

べちか @bechica

CRCについて勉強しなさいってかいてある うーん

べちか @bechica

@melodia45 Class Responsibility Collaborator

べちか @bechica

@melodia45 クラス間の役割と依存関係を明確にするためのUMLの技法みたいだ

べちか @bechica

第１９章 Ｑ．私のプロジェクトはオブジェクト指向じゃないけどどうすれば安全に変更できますか？ Ａ．ほぉ～！それ聞いちゃう？ｗｗｗマジで？ｗｗｗそっかぁ～ やるねぇ～ｗｗｗｗｗ

べちか @bechica

絞り込み点を探して依存関係をできるだけ排除し、テストコード書け 地道にやれ みたいな話

べちか @bechica

第２０章 Q.このクラス大きすぎてもうこれ以上大きくしたくないんですけど A.するな 明快

べちか @bechica

で、単一責務の法則。 すべてのクラスは単一の責務を持つべきである・・・。

べちか @bechica

じゃあ責務ってなんですか、それは・・・ あとは自分で考えてください みたいな内容で発狂

べちか @bechica

インスタンス変数がクラス内のどのメソッドで使われているか整理すると責務分割に役立つとある。 この手法を機能スケッチとして紹介している。

べちか @bechica

影響が少ないところで分割できるかどうか検討しようということみたいだ

べちか @bechica

あと、クラスの役割を短文で説明できるかためしてみろ とかそういう経験則の紹介。

べちか @bechica

試行リファクタリングという方法が紹介されている。 あらゆる手段でクラスをリファクタリングしてみて、それは使用せずに破棄せよ といってる。 コードの理解を深めるための手法。

べちか @bechica

まず、単一責務の法則を実装レベルで導入、するとインタフェースが書きやすくなるから書く、みたいな

べちか @bechica

モンスターメソッドって言葉出てきてニヤニヤしてる

べちか @bechica

モンスターメソッドにはいろいろ種類があって インデントが不適切（あるいはない）、すごいデカいif文とかあって条件分岐が読みにくいとか、 if文が破滅的にネストしてて とか まあそういうのみたいだ

べちか @bechica

第２３章 Ｑどうすればデグレって無いことを確認できるの Ａまずテストを書こう そして、ひとつの目的で編集するたびテストを実行して、どこがまずいのか確認しながらやろう

べちか @bechica

第２４章 Ｑもううんざりです、何も改善できません Ａおちつけ

べちか @bechica

３４１ページまで読んだ あと１００ページ