3

これはコードのコンパイルに関するものであり、他には何もありません.. :)

だから、私は会社の初心者であり、予想通り、非常に遅いコンピューターに行き詰まりました。また、ビルドを作成するたびに Netbeans のメモリ/リソースが不足するという大きな問題が発生しています。JAVA ファイルをコンパイルしています。

私は 7.0 を使用していましたが、このエラーが発生していましたが、ソース パッケージをチャンクでコンパイルすることで問題を解決しました。（選択したものを複数回コンパイルする必要がある場合がありました）

しかし、私が 7.2 に移行して以来、この問題は悪化しています。パッケージをさらに小さなチャンクにコンパイルする必要があります。場合によっては、パッケージごと、ファイルごとにパッケージ化します。したがって、私には多くの時間がかかり、髪の毛も多くなります。

最初にコンパイルするパッケージがわかりません。ネットビーンズがそれを処理していました。したがって、リソースを取ります。

私の同僚のほとんどは強力なコンピューターを持っており、ソース ベース全体の構築に問題はありません。それで、私はコンパイルされたパッケージを入手し始め、必要なものだけをビルドしました。

では、これは正しいアプローチですか、それともソース全体をビルドするのですか (任意の時点でコード ベース全体の 1% を変更するだけですが)?

ほとんどの変更は 1% にすぎませんが、この会社のほぼ全員が少なくとも 1 回はコード ベース全体を構築しています。

4

5 に答える 5

2

プロジェクト全体をビルドして設計どおりに動作させ、その後 99% をビルドしても動作しない方がはるかに優れています。1% が重要なコードであるか重要でないコードであるかを示すものはなく、初心者としてすぐにそれを判断することはできません。

チームメイトや IT 担当者にビルドが遅いことを知らせ、コードをチャンクでビルドするのではなく、それを解決するために何ができるかを尋ねます。

于 2012-08-02T14:48:56.763 に答える
2

生産性の低下とハードウェア コストの違いを説明するときは、開発者が遅いマシンを使用して作業を妨げている問題を強調する必要があるかもしれません。

そうすれば、「99%」を構築することについて心配するのをやめて、実際の問題に取り組むことができます。

于 2012-08-02T14:50:16.910 に答える
1

それで、これは正しいアプローチですか、それともソース全体を構築していますか（いつでもコードベース全体の1％に変更を加えただけですが）？

すべての内部依存関係を完全に理解し、変更が行われた後に近くのモジュールで予期しない動作が発生しないことを保証できる場合にのみ、プロジェクトの一部のみをビルドできると思います。私の意見です。さらに、コードを変更してコンパイルすることはできますが、プロジェクトビルド全体が同じように失敗する可能性があります。

PSあなたはあなたに新しいコンピュータを買うために会社を得る必要があります。

于 2012-08-02T14:53:11.750 に答える
1

プロジェクト全体をビルドすることをお勧めします。調整してみてくださいnetbeans.conf 

netbeans_default_options="-J-client -J-Xss4m -J-Xms128m -J-XX:PermSize=128m -J-XX:MaxPermSize=512m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true-J-XX:+UseParNewGC -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled"
于 2012-08-02T14:53:14.513 に答える
0

理論的には、すべての依存関係を調べて、自分自身を依存関係の階層マップにすることができます。変更したコードとそれに依存するすべてのものをコンパイルするだけでよいはずです。ただし、必ずしも 100% 誰にでもできるわけではなく、わずかな利益のために多くの努力が必要です。初心者の責任で解決できると私が期待するものではありません。むしろ、上司が適切なキットを使用して解決する必要があります。

于 2012-08-02T14:54:26.273 に答える