我有几个编程工作.每个人有20-50名开发人员,项目持续3 - 5年.
每次都是一样的.有些程序员很聪明,有些程序员很平均.每个人都有自己的CS学位,每个人都阅读设计模式.意图是好的,人们正在努力编写好的代码,但几年后代码变成了意大利面条.模块A中的更改突然中断了模块B.除了编写模块的人之外,总有这些代码部分无人能理解.改变基础设施是不可能的,向后兼容性问题阻碍了良好的功能进入.有一半时间你只想从头开始重写所有内容.
比我更有经验的人将此视为正常.是吗？它必须是吗？我该怎么做才能避免这种情况,或者我应该接受它作为生活中的事实？
编辑:伙计们,我对这里的回复数量和质量印象深刻.这个网站及其社区摇滚!
无情的勤奋与持续的单元测试相结合是防止意大利面条代码的唯一方法.即使这样,它也只是一种创可贴解决方案.一旦你不再注意了意大利面.
我经常发现意大利面条代码被引入,因为那天有人只是懒惰.他们知道有更好的方法可以做到而且没有时间.当你看到这种情况时,只有一件事要做.
打电话给他们,让他们改变它
我发现在代码审查过程中指出更好的方法通常足以让人们前进.如果他们检查并且我感觉强烈,我会自己重构它.
我偶尔会有点古怪吗？我敢肯定.坦率地说,虽然我不介意.我不是一个混蛋,并以最好的社交方式处理这个问题.但是,让错误的代码得到检查几乎可以确保我将来必须在某个时候调试它.我现在宁愿采取一些措施并获得正确的代码.
我也觉得单元测试的文化也有助于防止意大利面条代码.单元测试意大利面代码是一个很好的代码.随着时间的推移,这迫使人们将代码保留在一定程度上.
我认为避免代码腐烂的关键在于完善的自下而上的设计和实现方法(我相信它如此强烈以至于我将自己的业务命名为"Think Bottom Up - after it!").这里选择的工具是:
合同编程
分层设计
专注于脱钩
始终以重用为目标,寻找通用解决方案
保持框架轻量,简单和专注
正如其他受访者所建议的那样,您需要尽早发现问题.对于绿色开发人员来说,这意味着指导(结对编程很棒)和评论(代码和设计评论).对于更多的高级开发人员来说,这意味着警惕.
最重要的是,不要害怕重构.如果重构吓到你,你已经沉没了.如果重构被视为"糟糕",那么您的业务就会出现问题.
当您修复某些内容时,请正确修复它.我使用术语"fux"来描述一个错误方法的修复:它只是"fux"你的代码库.
干杯,
担
20至50名开发人员可能是问题所在.这是非常高的,需要大量的管理和资源来控制一切.
我会考虑将项目分成更小的可重用段.摘要某些层远离核心系统.
在代码的不同区域之间创建"防火墙".您可以通过定义不同的代码区域或层,并定义每个层响应的单个API(在Java中,这通常通过接口完成)来实现.应该有API使用的简单接口或类,但它们"知道"这些层的内部结构.例如,gui不应该知道或关心如何存储数据,并且您的数据库不应该知道或关心数据如何呈现给最终用户.
这些API不必一蹴而就 - 只要您确保不污染防火墙,您就应该能够根据需要添加内容.
我认为重点是你说的时候
你只想从头开始重写所有内容
只是拥抱它.
使用尽可能多的单元测试,然后让重构成为一种常见的做法.
自动化和单元测试将确保更改不会引入回归; 投入一定比例的时间来重构旧代码(这意味着更少的新功能!)确保现有的代码库不会变老,或者至少不会那么快.
代码审查,编码标准和公司政策.
以下内容适用于我们的商店 - 因为我不知道您有哪种商店,您的里程可能会有所不同.在迁移到Team Foundation Server时,我们关注的重点在于维护代码质量 - 或者至少有助于以任何可能的方式保持质量.我们正在添加的一些示例:
代码审查工作流程 - 强制执行代码审查作为流程的一部分.包含一项策略,如果未检查代码,该策略将阻止签入发生.
TeamReview - 通过提供完整的"IDE内部"体验,减少代码评审的痛苦.
签入策略(一般情况下) - 许多很酷的好东西可用于控制代码流.确保在办理登机手续之前记录公共和受保护的方法,以确保在没有相应的工作项目的情况下无法检查任何工作.
就像我说的,如果你使用的是不同的平台,也许可用的工具和你可以做的是不同的.但不要排除工具以任何可能的方式提供帮助.如果您可以使用它来改进,控制和审核您的工作流程以及在其中移动的项目,那么至少应该考虑它.
请记住,任何过程中的变化都将涉及回击.我们帮助减轻这种情况的方法是将策略构建到从旧版本控制/缺陷跟踪系统过渡的培训中.
京公网安备 11010802040832号 | 京ICP备19059560号-6 