我有几个编程工作。每个人有20-50名开发人员，项目持续3 - 5年。
每次都是一样的。有些程序员很聪明，有些程序员很平均。每个人都有自己的CS学位，每个人都阅读设计模式。意图是好的，人们正在努力编写好的代码，但几年后代码变成了意大利面条。模块A中的更改突然中断了模块B.除了编写模块的人之外，总有这些代码部分无人能理解。改变基础设施是不可能的，向后兼容性问题阻碍了良好的功能进入。有一半时间你只想从头开始重写所有内容。
比我更有经验的人将此视为正常。是吗？它必须是吗？我该怎么做才能避免这种情况，或者我应该接受它作为生活中的事实？
编辑：伙计们，我对这里的回复数量和质量印象深刻。这个网站及其社区摇滚！
答案 0 :(得分：30)
无情的勤奋与持续的单元测试相结合是防止意大利面条代码的唯一方法。即使这样，它也只是一种创可贴解决方案。一旦你不再注意了意大利面。
我经常发现意大利面条代码的介绍是因为当天有人只是懒惰。他们知道有更好的方法可以做到而且没有时间。当你发现这种情况时，只有一件事要做。
打电话给他们并要求他们改变
我发现在代码审查过程中指出更好的方法通常足以让人们前进。如果他们检查并且我感觉强烈，我会自己重构它。
我偶尔会有点古怪吗？我敢肯定。坦率地说，虽然我不介意。我不是一个混蛋，并以最好的社交方式处理这个问题。但是，让错误的代码得到检查几乎可以确保我将来必须在某个时候调试它。我现在宁愿采取一些措施并获得正确的代码。
我也觉得单元测试的文化也有助于防止意大利面条代码。单元测试意大利面代码是一个很好的代码。随着时间的推移，这迫使人们将代码保留在一定程度上。
答案 1 :(得分：14)
我认为避免代码腐烂的关键在于完善的自下而上的设计和实现方法（我相信它如此强烈以至于我命名我的业务 - 思考自下而上 - 之后！）。这里选择的工具是：
正如其他受访者所建议的那样，您需要及早发现问题。对于绿色开发人员来说，这意味着指导（结对编程很棒）和评论（代码和设计评论）。对于更高级的开发人员来说，这意味着警惕。
最重要的是，不要害怕重构。如果重构吓到你，你已经沉没了。如果重构被视为“糟糕”，那么您的业务就会出现问题。
当您修复某些内容时，请正确修复它。我使用术语“fux”来描述一个错误的修复方法：它只是“fux”你的代码库。
干杯，
丹
答案 2 :(得分：11)
20到50位开发人员可能是问题所在。这是非常高的，需要大量的管理和资源来控制一切。
我会考虑将项目分成更小的可重用段。摘要某些层远离核心系统。
答案 3 :(得分：10)
在代码的不同区域之间创建“防火墙”。您可以通过定义不同的代码区域或层，并定义每个层响应的单个API（在Java中，这通常通过接口完成）来实现。 API应该使用简单的接口或类，但它们“知道”这些层的内部结构。例如，gui不应该知道或关心如何存储数据，并且您的数据库不应该知道或关心数据如何呈现给最终用户。
这些API不必一蹴而就 - 只要您确保不污染防火墙，您就应该能够根据需要添加内容。
答案 4 :(得分：7)
代码审查，编码标准和公司政策。
以下内容适用于我们的商店 - 因为我不知道您的商店是什么类型，您的里程可能会有所不同。在迁移到Team Foundation Server时，我们关注的重点在于维护代码质量 - 或者至少有助于以任何可能的方式保持质量。我们正在添加的一些示例：
就像我说的，如果你使用的是另一个平台，也许可用的工具和你可以做的是不同的。但不要排除工具以任何可能的方式提供帮助。如果您可以使用它来改进，控制和审核您的工作流程以及在其中移动的项目，那么至少应该考虑它。
请记住，流程中的任何变化都会涉及回击。我们帮助减轻这种情况的方法是将策略构建到从旧版本控制/缺陷跟踪系统过渡的培训中。
答案 5 :(得分：7)
我认为重点在于你说
你只想从头开始重写所有内容
接受它。
尽可能多地使用单元测试，然后让重构成为一种常见的做法
自动化和单元测试将确保更改不会引入回归;投入一定比例的时间来重构旧代码（这意味着，更少的新功能！）确保现有的代码库不会老化，或者至少不会那么快。
答案 6 :(得分：3)
在至少两对眼睛看到它之前，不要允许代码提交。
答案 7 :(得分：3)
听起来很多人没有遵循封装和良好设计的一些基本原则。
在其他部分保持隔离和不可靠对于避免您描述的问题至关重要。您可能需要一些更高级别的设计师或架构师。这是一个典型的场景，人们已经证明了一些严苛的流程和变革管理。 （我不主张）
您需要避免依赖关系和相互关系，并仅定义和使用公共接口。这当然是过于简单化了，但您可能会通过代码的一些指标学到很多东西 - 类的复杂性，公共方法，通过逆向工程代码构建的UML图等等。
答案 8 :(得分：3)
我认为完全使用依赖注入可以获得的松耦合是一项技术特性，可以提供很多帮助。当你拆开应用程序的部分时，你不太可能因为“有趣”的重复使用而产生意大利面。
你可能会过度分裂，但这是另一个问题而不是全球结构问题。
答案 9 :(得分：2)
我认为这不正常。当它在那里存在几年时，真的很难对付它。
避免它的唯一方法是改变态度：
“敏捷开发人员对软件设计的态度与外科医生对无菌手术的态度相同。无菌程序使手术成为可能。没有它，感染的风险将太高而不能容忍。敏捷开发人员对他们的设计也有同感。甚至让最微小的腐烂开始的风险太高而不能容忍。“ 马丁罗伯特C. “C＃中的敏捷原则，模式和实践”
我强烈建议您阅读本书以获取建议。它列出了所有“设计气味”，它们存在的原因以及离开它们的后果。愿这可以帮助您说服您的管理层当前情况不合适。
祝你好运！答案 10 :(得分：2)
软件行业最大的问题是编程代码的质量被视为一个主观问题。没有一些定义明确的指标，只是整洁，并遵循惯例是不足以确保质量是可接受的。
有人试图改变this，但他们不太可能获得足够的兴趣或接受，这主要是因为程序员长期建立的文化正在努力远离任何类似工程的东西。编程的“纯艺术”理念意味着你的20-50名开发人员都会以自己独特的方式在代码中熠熠生辉，因此无论个人编码器有多好，团队的努力总和总是会成为“泥球”。
要避免这种情况，要么将所有编码器放在同一个“页面”上，将规范化代码作为约定的一部分，要么追逐工作，因为开发团队规模较小（1-3人）并且你很大奇卡。有一天，大型团队可能会找到一种方法来构建更好的东西，但是在那之前，如果他们能够接近10分中的6分，那么即使是最好的也是非常幸运的。我们构建低质量的软件，因为这就是我们设置的我们的行业要做......
保罗。
答案 11 :(得分：2)
<强> Refactoring
努力保持设计尽可能干净。这并不容易，但值得付出努力。
答案 12 :(得分：1)
持续重构。你有重构，特别是在设计层面。当您看到破损的代码或设计时，请准备好修复它。这通常是修复未破坏的东西本身。除了它......它只是没有表现出它的破碎......然而。
答案 13 :(得分：1)
否
：）
答案 14 :(得分：1)
跟踪系统各个部分的缺陷和性能将使您能够识别问题。随着系统的改变，设计不良或编写的功能或模块将具有更高的缺陷率。当识别出“问题”模块时，可以决定重写模块（而不是应用程序）。
答案 15 :(得分：1)
您必须密切关注软件开发实践。必须有代码审查和单元测试，以确保更新正在影响系统中的其他内容。 20-50个开发者很多，但可以做到。实现良好的流程是唯一可以在这种环境中拯救你的东西。强制编码标准也很关键。
答案 16 :(得分：1)
Shore and Warden's The Art of Agile Development是一本很好的书，其中有一节“将XP应用于现有项目”（第4章）。除非你努力奋斗，否则项目会随着时间的推移而变得更糟：克服这些技术债务是很困难的，并且会越来越难以发布可接受的版本唯一的解决方案是降低提供新功能的速度，并节省时间，提高测试覆盖率和重构能力。
通常，项目没有太多的测试覆盖率，并且没有运行10分钟自动脚本的选项，该脚本将非常彻底地构建和运用您的代码。相反，大多数代码都是结构化的，因此很难测试。最好的选择是尽可能地添加简单的测试覆盖，同时开始重构以使代码抽象化以便更容易测试。
虽然团队需要花时间改进代码以使其清洁和可测试，但您可能无法在“完成”清理所需的时间内停止交付。因此，您必须一步一步地执行此操作，同时添加新功能。没关系，首先选择最差的区域，并且不要马上获得明显的好处。坚持下去，因为最终你会到达那里。不要听那些说所有大型项目都不好的声音。
简而言之，每周花一点时间整理，并确保下周的代码比本周更好。
答案 17 :(得分：0)
开始创建单元测试，这将帮助您解耦代码并避免跟踪错误修复错误。它具有良好的覆盖率，它将使您更容易删除未使用的代码。
答案 18 :(得分：0)
更多代码审核以及代码所有权。
如果您只是破解了一些随机代码，那么您并不关心您“拥有”的代码。如果您有责任维护项目的一个模块，那么您希望大放异彩。
代码审核是您展示代码的时候。