只是想听听一些建议(和舒适......),这将帮助我控制一些复杂的意大利面条代码 - 这是由多个程序员(通常从不相遇)长时间开发的代码.解决方案的功能只是相互补充.
通常我倾向于看到两种程序员:
"害怕死亡的程序员" - 那些家伙不会碰任何他们不需要的东西.他们可能会使用快速而肮脏的修复程序完成维护任务,这将使下一个程序员开始寻找他们的家庭地址;-)
专业人士:
它有效
缺点:
你希望你再也不会看到这个代码..
"教师" - 那些可能会重写整个代码,同时完全翻新其逻辑.
专业人士:
嗯,有人必须做肮脏的工作......
缺点:
需要更长的时间,可能其中一个最重要的功能将从产品中神奇地消失
从程序员生活中这个黑暗的一面听到你的个人经历会很高兴.
我特别好奇听到任何理论/实践建议,这将有助于我深入了解意大利面条维护任务而不会感到如此痛苦.
在开始之前,我尝试在测试中包装非常糟糕的遗留代码.老实说,我在测试中非常扼杀它!然后我有信心潜入重构我需要的地方.
你可能想读
书籍封面http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg
有效地使用遗留代码
虽然最好的建议是,正如本主题的其他每一张海报都指出的那样,编写测试时,我经常遇到这种情况不切实际的情况.如果代码那么糟糕(1000行方法,嵌入和未记录的幻数,代码重复等等),它也可能有另一个问题,即它是深度耦合的,组件几乎不可能被隔离.
(示例 - 在启动时加载并缓存数百个不同数据库对象的代码库.组件假设存在缓存的随机部分,缓存的某些部分假定缓存的其他部分 - 另外,您必须加载整个事物得到任何东西 - 代码依赖于静态和混杂的公共状态变量,在那里无法确定谁设置这些变量,甚至是什么意思)
我能提出的最佳建议:
首先尝试修复简单/明显的事情.硬编码路径,幻数引用,明显的代码重复.也许快速发布可以消除最严重的20%违规行为的风险很低,并使下一步更容易实现.
为refarctoring获得组织支持 - 通常没有意愿或愿意做不会增加直接功能的工作,并且有可能破坏现有代码.当然,重构的理由很多,但不是每个人都会购买它们.如果组织不支持,您可能需要放弃.
让其他开发人员接受相同的观点 - 如果他们有任何好处,他们可能会像你一样对代码库感到不满.如果新代码构建为更好的标准并且人们受到激励,他们将开始修复旧代码,因为需要应用调整.
如果某个特定的子系统真的非常糟糕,并且已达到几乎不可能实现新开发的程度,那么您可以利用这个机会重建它.
文献.彻底记录.你做出的每一个改变 - 你发现的每一个警告,你追踪的每一个奇怪的逻辑流程,每次你认为"这可以做得更好" - 记录它.
这是在没有实质性重写的情况下减慢并最终消除系统熵的唯一方法.
我知道的唯一方法是:
写测试
重构
运行测试
修复坏了什么
为新功能编写测试
介绍新功能
运行测试
修复坏了什么
你可以这样生活.
注意:有时候单位测试意大利面条代码真的很难:生成HTML的3Klines方法,与业务逻辑纠缠在一起的DAO,强耦合类......在这种情况下是一个带有自动重构的好IDE(能够提取方法,到开始)和一些像Selenium这样的测试工具可能非常方便.
充分利用两者.将项目组织成逻辑部分,最好使用反向工程UML类图,并查看互连的位置.任何松散连接的东西都是重构的理想选择.在任何停机时间,也要检查强连接,并查看哪些组可以完全拆分为具有最少更改的单独模块.弄清楚在重写整个事情之前,真正发生了什么.
京公网安备 11010802040832号 | 京ICP备19059560号-6 