Pragmatic Bookshelf
発売日：2011-05-02
本日、「Test-Driven Development for Embedded C (Pragmatic Programmers)」読書会の第2回をやりました。
今日読んだ範囲は？
第3章「Starting a C Module」と第4章「Testing Your Way to Done」をやりました。第3章は初めてのTDDセッションでLEDドライバのコア部分をTDDで実装する章です。第4章はテストリストに書いた機能をひと通り実装しながら、リファクタリングをしていく章です。
第3〜4章の一連の流れは前半のハイライトだと思います。本書を読み進めていく場合に、最初に感じを掴みたい方はここのサンプルを一から自分で書いてみることをオススメします。
サイトにレジュメを置いているので、こちらも参照してみてください。
サンプルコードは私のgithubのリポジトリにあります。ちょっとインデントが崩れているので、後で綺麗に整形します^^;
- テストコード
- プロダクトコード
常にコードを安定な状態に置く
今日の勉強会で一番勉強になった点を2つご紹介します。
まず、1つめは「常にコードを安定な状態に置く」ということ。これは以前、ブログの
まず、1つめは「常にコードを安定な状態に置く」ということ。これは以前、ブログの
「C/C++でTDDする時の手順をステートマシン図で描いてみた」に書いたTDDの作業を表現したステートマシン図に通じる話です。
今日、勉強会をやっていてふと思ったコードには2つの安定した状態があって、TDDでは必ずその2つのうちのどっちかの状態に置いて安定させるという意図があるんじゃないかということです（持論です）。
1つ目はテストが通って安定した状態。これにはテストが通っただけでリファクタリングされていない状態と、リファクタリングされている状態があります。これはTDDを少しかじっていれば知っている内容ですね。
2つは、（勉強会を初めて知りましたが）テストが通っていなくて安定している状態があります。コンパイルエラー、リンクエラー、テスト失敗ときてプロダクトコードを書くための過程の状態です。それまでの間に、ちゃんとテストが通っていない実装があることが目に見えている状況を作り出しています。これで全体としてはテストが通っているけど、失敗もエラーも起きない隠れた実装ミスや不要なものがあるという不安定な状況を意図的になくそうとしています。
ここまで厳密にやる必要があるのか？と思う人がいるでしょう。もちろん、人によっては、こんなことやらなくても、ぱぱっと1度で完全なコードを実装出来る人もいると思います。私のように、そうでない人は何かしらの手段で実装モレや不要な実装を残さない手段は取っておくと良いのかなと思いました。
実装する時は最初からパフォーマンス重視にせず、基本は可読性を意識する
もう1つは、リファクタリングを通じて重複を排除していく箇所でこのような記述がありました。
don't let the performance factor outweigh improved design and readability unless there is proof the code is contributing to a specific performance problem.
今リファクタリングしようとしているコードがパフォーマンス上の問題箇所であるという証明がないなら、可読性を重視しろということです。
これは組み込みで大事な性能を無視しろということを言っているわけではありません。ディスカッションでも意見が挙がりましたが、パフォーマンス上の問題はちゃんとプロファイラなどのツールで計測して、ボトルネックを明らかにしてから対処するべきです。どこにボトルネックがあるかを明らかにしないまま闇雲にパフォーマンス重視なコードを書いていては、保守性が下がり、開発コストに悪影響を与えます。
なので以下がいいのかなと思いました。
- アーキテクチャ設計の段階でちゃん性能要求を満たすよう設計しておく。
- アーキテクチャを固める段階、プロジェクト序盤でプロファイリングなどを使って性能のボトルネックを明らかにして対処する。
- 個々の実装では可読性を重視した実装へリファクタリングする。
今日はオフトピとして各自の工夫についても披露してもらいました
1つ目はEclipseを使い、ファイル保存時にビルド・テストが走らせること（これは私が話しました）。Eclipseには、ファイル保存時にビルドコマンドを実行する設定があります。これを有効にしておくと、Makefaileを修正して静的解析・コードフォーマット・カバレッジのツールを自動実行でき、非常に楽チンで良いかなと思っています。
2つ目は静的解析ツールAdLintをビルド時に実行すること（うちの先輩が開発してるんで宣伝させてもらいました^^;）。まだ「Mac OS X LionにC言語用静的解析ツールAdLintをインストールした」に書いたとおり調べている途中で、案を話した程度です。次回くらいに披露したいですね。
3つ目はコード整形ツールを使ってコード書式を自動で統一するという内容。今日、紹介されたのはArtistic Styleというツール。今日の話では、ビルド時に毎回Artistic Styleを走らせてコード書式の統一を強制するやり方はどうか？とい話でした。意図しない成形が起こる場合があるので注意が必要ですが、コード書式の統一をツールで自動化するのは有用だと思いました。
4つ目はカバレッジ計測ツールの利用です。皆さんgccを使っているのでgcovというツールが良さそうだというアドバイスがありました。
次回の予定は？
次回は4月にやります。そのうち案内を出します。
読む範囲は第5章「Embedded TDD Strategy」と第6章「Yeah, but...」になる予定です。前者は組み込み開発にTDDを適用する際に、後者は周囲の人にTDDを導入を勧める際に役立ちそうな内容だと期待しています。
0 件のコメント:
コメントを投稿