数年前、ある仕事で、
コンパイルが遅い＝とてつもなく時間がかかる、ので開発効率が落ちている
というので詳しく状況を聞いたら、以下のような状況でした。
- どうもコンパイラの挙動が信用できないので、いちいち全てのソースをコンパイルしている
- 実はリンクに時間がかかる
- cygwinを使っている(クロス開発環境)
全コンパイルが逐次コンパイルよりも時間がかかるのは当然です。makeとmakedependを適切に利用することで削減可能です。
ですが、間抜けなことに
- 全ソースからインクルードされるヘッダがしょっちゅう更新される
という状況ではそれもままなりません。
本来必要ではないヘッダファイルをインクルードしなきゃいいんですが、
いったん追加した#includeをはずす作業ほど苦痛を伴うものは無い
という物理法則が働きますので大変です。コンパイルエラーやウォーニングを解消するために安易に追加された#includeディレクティブはスパゲッティどころの話ではありません。
リンクに時間がかかるので大変だというのは、最近見直されつつあると（勝手に）思い込んでいますが、実際どうでしょうか。distccとかいう分散コンパイル環境は簡単に構築可能なはずですが、分散リンクは可能でしょうか。
# 使ったことが無いのでわかりません
そしてcygwinを実務で使うならパイロットプロジェクトで、パフォーマンスについてよく調べたほうがよいです。理由はよくわかりませんがcygwin環境ではプロセスの生成がやたらと重いようです。configureスクリプトやmake(からのコンパイラ起動)が遅いです。
# 体感速度で
まぁ、ちょっとした思い出話です。所詮私は一下っ端に過ぎないので状況分析だけしかできなかったわけですが。
さてナイトリビルド的な体制は割りとみかけるのですが、1製品辺りビルド何回くらいになるかをドンブリ勘定でもいいので決めてしまうとマイルストンも設定しやすいのになぁと思ったりします。
そうすれば必要な開発環境のパフォーマンスが設定可能となるような気がするんです。例えば、ビルドマシンの必要数とか性能目標とか。
ベテランさんの中からは、そんなしょっちゅうコンパイルやリンクするような実装の進め方はイカンという声も聞こえてきそうですが、昔のようにアセンブラコード10行のためにレビュアーが3人も4人も集まるような呑気な時代ではなくなってますので。
コンパイルやリンク中も他の仕事をすればよいという意見も多いです。コンカレントに仕事をしろと。ですが、人間のこなせる仕事のコンカレンシはそれほど高くないと思いませんか？
ここら辺になると宗教議論になってしまいそうです。
コメント