何かがソフトウェアのビルドを壊すのが嫌ではありませんか? ビルドの問題は、余分な、予定外の作業を生み出します。このような問題は、他の問題を解決するために急いでいるときにいつも起こるようです。多くの場合、あなたが今やっていることとは無関係の何らかの要因でビルドが中断されます。そのため、今やっていることを中断して、ビルドが壊れた原因を調べて、その問題を修正して、ビルドを再起動しなければならないのは、かなりイライラさせられます (解決すべき問題が 1 つしかないことを願っています)。
今日、いくつかのオープンソースのパッケージを再構築しているときに、この問題に遭遇しました。数ヶ月前、OpenSSL をバージョン 1.0.0 に更新しましたが、それに依存するパッケージをすべてリビルドしたわけではありませんでした。たまたまですが、バグ修正のために subversion クライアントをリビルドしに行ったときに、OpenSSL 1.0.0 で互換性のない変更がいくつか導入されたために subversion のビルドが壊れていることがわかりました。この問題は数ヶ月前に修正されていたので、修正方法を見つけるのに時間はかかりませんでしたし、簡単なウェブ検索でバグレポートと修正方法の両方が見つかりました。しかし、製品を再構築しようとしているときにこの問題に遭遇するのは、いらいらさせられるものでした。
私はここで素晴らしい提案をするつもりはありません。しかし 私には観察があります それは機械の時間が豊富になったということですたぶん、私たちは毎晩すべてのソフトウェアを単純に再構築すべきだと思います。そうすれば、問題がまだ誰の心にも残っているときにビルドの問題を捕まえることができるでしょう。
また、念のために、ビルドプロセスの中にいくつかの手動ステップがある場合は、頻繁にリビルドすることを決めることは、それらを排除するための良いインセンティブになります。マニュアルステップはエラーの原因になりがちです。
ソフトウェアテスターは、一度テストしたソフトウェアを再構築することを嫌う傾向があります。彼らはそれを、新しい欠陥を導入する機会と見なしています。私は、ビルドツール (コンパイラ、リンカ、makefile) に十分な自信を持って、いつでも再構築できるようにしたいと思っています。高レベルの言語で作業していることを考えると、ビルドツールに自信を持たなければなりません。 しかし、段階的な開発プロセスの中では、両方の見方ができる余地は十分にあります。
ビルドが壊れる可能性を最小限に抑えるためにソフトウェア開発を管理する方法や、ビルドの問題を修正するのに必要な労力を最小限に抑える方法についての提案があれば、この投稿にコメントを追加してください。