作者dream1124 (全新开始)
看板java
标题Re: [问题] 专案很肥大重新build,需要很多时间
时间Tue Jul 7 21:31:36 2015
※ 引述《supercygnus (......)》之铭言：
我猜你的问题跟我公司专案一样，都是老专案而且我们 eclipse 版本还比你旧，
记忆体吃更多，改个设定重启一次伺服器就要 15 分钟.... 久到非常消磨士气...
但原始码很大一包其实不是错，大是因为要做很多事情，只要不是大而无用就好。
可是你会说... 专案一大，IDE 就卡，然後开发就慢，该怎麽办？
仔细想想平常开发功能时，IDE 真的需要载入那麽多原始码，
不断建置、不断完整检查语法有错吗？ 很多类别明明就用不到吧？
既然这些类别的原始码根本用不到，为什麽不先编译好才引到专案中呢？
因此改善开发效率的可行做法是把系统模组化或是分层，
然後各层各模组分别建置，再用执行套件的管理伺服器统一建档保管。
等到开发时再用相依性管理工具 (ant ivy, maven, gradle) 宣告
要开发的程式会依赖在哪些函式库，接着让相依性管理工具在建置的时候
自动帮你从管理伺服器取回函式库，这样就不用每次 IDE 一打开
就必须抱着一堆原始码，不停的检查语法有没有错、不停的建置，永远都在卡。
引入相依性管理後，IDE 的反应才会快，你开发速度也会跟着快，
生产效率就会大幅提高。
但残酷的是，通常若没有足够权限的高阶主管支持你改革，
要在长时间维护的旧专案引入这种管理专案的机制几乎是不可能的。
光是上面不写程式的长官能感受到有这种问题就不容易，
发现了往往也只会介定「IDE 让开发人员一直等」只是感觉问题而不用优先解决，
却未必会细想 IDE 很卡其实是专案管理方式不佳的徵兆，这会明显拖累开发效率。
此外还有太多政治和技术问题，一般基层只能期盼未来新专案能一开始就有好规划。
其实这也是我最後决定做的事，在因缘际会下我调到另一个研究新开发技术
以推广到其他部门的团队，而我也趁这机会以「典范转移」号召大家引入好的机制。
运气好的是团队成员既愿意接纳我的想法又很可靠，
让我们能一口气换掉一堆腐烂的东西，导入好方法。
档案库从完全不敷日常使用的极旧版本 CVS 换成 git、
持续整合从公司人员自行开发，服务范围很小又没人会维护的伺服器换成 jenkins，
建置从全公司都几乎没人想也没人会维护的 ant 换成 gradle，
相依性开始用 gradle 管理，还引入 Nexus 管理执行档，工作环境焕然一新。
如果你也想改善开发环境，升级大家的开发方法，就努力研究新技术新方法，
找机会革新吧，不然这种开发方法落後又没有主管在意的旧专案，
还真的建议快逃，留下来往往是消磨斗志罢了....
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.231.187.127
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/java/M.1436275898.A.ED0.html
※ 编辑: dream1124 (61.231.187.127), 07/07/2015 21:34:41
1F：推 felixgugu: 是很理想，但大多数时候太难了..... 07/07 23:18
2F：推 qrtt1: 真是个好消息，宁静革命终於开花结果了 07/07 23:19
4F：→ qrtt1: soft_job 相关的系列「前辈拒绝导入任何其他工具」也蛮值得 07/07 23:23
5F：→ qrtt1: 去回顾一下当下的困境与版友的建议的. 07/07 23:23
写那篇旧文的时候是初牲之犊不畏虎，那时候我在板上也被批得很惨，
後来我也能体谅前辈说那些话背後的苦衷。
不过我想可能是有自信，赌定新团队要靠我研究新技术，不敢完全不理我的意见，
然後也不怕黑不怕死吧，到新团队以後还是有什麽想法都勇敢地用正用的方式提出来。
运气不错的是团队成员刚好各司所长，开发时程又能配合，导入新工具就比较顺利。
我有一样是怪人，支持我理念的技术研发前辈跟我一起横冲直撞，省很多沟通成本。
前辈规划新开发环境的硬体、选用作业系统和伺服器并调教设定，解除我的後顾之忧。
而我则规划应用程式要套用的框架，设计整合各框架的架构，然後选用并整合开发工具。
此外还有适应公司文化，会用「公司惯用方法」和更上级沟通，润滑两方的 PM，
以及善解人意又有耐性的同事帮忙我处理来不及做完的事情，验证我设计的架构。
最後我们就慢慢做到现在的状态。
虽然我们都很认真引入新工具，但这些事情能走到这步其实超过 40% 的比例是运气，
刚好天时地利人和都具备。目前革命也还不算完成，後续还有很多细节要规划。
另外我觉得自己经过这一阵革新之後应该也很黑，但我其实不是很在意更上层的看法，
因为一来虽然不讨厌政治，但我本来就不喜欢整天钻研应对进退搞政治；
二来有些高层的想法太旧又僵硬，只愿意从他接受的管道用认同的方法沟通，
我觉得自己没有耐性花很多年慢慢跟他们磨合，升迁到有权限之後才来做这些事，
到时候我早就年纪不轻又没有热诚了。
他们愿意接纳提议，改善我受不了的环境问题... 很好，我们就来冲锋陷阵
他们不愿意接纳提议，又讲不出好理由... 没关系道不同不相为谋，适当时机分道扬镳
我是本着这种态度向他们推广新事物的。
6F：推 yfr: 哈，我想起那时候那篇文章了，你真是不简单 07/07 23:49
7F：→ yfr: 可以用一些先进的工具来简化工作流程真是一件很棒的事 07/07 23:51
8F：→ yfr: 我好奇的是为什麽选择gradle而不是maven呢 ? 07/07 23:53
因为我们专案建置过程复杂，用 maven 这种 xml 语法作为建置档的工具较不易实现。
※ 编辑: dream1124 (61.231.187.127), 07/08/2015 01:51:43
9F：推 yfr: 了解，大概懂你考量的点，我之前也曾经试过从ant升上去maven 07/08 09:02
10F：→ yfr: 即便那时那个专案不大却也有许多非正规maven建置流程的步骤 07/08 09:03
11F：→ yfr: 那时就遇到许多挑战了，有机会我会试着玩看看gradle 07/08 09:05
12F：→ qrtt1: 所以，你是换了公司吗 xd? 07/08 09:09
13F：推 andymai: 推，上面和同事支持很重要，不然会心力交瘁，到最後一样 07/08 09:38
14F：→ andymai: 只好选择离开 07/08 09:38
15F：→ qrtt1: 其实只要同事不反对，没有明显抗拒就蛮容易成事了。 07/08 10:01
16F：→ qrtt1: 因为导入新方法会有显着的改善困境，享受过就「回不去了」 07/08 10:01
其实我觉得某种层面来说，我是长期压抑的开发人员之宣泄口。
全公司只要还有在碰程式或技术的人几乎都想改变，只有少数高层还是状况外。
职级差不多的人都满支持我运用这些新工具和新方法。
17F：→ realmeat: 从一个makefile换成另一个makefile.. 世界会变的更美好? 07/08 11:46
试着从 Ant (不含 ivy 唷) 跳到 gradle 一次你就知道了
※ 编辑: dream1124 (118.160.99.40), 07/08/2015 21:26:45