有没有办法避免多年来的意大利面代码？
我有几个编程工作。 每个人有20-50个开发者，项目持续3 – 5年。
每一次都是一样的 一些程序员是光明的，有些是平均的。 每个人都有自己的CS学位，每个人都读devise模式。 意图是好的，人们正在努力编写好的代码，但在几年后，代码变成意大利面。 模块A中的变化突然中断了模块B.除了写它的人之外，总是有这些代码部分是人们无法理解的。 改变基础设施是不可能的，向后兼容性问题阻碍了良好function的进入。一半时间你只是想从头开始重写所有的东西。
比我更有经验的人把这视为正常。 是吗？ 它必须是？ 我可以做些什么来避免这种情况，或者我应该接受它作为生活的事实？
编辑：伙计们，我对这里的回应的数量和质量印象深刻。 这个网站和它的社区摇滚！
无情的努力和不断的unit testing是防止意大利面代码的唯一方法。 即使这样，它也只是一个创可贴的解决scheme。 一旦你停止注意出来的意大利面。
很多时候，我发现意大利面条代码被引入，因为那天有人只是懒惰。 他们知道有一个更好的办法，只是没有时间。 当你看到发生的时候，只有一件事情要做。
打电话给他们，让他们改变它
我发现在代码审查中指出更好的方法通常足以让人们去。 如果他们检查，我感觉强烈，我会自己重构。
偶尔有点偏心吗？ 我确定我是。 坦率地说，虽然我不介意。 我不是一个混蛋，以最好的社交方式来解决这个问题。 不过，让错误的代码检查几乎可以确保我将来必须在某个时刻进行debugging。 我宁愿现在采取一点小小的挑战，并得到正确的代码。
我也觉得unit testing的文化也有助于防止意大利面代码。 unit testing代码良好的意大利面代码是非常困难的。 随着时间的推移，这迫使人们保持他们的代码有点因素。
我相信避免代码腐烂的关键在于自下而上的devise和实现方法（我相信这是非常强烈的，我命名我的业务 – 想想自己的事情 – 之后！）。 这里select的工具是：
- 按合同编程
- 分层devise
- 注重脱钩
- 始终以重用为目标，寻找通用的解决scheme
- 保持框架轻量级，简单和专注
正如其他受访者所build议的，您需要尽早发现问题。 对于绿色开发者来说，这意味着指导（配对编程在这里很好）和评论（代码和devise评论）。 随着更多的高级开发人员，这意味着警惕。
最重要的是，不要害怕重构。 如果重构吓到你，你已经沉没了。 如果重构被认为是“不好的”，那么你的业务就有问题了。
当你修复某些东西时，请正确修复它。 我使用术语“fux”来描述一个修正方法是错误的：它只是“fux”你的代码库。
干杯，
担
20到50个开发者可能是这个问题。 这是相当高的，将需要大量的pipe理和资源，以保持一切检查。
我会考虑把这个项目分成更小的可重用部分。 抽象出远离核心系统的某些层。
在代码的不同区域之间创build“防火墙”。 您可以通过定义不同的代码区域或层次来实现这一点，并定义每个层响应的单个API（在Java中，这通常是通过一个接口完成的）。 应该有API使用的简单的接口或类，但是对这些层的内部没有“了解”。 例如，gui不应该知道或关心你如何存储数据，你的数据库不应该知道或关心数据是如何呈现给最终用户的。
这些API不必一成不变 – 只要确保不会污染防火墙，就可以根据需要添加内容。
我认为重点是当你说
你只是想从头开始重写所有的东西
只是拥抱它。
使用尽可能多的unit testing，然后让重构成为一种常见的做法 。
自动化和unit testing将确保更改不会引入回归; 把一定比例的时间用于重构旧代码（这意味着新functionless一些 ），确保现有代码库不会变老，或者至less不会太快。
代码评论，编码标准和公司政策。
以下是适用于我们的商店 – 因为我不知道你有什么样的商店，你的里程可能会有所不同。 在转移到Team Foundation Server的过程中，我们很大一部分工作重点是维护代码质量 – 或者至less帮助以任何可能的方式保持质量。 我们添加的一些例子：
- 代码审查工作stream程 – 强制代码审查作为stream程的一部分。 包含一个策略，可以防止代码未被审查时发生签入。
- TeamReview – 通过提供完整的“IDE内部”体验，使代码评论更加轻松。
- 签入政策（一般情况下） – 许多很酷的好东西可用于控制代码stream。 诸如确保公共和受保护的方法在登记之前被logging下来，以确保没有相应的工作项目就不能检查工作。
就像我说的，如果你使用的是不同的平台，也许可用的工具，你可以做的是不同的。 但是，不要排除工具，以任何可能的方式提供帮助。 如果您可以使用它来改进，控制和审核您的工作stream程以及其中的项目，那至less应该值得考虑。
请记住，stream程中的任何更改都将涉及推回。 我们帮助缓解这个问题的方法是将策略build立在从旧版本控制/缺陷跟踪系统转换到培训上。
听起来很多人并没有遵循封装和良好devise的基本原则。
为了避免你所描述的问题，保持事物与其他部分的隔离和不可靠性是非常重要的。 你可能需要一些更高层次的devise师或build筑师。 这是一个典型的情况，人们已经certificate一些严厉的程序和改变pipe理。 （我不主张）
您需要避免依赖关系和相互关系，只能定义和使用公共接口。 这当然是过于简单化了，但是您可能会通过一些关于代码的指标学到很多东西 – 类的复杂性，公共方法，通过逆向工程构build的UML图等等。
我认为通过全面使用dependency injection可以获得的松耦合是一个技术特性，可以帮助很多。 当你分开应用程序的片断，你不太可能得到“有趣”重用的意大利面条。
你可能会过度分散，但这是另一个问题，而不是全球结构性问题。
至less有两双眼睛看到它之前，不要让代码被提交。
重构
努力保持devise尽可能干净。 这并不容易，但是这是值得的。
我不认为这是正常的。 当它在那里呆了几年，真的很难打。
唯一的办法就是改变态度：
“敏捷开发者对软件devise的态度与外科医生对无菌程序的态度相同。 无菌手术是使手术成为可能 。 没有它，感染的风险将会太高而无法容忍。 敏捷开发人员对他们的devise也有同样的感受。 即使是最微小的腐烂开始的风险，也是无法容忍的。“Martin C. Robert”C＃中的敏捷原则，模式和实践“
我强烈build议看看这本书的意见。 它将所有的“devise气味”，它们存在的原因以及离开它们的后果命名。 愿这能帮助你说服你的pipe理层，目前的情况是不恰当的。
祝你好运！
没有
🙂
软件行业最大的问题是编程代码的质量被视为一个主观的问题。 没有一些明确的指标，只是简洁而整齐，遵循惯例是不够的，以确保质量是可以接受的。
有人试图改变这种情况 ，但是他们不可能获得足够的兴趣或接受，主要是因为程序员长期以来build立的文化正在努力远离类似工程的任何东西。 “纯粹的艺术”编程哲学意味着你的20-50的开发者都将以自己独特的方式打破代码的束缚，所以不pipe个人编码者有多好，总的努力总是要是“一大块泥土”。
为了避免这种情况，要么让所有的编码器在同一个'页面'，使规范化的代码作为你的约定的一部分，或者在开发团队较小（1-3人）的工作之后追逐，而你是那个大个子。 总有一天，大型团队可能会find更好的方法，但是在那之前，即使是最好的团队，如果能够接近6个，我们也是非常幸运的。我们构build的是低质量的软件，因为我们已经build立了这个软件我们这个行业要做…
保罗。
您必须密切关注软件开发实践。 必须有代码审查和unit testing，通常会确保更新影响系统中的其他内容。 20 – 50个开发者很多，但是可以做到。 实施良好的stream程是唯一能够帮助您节省开支的环境。 强制编码标准也是关键。
跟踪系统各个部分的缺陷和性能将使您发现问题。 由于系统改变devise不当或书面function或模块将有较高的缺陷率。 当“问题”模块被识别时，可以决定重写模块（不是应用程序）。
持续重构。 你必须重构，特别是在devise层面。 当你看到破码或devise，准备解决它。 这通常是修复本身没有被破坏的东西的情况。 除了这是…它只是没有performance出它的破碎…然而。
Shore and Warden's 敏捷开发的艺术是一本很好的书，其中有一章“在现有项目中应用XP”（第四章）。 随着时间的推移，项目会越来越糟糕，除非您努力奋斗：克服这种技术债务是困难的，并会使得发布可接受的版本越来越困难。 唯一的解决scheme是降低提供新function的速度，节省时间，提高testing覆盖率和重构。
通常情况下，项目没有太多的testing覆盖，没有运行10分钟自动化脚本的选项，可以非常全面地构build和运行代码。 相反，大多数代码的结构是很难testing的。 那么最好的select就是在可以的地方添加简单的testing覆盖，同时开始重新构build抽象的代码，以便testing。
虽然团队需要花时间改进代码，使其清洁和可testing，但您可能无法停止交付“完成”清理的时间。 所以，你必须一步一步做，而且还要增加新的function。 没关系，首先挑选最差的地方，不要期望马上有明显的好处。 坚持下去，因为最终你会到达那里。 不要听那些说大项目不好的声音。
总之，每周花一点时间整理一下，确保下周的代码比本周更好。
更多的代码评论，也许代码所有权。
如果你只是破解了一些随机代码，那么你并不关心你自己的代码。 如果您有责任维护项目的一个模块，那么您希望发光。
代码评论是您展示代码的时候。
开始创buildunit testing，这将帮助您解耦您的代码，并避免错误修复后续错误。 它具有良好的覆盖范围，这将使您更容易地删除未使用的代码。
