※ 引述《supercygnus (......)》之銘言：
我猜你的問題跟我公司專案一樣，都是老專案而且我們 eclipse 版本還比你舊，
記憶體吃更多，改個設定重啟一次伺服器就要 15 分鐘.... 久到非常消磨士氣...
但原始碼很大一包其實不是錯，大是因為要做很多事情，只要不是大而無用就好。
可是你會說... 專案一大，IDE 就卡，然後開發就慢，該怎麼辦？
仔細想想平常開發功能時，IDE 真的需要載入那麼多原始碼，
不斷建置、不斷完整檢查語法有錯嗎？ 很多類別明明就用不到吧？
既然這些類別的原始碼根本用不到，為什麼不先編譯好才引到專案中呢？
因此改善開發效率的可行做法是把系統模組化或是分層，
然後各層各模組分別建置，再用執行套件的管理伺服器統一建檔保管。
等到開發時再用相依性管理工具 (ant ivy, maven, gradle) 宣告
要開發的程式會依賴在哪些函式庫，接著讓相依性管理工具在建置的時候
自動幫你從管理伺服器取回函式庫，這樣就不用每次 IDE 一打開
就必須抱著一堆原始碼，不停的檢查語法有沒有錯、不停的建置，永遠都在卡。
引入相依性管理後，IDE 的反應才會快，你開發速度也會跟著快，
生產效率就會大幅提高。
但殘酷的是，通常若沒有足夠權限的高階主管支持你改革，
要在長時間維護的舊專案引入這種管理專案的機制幾乎是不可能的。
光是上面不寫程式的長官能感受到有這種問題就不容易，
發現了往往也只會介定「IDE 讓開發人員一直等」只是感覺問題而不用優先解決，
卻未必會細想 IDE 很卡其實是專案管理方式不佳的徵兆，這會明顯拖累開發效率。
此外還有太多政治和技術問題，一般基層只能期盼未來新專案能一開始就有好規劃。
其實這也是我最後決定做的事，在因緣際會下我調到另一個研究新開發技術
以推廣到其他部門的團隊，而我也趁這機會以「典範轉移」號召大家引入好的機制。
運氣好的是團隊成員既願意接納我的想法又很可靠，
讓我們能一口氣換掉一堆腐爛的東西，導入好方法。
檔案庫從完全不敷日常使用的極舊版本 CVS 換成 git、
持續整合從公司人員自行開發，服務範圍很小又沒人會維護的伺服器換成 jenkins，
建置從全公司都幾乎沒人想也沒人會維護的 ant 換成 gradle，
相依性開始用 gradle 管理，還引入 Nexus 管理執行檔，工作環境煥然一新。
如果你也想改善開發環境，升級大家的開發方法，就努力研究新技術新方法，
找機會革新吧，不然這種開發方法落後又沒有主管在意的舊專案，
還真的建議快逃，留下來往往是消磨鬥志罷了....