クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

テスト駆動開発による組み込みプログラミング [ James W.Grenning(著), 蛸島昭之(監訳), 笹井崇司(訳)]

おもしろい本でした。
組み込みTDDの苦しい事情と、それでもやるんだという強い意気込みを感じました。


以前読んだTDDの本よりも引っかかるところが少なく、納得しながら読めました。

だけどドライバモジュールからハードウェア依存の情報を抜いて、
制御するアドレスを外から渡すというのは分かりにくくなってるように見えました。
ドライバだけ見ればハードウェアのどの部分とどうやりとりしているのかが分かるようになっていてほしいと思ってしまいます。
あとテスト関数の結果判定部分にメモリの情報を書かなくてはいけないのがメンテ大変そうです。
あんまりヘルパー関数作りすぎるとプロダクトコードに近くなって何をテストしているのか分からなくなりそうだし。

テストダブルやモックのバインディングはかなり苦しいです。
関数ポインタは実際の動きがコードから追いかけづらいからどうかと思います。
でも確かにリンクだけでは対処できないし、ifdefは汚いし、苦しいです。

そしてモックのexpectationもなかなかしんどいです。
組み込みだと多用したくなりそうだけど、そこまでガチガチにテストケース作ってしまうと
作るのも大変だし、あとで変更するときもどうにもならなくなりそうだし。

そして後半は「CでいかにC++をやるか」みたいな話になっていって、目的がよく分からなくなりました。
この本自体がSOLIDの原則の「単一責務の原則」から外れかけているんじゃないかと心配になりました。
途中で「TDDのためにはいい設計が大事」という断り書きがあって、一応流れが繋がるようにはなっているけど。

なんだか批判的なことばかり書いてしまいましたが、
基本的には納得する部分の方が圧倒的に多く、刺激的な本でした。
ソフトとハードどっちが悪いのか分からなくてデバッグ地獄にはまるとか、
ハードが壊れないとエラー処理部分をテストできないとか、
ステップ実行が猛烈に時間かかるとか、
ターゲットへのダウンロードに時間かかるとか、
そもそもターゲットが手元になかなかないとか、
#ifdefは使わない方がいいとか、
時計が厄介だとか、
普遍的な問題提起に毎回頷きながら読みました。
ユニットテストの重要性がよく分かりました。
練習問題の「新旧基板に対応する」とか「正論理から負論理に変わりました」とかも組み込みあるあるですね。
  1. 2017/05/04(木) 23:41:17|
  2. | トラックバック:0
  3. | コメント:0
<<欠測データの統計解析 [阿部貴行(著)] | ホーム | マスタリングTCP/IP 入門編 [竹下隆史, 村山公保, 荒井透, 苅田幸雄(著)]>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/370-744f2cf7
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。