Man*_*noj 5 version-control project-management design-patterns
我的项目邀请我对生产代码进行大量更改.需求不断出现,我需要尽快进行更改并进行部署.我有时最终会创建补丁工作类代码,因为某些要求不适合软件的整体设计.如何有效处理？任何设计模式来处理这个？
Ste*_*ton 14
我已经看过很多次这种情况,它总是以泪水结束.客户最后一次在改进流程之前损失了数百万美元.
用户总是希望"尽快"提供新的要求,但他们并不了解以与您相同的方式进行更改的风险.他们看到没有这项功能的成本,但他们没有预料到会发生什么,如果改变会破坏某些东西会损失多少钱.(我并不是说你不是一个好的开发人员,只是在任何非平凡的软件中都会出现错误,并且不受控制的更改可能会更快地暴露它们.)
所以,我认为你需要退后一步,试图发起一个定期的发布时间表.会有阻力,但你可以更有效.当然有时会是需要立即做出了改变,但如果有一个时间表,然后的责任将会对用户解释为何打破了发布周期是有意义的.
哦,正如其他人所说,你需要技术基础设施,如登台/测试系统,一键发布程序等.(参见乔尔测试.)
测试时,您需要一个可靠的测试框架,以确保您的修复不会破坏其他任何内容.
编辑:回答评论的问题.
不幸的是,除了花时间重构"黑客"之外,我无法想到一个真正完善的模式/解决方案来保持架构的完整性.但是你可能没有多余的时间来备用,因为你已经在生产中了.所以这并不容易......
但更重要的是,如果架构因为你真的需要"破解"解决方案而被破坏,这实际上可能表明原始设计不符合产品的实际要求,因为如果是,你应该能够在Architecture的当前框架中修复/补丁.
因此,为了对整个情况保持积极态度,您应该注意到您的修复,以及当前架构如何帮助/遵守,以便您可以在以后的路上,当热修复程序开始解决时,有数据和提示至于重新设计架构的任何部分需要设计,因为您在生产过程中发现了更准确的要求.
| 归档时间： |
|
| 查看次数： |
588 次 |
| 最近记录： |