スポンサーサイト 

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

最近の私の嗜好:Makefileのターゲット 

eclipseなどのIDEも素晴らしいと思うのですが、makeもまだまだ健在です。 makeの中でも一番多く使われているのはおそらくgnu makeでしょう。ただやはりMakefileの記述は簡単なものではなく、 build環境が大きくなってくると特にgnu makeのように機能が多いmakeではMakefileの記述に嗜好が表れてきます。 以下は最近の私のTop DirectoryにおけるMakefileの私の嗜好です。

サブディレクトリを再帰的にmakeを起動していくやり方は多くの場面で見られます。大体こんな感じでしょうか。


SUB_DIRS = SubDir1 SubDir2 ReleaseDir

all:
    @for subdir in $(SUB_DIRS) ; do \
        (cd $$subdir && $(MAKE) $@) ;\
    done


私はこれに少し手を加えて


SUB_DIRS = SubDir1 SubDir2 ReleaseDir

%.subdirs:
    @for subdir in $(SUB_DIRS) ; do \
        (cd $$subdir && $(MAKE) $(basename $@)) ;\
    done


としています。こうしておくとtargetがclean、dependなどと増えていっても


clean: clean.subdirs
depend: depend.subdirs


と2行加えるだけで済みます。

その他、私の今までの体験では特定のディレクトリだけmakeをかけたいというケースがありました。 そのようなケースに対応するために以下のようなターゲットも用意するようになりました。


%.all:
    @cd $(basename $@) && $(MAKE) all


これですと、make SubDir1.allというようにmakeを実行すればSubDir1にだけmakeが実行されます。 SubDir1/SubDir1_1にmakeをかけたければ make SubDir1/SubDir1_1.allで行えます。 もちろんSubDir1/SubDir1_1にMakefileがなければいけませんが。

 


スポンサーサイト

最近の私の嗜好:ラベルの付け方 

以前はCでラベルをつけるときに全部小文字+アンダースコアで書いていたのですが、最近はCamelCase+アンダースコアになっています。

 

例えばややこしい初期化が必要なデバイスを扱う際にdevice_init_phase_1stなんてラベルをつけると、 これは関数名なのかenumか何かで表された値なのかがわかりにくくなります。 そのため関数であればDevice_InitPhase1st()、 値であればDeviceInitPhase_1stのような書き方をするようになりました。 アンダースコアより前をnamespaceっぽく使おうというわけです。 namespaceを構成するときのポリシーというのをあまり見かけないのですが、何か基本があるのでしょうかね。

 

まあ、こんなことをやるのならC++をベターなCとして使いたいのですが、仕事となるとそうもいかないですからね。

 

 


バグの優先順位が致命的とかでいいのだろうか? 

多くのバグトラッキングシステムにはそれぞれのバグに対して 優先順位がつけられるようになっています。致命的とかshowstopperとか criticalなどのような順位を見たことがある人も多いと思います。 バグの優先順位をつけるときに迷われたことはありませんか?私はあります。

 

そもそも優先順位というのは何の優先順位なのでしょう。ハングアップして しまうものを1、ハングアップはしないものの、プロダクトとして致命的なものを 2というような順位をつけた場合、「みられまくっちゃ」と入力するとハングアップ する不具合と30秒で通話が途切れてしまう不具合があればどちらを 優先して対応すべきでしょうか?30秒で切れたらかけ直せばいいだけだから ハングアップを先に直そうという判断をするプロジェクトは無いと私は信じています。

 

プロジェクト終了後、今回はたくさんハングアップがでたな、と眺めるための ものだと割り切ってしまえばそれでおしまいですが、プロジェクトの運営に なんらかの影響を与えるものだとすればこのような優先順位のつけ方は あまり有効でないように思えます。

 

通常のプロジェクトではバグが発見された場合に最初に判断されるべきは 修正されるべきか、そうでないかです。別の言い方をすれば 修正する許可が得られる(Do)か保留される(Pendingかです。極論すれば優先順位は この2つでよいと言えるでしょう。これ以上の細分化はプロジェクトの 運営形態などを考慮して行われるべきです。

 

比較的一般的な細分化の例としては修正許可は得られていて 期日までに対応しなければならないものとそうでないもの という分け方があります。この場合だとHigh,Low,Pending という優先順位でしょうか。このような優先順位付けであれば プロジェクト運営においてバグ管理データベースから得られる情報 がどのように活用されるべきかは明確になります。重要なのは 優先順位がきちんとMECEになっていることだと思います。


ワンピース 2006年45号週刊少年ジャンプ 

本を買うときには半分くらいは衝動買いなのですが、突然割り込んできたのが今週号の少年ジャンプでした。 ましてや3連休ということもありいつもの月曜日発売でないということもあって完全に油断してました。

 

ワンピースは多くの場合、バトルシーンが長く繰り返され決着がつき、そして新展開というパターンで話が進みます。 最も長い時間を費やされるバトルシーンではルフィがどん底から逆転しようが何をしようが淡々と読んでいるのですが、 ひとつのエピソードの締めくくりに時折見せる暴力的なまでの引きずり込ませ力に今回思いっきりやられてしまいました。

 

そもそもゴーイングメリー号の修理から始まったエピソードですから、長い長いバトルの後、 ゴーイングメリー号で締めくくるというのは至極全うな流れだと思います。しかし、そりゃちょっと都合が良すぎませんか、と先週から思いつつ、 電車の中で必死で涙をこらえてる自分は何なんだと。。。言えるのはおそらくこの号だけ読んだのでは、頼むからあやまんないでくれよ、 とは思わなかっただろうということ。アラバスタ編のバッテンとならぶ締めくくり。少年ジャンプをろ過しつくすとこうなるのでしょうか。

 


Tracにclosedが無いことを前向きに考えてみる 

TracというIssueTrackingSystemがあります。 導入が容易でSubversionと連携しWikiも使えるということであちこちで使われているのを見ます。 しかし不思議なことに多くのバグトラッキングシステムがopen,assigned,resolved,closedというようなステータスを持っているにもかかわらずTracにはclosedがありません。 (本家のリポジトリのブランチには暫定的にはあるようですが)

 

Tracはデータベースにsqliteを採用していることからも少人数での開発に使われるであろうことが考えられます。 特に組み込み系の開発の場合大企業においても数人で開発しているところも珍しくありません。 closedというのはコードの修正が終わった後、確認作業を行い、正しい動作が確認された状態のことですが、 大企業などでは評価部隊はすでに独自の不具合データベースシステムなどが稼動していることが多く、 開発チームで独自に導入したシステムに対して協力的である可能性は高くないでしょう。また、 ハードウェアを含めて正しく動作することが求められるため、フィールドテストならこちらの部署で、温度系のテストであればこちらの部署で、 UI系のテストはこちらでと評価部隊が複数に分かれていることもあります。そのような場合、 確認作業を行った人がステータスをresolvedからclosedにするという運用ルールを決めたとしてもうまくいくとは思えません。

 

ならばTracでの管理はresolvedまでと割り切ってしまい、 どうしても確認作業が完了していることの管理を行いたいのであればその分だけTypeをToDoなりVerifyなどにして新規にTicketを発行すればよいと思います。 Tracで管理すべき事項はチームの責任範囲内のみと割り切るのもひとつの手ではないでしょうか。

 


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。