※ 引述《supercygnus (......)》之铭言：
我猜你的问题跟我公司专案一样，都是老专案而且我们 eclipse 版本还比你旧，
内存吃更多，改个设定重启一次服务器就要 15 分钟.... 久到非常消磨士气...
但原始码很大一包其实不是错，大是因为要做很多事情，只要不是大而无用就好。
可是你会说... 专案一大，IDE 就卡，然后开发就慢，该怎么办？
仔细想想平常开发功能时，IDE 真的需要加载那么多原始码，
不断建置、不断完整检查语法有错吗？ 很多类别明明就用不到吧？
既然这些类别的原始码根本用不到，为什么不先编译好才引到专案中呢？
因此改善开发效率的可行做法是把系统模组化或是分层，
然后各层各模组分别建置，再用执行套件的管理服务器统一建档保管。
等到开发时再用相依性管理工具 (ant ivy, maven, gradle) 宣告
要开发的程式会依赖在哪些函式库，接着让相依性管理工具在建置的时候
自动帮你从管理服务器取回函式库，这样就不用每次 IDE 一打开
就必须抱着一堆原始码，不停的检查语法有没有错、不停的建置，永远都在卡。
引入相依性管理后，IDE 的反应才会快，你开发速度也会跟着快，
生产效率就会大幅提高。
但残酷的是，通常若没有足够权限的高阶主管支持你改革，
要在长时间维护的旧专案引入这种管理专案的机制几乎是不可能的。
光是上面不写程式的长官能感受到有这种问题就不容易，
发现了往往也只会介定“IDE 让开发人员一直等”只是感觉问题而不用优先解决，
却未必会细想 IDE 很卡其实是专案管理方式不佳的征兆，这会明显拖累开发效率。
此外还有太多政治和技术问题，一般基层只能期盼未来新专案能一开始就有好规划。
其实这也是我最后决定做的事，在因缘际会下我调到另一个研究新开发技术
以推广到其他部门的团队，而我也趁这机会以“典范转移”号召大家引入好的机制。
运气好的是团队成员既愿意接纳我的想法又很可靠，
让我们能一口气换掉一堆腐烂的东西，导入好方法。
档案库从完全不敷日常使用的极旧版本 CVS 换成 git、
持续整合从公司人员自行开发，服务范围很小又没人会维护的服务器换成 jenkins，
建置从全公司都几乎没人想也没人会维护的 ant 换成 gradle，
相依性开始用 gradle 管理，还引入 Nexus 管理执行档，工作环境焕然一新。
如果你也想改善开发环境，升级大家的开发方法，就努力研究新技术新方法，
找机会革新吧，不然这种开发方法落后又没有主管在意的旧专案，
还真的建议快逃，留下来往往是消磨斗志罢了....

是很理想，但大多数时候太难了.....

真是个好消息，宁静革命终于开花结果了@felixgugu 不要灰心，只需要持续做 http://bit.ly/1MbnR6osoft_job 相关的系列“前辈拒绝导入任何其他工具”也蛮值得去回顾一下当下的困境与版友的建议的.

哈，我想起那时候那篇文章了，你真是不简单可以用一些先进的工具来简化工作流程真是一件很棒的事我好奇的是为什么选择gradle而不是maven呢 ?

所以，你是换了公司吗 xd?

推，上面和同事支持很重要，不然会心力交瘁，到最后一样只好选择离开

其实只要同事不反对，没有明显抗拒就蛮容易成事了。因为导入新方法会有显著的改善困境，享受过就“回不去了”

从一个makefile换成另一个makefile.. 世界会变的更美好?