モダンC言語プログラミング 統合開発環境、デザインパターン、エクストリーム・プログラミング、テスト駆動開発、リファクタリング、継続的インテグレーションの活用

花井志生(著者)

• 販売会社／発売会社: アスキー ドワンゴ/KADOKAWA
• 発売年月日: 2019/01/31
• JAN: 9784048930673

商品レビュー

2024/04/20

おそらく、古い環境のCを使った開発環境の人には刺さる部分もあるのだと思う。
対象読者として、Cで開発をしていて、昔ながらの開発環境で、でもその環境を新しくしたくて、とはいえ自分でそれをやっていくことができるほどではない、と言ったような人に対して、具体的な例で説明・チュートリアルをしていくスタイルの本。

なのだけど、基本的に具体論に終始しているのでその具体論が古かったり自分と合わないものだったりすると読み進める意味がない、と思える箇所がままあった。（e.g. 今時Eclipseか、とか、そんなビルドツール使ってるの耳にしないなあとか）

モダナイズするためにここをこう変える、という抽象論と、それの具体論とを、章立てだったり構成だったりでもっと分けて示すと読みやすかったように思う。

2022/01/22

あのCでもオブジェクト指向ライクにかけるんだという希望を見せつつ、一方でそのためにC++であればコンパイラがやってくれることを人間がやらなければならず、とてつもない絶望も見せてくれる本。Cを使うくらいなら.cppにしてC++の中のCを使った方がいいというのは上司の談。
本の構成としては、Cでの開発の概念的な説明と開発環境の準備で1/3、Cでのオブジェクト指向とデザインパターンの実現方法について1/3、リファクタリングと継続的インテグレーションとデプロイで1/3という構成になっているので頭から読んでも問題ないし、オブジェクト指向から読んでも問題ない。というよりこの本のキモは後半2/3である。
Ｃにおいて継承・ポリモーフィズムをどう実現するかというのが書かれている。具体的にはvoidポインタや構造体ポインタ、関数ポインタなどいわゆるＣの入門書では難しいと扱われ、下手すると記載されていない機能を使って実装している。そのためＣができるといえるにはこれらを使いこなす必要があるということである。オブジェクト指向でクラスが重要な役割を果たし、それらが状態と振舞で成り立っているとするなら、クラスの源になった構造体、そしてＣにおいては振舞を持たせるのに関数ポインタが必要にあるということを理解していれば、この怒涛のポインタの扱いについて気圧されることはないだろう。また仮想関数テーブルの実装も記載されているので、Ｃ＋＋の理解にも役に立つ（というより必須）。このことから著者の頭の中にＣ＋＋の知識が前提にあることはもちろん、Ｃを使いこなすのにＣ＋＋の知識が必要であり、Ｃ＋＋を理解するのにＣの知識が必要であることも推測できる。
デザインパターンについてはState、Template Method、Observer、Chain of Responsibility、Visitorが記載されている。Cで特に使えるものをピックアップしたとされているが、そもそもこれらのパターンを本来のオブジェクト指向言語でどう実装し、どういう時に使われるものかというのを理解していないと、Cでなんとかやりくりして実装している都合上理解はややしづらい。そのため、他のデザインパターン本で予習してから読むのが望ましいと思われる。
後半のリファクタリング以降は、Gtestを使っていて、かつテストやリファクタリングについてのCにおける注意点などもちらほら書かれているので読んで損はない。ただしjenkinsの設定や使い方だったりSConsやvalgrindなど特定のツールの使い方の説明も含まれているため、分量に比べて得られるものは少ない。よってキモはオブジェクト指向部分と思ってよい。
今日ではCを使うのは組み込みでの限られた場面でしかないと思われるのでその点についてフォーカスをあててテストやデザインパターンのことを書いてあるのは好ましい。
全体として分量からみて余計な情報もある。自分で体験してくという構成上しかたないツールの説明などがそれにあたる。しかし残りの部分はそれを補ってあまりある質なので、本自体の品質は非常に高いと思う。Cを直接使うことはなくC++だけという人も理解を深めるために読んでみる価値のある本だと思う。
まあそもそもC+＋を最初から使えるなら使ってしまった方がいいという点は否めない。

2019/03/31

■知りたいこと
Cによる組み込み開発において、
・デザインパターンをどう実現するか
・TDD（テスト駆動開発）やCI（継続的インテグレーション）をどう実現するか

■総評
Cによるオブジェクト指向プログラミングやデザインパターンは、実用性がないと思う。
テストについては、モック化やstatic関数などの難しいところをどうすればいいのかを知りたかったが、結局は人手で頑張らなくてはいけないという当たり前の結論であった。
単体テストは労力を注ぎ込む領域ではないように思えるので、有償ツールがあるなら、それを買って済ませた方がいいのかもしれない。

■TDDの実践に必要なツール
・単体テストツール
　Google Testは便利そう。
・カバレッジ測定ツール
・モック化ツール
　モック化ツールは適当なものが存在しない。自分でCの関数をモック化する必要がある。

■OOP, デザインパターン
Cによるオブジェクト指向プログラミングの実現方法、および、Cに対するデザインパターンの適用方法が記載されているが、OOPはかなり無理があると感じた。変更局所化という意味での保守性は上がるかもしれないが、可読性という意味での保守性は下がると思う。やるとしてもLinuxカーネルのように関数ポインタを使うまで。ここまでやるなら最初からC++を使う方がいいと思う。
デザインパターンの章は読んでも意味がないと思い、読まなかった。

■単体テスト
・単体テストは品質保証ではない。ケアレスミスを発見するためのダブルチェックぐらいに考えるのがよい。テストを厳密に書いてしまうと、テスト作成作業のコストが単体テストのメリットを上回ってしまうことや、コード修正時にテストが壊れやすくなってしまうことなどの問題が発生する。

・モック化の方法
　(1)「ライブラリ差し替え」「マクロを利用した差し替え」…現実的
　　①H/Wアクセス箇所をライブラリにまとめておき、単体テスト時はライブラリをにせものに差し替え
　　②H/W呼び出しの入り口をすべてマクロにしておき、単体テスト時はマクロ定義を変更
　(2)「オブジェクト指向によるモックの実現」………保守性（可読性）が問題だと思う
　(3)「関数ポインタとマクロによるモックの実現」…保守性（可読性）が問題だと思う

・static関数をどうやってテストするのか
　(1) テストしない：
　　　あるモジュールが、外部公開I/Fのみを使ってテスト可能である場合に有効な考え方。数学的な処理や、アルゴリズムを実装したモジュールが該当（＝副作用がない場合？）
　(2) テストコードからテスト対象のソースコードをincludeする。

■CI
「6,4 CI入門編」は、実際にCIを始める際に読むと役に立つかもしれない。