Test Driven Development for Embedded C 読書会 第6回
-
- いいね！1
Yohei
@legoboku
@yukikado 前のお仕事では、UMLのクラス図から生成したXMIを読み込んで、クラス定義やら関数ポインタテーブルを自動生成するツールを使っていました。ココらへんは人間が書くべきではないと思います。#tdd4ec
2012-08-19 14:18:08
Yohei
@legoboku
#tdd4ec （定番の流れ）ダメコードを示す→なぜダメか解説する→改善案を示す→いきなりコードをいじる！のではなく・・・→テストコードを書きましょう→安全にリファクタリングしましょう
2012-08-19 14:21:04
CAD
@yukikado
@legoboku 興味深いです。OOP言語では継承等で提供されている機能ですから、自動化するというのは理にかなっていると思います。 #tdd4ec
2012-08-19 14:25:11
Yohei
@legoboku
@yukikado クラス継承の実装は、コードベースでやるよりクラス図を見ながらやった方が直感的で分かりやすいのもあるし、ルールにもとづいて自動生成して効率化もできるしで両得ですね。 #tdd4ec
2012-08-19 14:27:19
Yohei
@legoboku
#tdd4ec OCPとLSPにもとづいて、冗長なswitch文の嵐を関数ポインタテーブルによる動的インタフェースに置き換えていく。これで仕様追加があっても、既存コードを変更せずに拡張できるようになる。
2012-08-19 14:29:13
Yohei
@legoboku
#tdd4ec 関数ポインタを使うから、製品コード側にはNULLポチェック、期待する関数ポインタ華道家のチェックを入れて、かつテストコードに初期化時に期待する関数ポインタが設定されているかチェックするようなテストを入れておくのだな。
2012-08-19 14:42:43
CAD
@yukikado
実際に関数ポインタを使うなら、C++に習って静的解析ツールを作ったり、実行時エラーを解析するためのロガー＆ヘルパーが必要になりそう。オレオレフレームワークだな #tdd4ec
2012-08-19 15:04:40
CAD
@yukikado
@legoboku @Catu_dm なるほど。そうなると、#tdd4ec ++ は普通のTDDとどう違うかということになりますから、ハード依存の部分や、少ないリソースの管理方法についてフォーカスした内容になってきそうですね。
2012-08-19 15:23:04
Yohei
@legoboku
#tdd4ec 新規開発は不確実性がつきまとう。待っていても固まることはないので、後で変更が出るとしても早期に開発を始めるのが良い。そうでないとビジネスチャンスを失う。
2012-08-19 15:35:23
Yohei
@legoboku
#tdd4ec アプリケーションをハードウェアの詳細に依存させない設計にしておくと、詳細が決まっていない状況で開発が始められる点でも良い。
2012-08-19 15:36:43
goyoki
@goyoki
Single-instance module, Multiple-instance module, Dynamic inteface, Per-type dynamic interface #tdd4ec
2012-08-19 15:52:05