Test Driven Development for Embedded C 読書会 第7回 (2012/10/6) #tdd4ec

Test Driven Development for Embedded C 読書会 第7回 第12章「Refactoring」、第13章「Adding Tests to Legacy Code」
1
Test-Driven Development for Embedded C

James W. Grenning (著) / 出版社: Pragmatic Bookshelf (2011/5/2) / 言語 英語, 英語, 英語 / ISBN-10: 193435662X / ISBN-13: 978-1934356623 / 価格: ¥ 2,553

Yohei 🇸🇬 @legoboku

明日、13時より池袋にて開催。#tdd4ec / “Test Driven Development for Embedded C 読書会 第7回 : ATND” http://t.co/ZetBXHW4

2012-10-06 00:42:28
Yohei Kato @Catu_dm

googleTestは日本語のチュートリアルはあるけど、細かいことを調べようとする検索できない。本当に使われているのか???http://t.co/1uV23zVQ #tdd4ec

2012-10-06 13:44:09
Yohei 🇸🇬 @legoboku

#tdd4ec google mockは変態的だけど便利だそうだ。

2012-10-06 13:45:56
Yohei 🇸🇬 @legoboku

#tdd4ec 暇ある時にgoogle mockについて調べてみよう。

2012-10-06 13:49:05
Yohei 🇸🇬 @legoboku

#tdd4ec ユニットテストをやっててもだんだんカバレッジが落ちたり、動かなくなったり。CIを入れて、良くない兆候を見つけたら、警告するように。

2012-10-06 13:53:55
Yohei 🇸🇬 @legoboku

#tdd4ec 12.4 Trnasforming the Codeから。内容はMartin Fowlerのリファクタリング本の紹介。

2012-10-06 14:15:58
Yohei 🇸🇬 @legoboku

#tdd4ec よくやるのが関数の抽出。大きな関数から処理を小さい関数に抽出。意図の分かる関数名に置き換える。

2012-10-06 14:18:32
Yohei Kato @Catu_dm

ダメif文はどのようにして生まれるか?? 1.仕様通りにべた実装 2.変更時に影響範囲を減らすための手抜き実装 #tdd4ec

2012-10-06 14:20:17
Yohei 🇸🇬 @legoboku

#tdd4ec if文の山盛りコードはどうやって生まれるのか?仕様書をまんまコードに落とした時や、修正・機能追加の時に既存コードを触れずにif文を追加する。

2012-10-06 14:21:11
goyo @goyoki

組み込み開発のブラック話は底の見えないブラックだな・・ #tdd4ec

2012-10-06 14:24:56
Yohei 🇸🇬 @legoboku

#tdd4ec リファクタリングする前にどうリファクタリングするか、コメントを挿入しておく。「ここは◯◯関数に置き換える」など。

2012-10-06 14:26:18
Yohei 🇸🇬 @legoboku

#tdd4ec 関数を抽出する時は、引数、戻り値を評価する。呼び出す側にとって自然な名前にする。

2012-10-06 14:28:04
Yohei Kato @Catu_dm

「実績のあるコード」って言葉はよく聞きますが、「たまたまバグが出てないコード」っていう意味ですね #tdd4ec

2012-10-06 14:30:53
Yohei 🇸🇬 @legoboku

#tdd4ec 「橋を燃やすな原則」。リファクタリングする時はリファクタリング前のコードを消さずに残しておく。リファクタリング結果がテストを通ったことを確認してから、前のコードを消す。

2012-10-06 14:35:37
Yohei 🇸🇬 @legoboku

#tdd4ec 例外系の処理を最初に書いて、条件分岐を浅くする。returnをあちこちに書くなという意見もあるが、こっちの方もが読みやすい。ただし、MISRAなどコーディング規約でも禁止している場合もある。

2012-10-06 14:38:18
Yohei 🇸🇬 @legoboku

@redboltz C/C++の場合、リソース確保をちゃんとやるためにreturn1箇所にするのは意味ありますね。

2012-10-06 14:44:34
Yohei Kato @Catu_dm

is△△のようなメソッドは直接条件文に突っ込むか?デバッグで戻り値見やす来るために一旦オート変数に格納するか?コードの可読性考えると前者でしょう。デバッグの戻り値はデバッガの方の技術で何とかすべき #tdd4ec

2012-10-06 14:45:19
Yohei Kato @Catu_dm

for文の中にへルタースケルターに詰め込むのではなくて外出ししたいですよね #tdd4ec

2012-10-06 14:51:25
Yohei 🇸🇬 @legoboku

#tdd4ec if文の山盛りも内容を精査して、先に評価していいやつを抜き出すことで、ネストを浅くできる。

2012-10-06 14:52:48
Yohei 🇸🇬 @legoboku

#tdd4ec 「関数の移動」。モジュールの責務に合わない関数を適切なモジュールに移動させる。

2012-10-06 14:57:10
goyo @goyoki

コールスタックのバグやオーバーフローを気にするとか組み込みならではで勉強会では新鮮 #tdd4ec

2012-10-06 14:59:17
残りを読む(29)

コメント

山本康彦@BluewaterSoft @biac 2012年10月6日
「ダメif文はどのようにして生まれるか?? 1.仕様通りにべた実装」 …その通り! なんだけど、「手続き」(リファクタリングでどんどん変わりうる)を記述したモノを「仕様(spec)」として定めるのがそもそもオカシイ。…と最近思うようになってきた。
0