「開発イテレーション偏重」を読んで

本記事では、shinichiro_hさんのブログ記事「開発イテレーション偏重」を読んだ感想を、普段業務で C++ を使っている二人が語り合います。

開発イテレーションを早く回すためにやっていることとして６項目挙がっているので、順に見ていきましょう。

よろしく。

早速、１つ目の項目は「2手で変更の正当性を高速に確認できるようにする」。 ワンアクションビルドは、C++ Coding Standardsという本でも強調されてたね。C++ の本なのに C++ に限らない話が書かれていたので印象に残ってる。

確かに、あちこちでコマンド叩くというのは非常に良くない。今のプロジェクトに参加した時に困りました。

ここではプラスワンアクションで、テストが走ること、も求められている。

make check というのは最近ソースコードレビューで見た気が、、、。

それはモロに、こちらのブログ記事を読んだ影響だよ（笑）。 それまで make で check が標準ターゲットだということ自体知らなかったからね。

次の項目は「細かいユニットテストを避ける」。 これは同意だけど、どこからが細かすぎるのかという境界が難しいと思う。

例えば文字列処理関数のような部品関数なら、しっかりユニットテストをすればいいと思う。 他方、一箇所からしか呼び出されない関数とかの場合、ユニットテストの効果がかなり落ちるのは事実。 で、境界がどこなのかというと、これは確かに難しい問題。

あと、排他制御のバグもユニットテストではまず見つからない。排他制御に関しては、気をつけてコーディングする、くらいしか対策のしようがないような気がする。

排他制御対策の第一は、そもそもマルチスレッドを使わないこと。 使う場合でも、C++ のようなオブジェクト指向言語なら、public関数をちゃんと定義すれば、気をつけなければならない箇所は意外と絞れると思うけどね。

次は「ヘッダを最小化する」。 C++ だとテンプレートを使うとなかなか苦しい。

最近レビューしてもらったユニットテストで、lest を使ってるでしょ。あれはヘッダーオンリーで気軽に使えるから気に入ってるんだけど、その分コンパイルは遅いんだよね。

確かに遅い気がしました。 xUnit系はイヤだとして、他の候補も試してみる価値はありそうです。

続いて「やたらチェックする」。 ここで紹介されている glog は Google Log の略で、作ったのが shinichiro_hさんみたいなんだよね。

それは深く使いこなしているのも納得ですね。CHECK_EQ(x, y) というマクロに << z と入力ストリームを与えるのは、かなり独自な書式と思いました。 最後の stringify というのは？

自分も知らなかったから事前に調べたよ（笑）。 Javascript の JSON ライブラリ関数のことらしい。要は dump のことだね。

なるほど。面倒だけど、そこは手を抜かないということですね。

次は「最適化オプションつきで開発」。 ビルドはリリースビルド相当が基本ということかな。

我々のプロジェクトも同じですね（笑）。 プロジェクトに参加した時、デバッグビルドの存在がないことが驚きでした。

我々の場合、何か思想があるわけじゃないけどね（笑）。

gdb も時々しか使わないから、詳細を調べなきゃいけなくなって初めて -g をつける場合もある、ということですね。 ブログ記事に書いてる通り、ケースバイケースにはなりそうですが。

最後は「なるべく auto を使わない」。 これは完全に同意。auto を使うと書くのは早くなるけど、読むのが遅くなるので、トータルでは時間を損すると思ってる。

この前 Review Board のソースコード（Python）を見る機会があったけど、動的型でクラスをバンバン使っていたから、全然読み進めず、歯痒い思いをしたことがあった。C++ でも auto も使ってしまうと同じことが起こるように思う。 ちなみに、namespace をガンガン使うのはいいのですかね？　using namespace はスコープが効くし。

階層が深くなり過ぎないように気を付けた方がいい。common系と、アプリ単位、あともう１階層くらいで収められたらベスト。

namespaceにあまり馴染みがないんですよね。

うちらのプロジェクトは C言語から来た人が多いから、接頭語の文化の方が強いよね。