｢レガシーコード改善ガイド」読んだ
-
- いいね！0
べちか
@bechica
サブクラスのオブジェクトはどんな場合においてもスーパクラスのオブジェクトの代わりに使えなければならない クラスの利用者が、そのクラスがサブクラスであることを知らずに使えるべきではない と書いてある
2011-03-29 01:51:37
べちか
@bechica
このLiskovなんとかに違反してない限りは具象メソッドをオーバライドしてもいいけど、可能な限り具象クラスをオーバライドしないようにしましょうね ということっぽい
2011-03-29 01:55:48
べちか
@bechica
テスト書いてるとき、オブジェクトが生成しづらいパラメータを必要とするような場合はとりあえずそのパラメータの代わりにnull渡しとくと、そのパラメータが実行中に使われたらぬるぽで落ちるだけで、とりあえずテスト自体は書けるようになるし便利だよ、ってかいてある へー
2011-03-29 02:06:05
べちか
@bechica
テストコード書いてる時に、特定クラスのインスタンス化が難しい時は さっきのnull渡すのとかインタフェース抽出するとかやれって書いてある イメージわいてない
2011-03-29 02:12:13
べちか
@bechica
コンストラクタのパラメータ化。コンストラクタ内でパラメータ作ってるようなとき、クラスの外側でオブジェクトを生成したらどうかという提案。これをやるとカプセル化が壊れて読みにくくなるけど、テストの作り方によってはむしろコードの振る舞いが把握しやすくなるといってる。
2011-03-29 18:11:55
べちか
@bechica
割り込み点と絞り込み点 割り込み点：特定の変更による影響を検出できるプログラム上の箇所 絞り込み点：加えた複数の変更の影響を一度に検出できるプログラム上の箇所
2011-03-29 18:17:39
べちか
@bechica
絞り込み点を探ると少数メソッドへのテストを書くことで多数のメソッドの変更を検出できる。 コレをやりすぎるとテストコード肥大化するから、出来るだけ小分けにする。
2011-03-29 18:20:22
べちか
@bechica
テストもドキュメントも無かったら 仕様を把握するためにテストを書け。 仕様が理解できたら新しい仕様に応じたテストを書いて、必要なコード修正内容を把握しよう。リファクタリングするときは既存の振る舞いや振る舞い同士の関係を検証するテストも書け。
2011-03-29 18:25:30
べちか
@bechica
ライブラリのクラスへの直接呼出しをコード内に分散して記述することは ライブラリ側に変更(仕様以外にも利用料金とか)が加わったときにリスク大になる。一箇所にまとめよう。
2011-03-29 18:29:12
べちか
@bechica
API利用するところをインタフェース自作してラップしようって手法が紹介されてる。本番では本物のＡＰＩ叩いて、テスト中はモック叩くとかがやりやすくなるから、と。
2011-03-29 18:33:05