在紧迫的期限内清理别人的代码有多重要？[关闭]

（我说的是HTML / CSS代码（不是编程语言），但我认为我们也面临与程序员相同的问题。）

我是团队中的高级前端设计师，而且我经常不得不在紧迫的期限内重新处理初级人员的输出。

我面临两个问题：

1. 他们的编码风格有点混乱。
2. 美学不好。

我发现，它们的编码风格是混合的，没有适当的约定/标准。在清理代码或只是处理他们的代码（甚至复制他们的工作方式）之间，我感到很痛苦。

我确实觉得遵循他们的编码风格感到沮丧，因为我觉得我可能会学到坏习惯。但是，那是完成截止日期的最快方法。

对于那些有更多经验的人，哪个更有效？我应该保存清理以备后用吗？还是在进行更改时进行清理？

（尽管我不想听起来很自大，但这是现实。要花更多的时间来编写更好的代码。我知道，我刚开始写的是凌乱的代码。）

我相信您以错误的方式看待问题-您缺少了一个向初中生教授如何编写更好的代码的机会。

如果习惯性地重新编写他们的代码，您可能会给大三级学生一种印象，即您不重视他们的工作，这会降低他们的士气，并且在下次没有帮助他们更好地编写代码。

我认为，更好的方法是将代码审查任务添加到您的团队的开发过程中。它不必涉及每个已提交的代码，也不必（我认为应该不这样做）仅由您执行-每当您的团队成员完成足够大的任务时，他都应该与一个（或多个）队友配对，向他们解释代码，并收到有关他的设计，编码风格，可能的错误和安全性问题等的建设性意见和批评。

如果您是代码审查小组成员，那么他们将比您简单地重写他们的代码（他们有机会听到应该更改代码的原因）所学的知识要多得多，并且可以减少犯规。

给他们机会也可以进行代码审查将进一步提高他们的能力-了解其他人如何编写代码以及为什么这样做-并提高他们的自尊心。

如果你给他们一个机会，审查他们也会学到很多东西你的代码。您可能也会学到一些东西-因此不要只是为了表演而已！

我之前已经说过这一点，并且会再说一遍“工作代码比漂亮代码更有价值”。

如果更改代码，则很有可能会更改其行为，如果这是经过测试的代码，则说明您已经使所有测试工作无效，并且需要重复测试。

一定要鼓励您的初级人员编写清晰易懂的代码，但是如果您要重写他们编写的所有内容，那么您的雇主钱会浪费数倍。他们必须为您的初级员工付款，然后为您支付他们已经付给您初级员工的费用，然后再为您付款以完成他们实际雇用您的工作。

• 最简洁的答案是不。在艰难的时刻，有时您只需要低下头，拿起美学的子弹。;）

• 更为实用的答案是对它进行时间限制。安排一个小时的预算，以完成并清理代码的一个特定方面。然后签入并做一些实际工作。但是，请诚实对待自己，使其不受约束。

• 但是，有时进行一些清理会使工作进行得更快。甚至一些快速的搜索和替换类型更改都使所有内容都更易于访问。

• 警惕时尚大战。尤其是在时间紧迫的情况下，如果您要撤消其他程序员将要重做的一些样式偏好，那么最好还是等到有时间真正解决这些问题时再这样做合作的文体问题。（这意味着有些让步。）

但是答案中有一个判断价值。我会说“中等”重要。干净的代码确实可以使工作更快，并且毕竟代码质量是可交付成果的一部分。我认为我不花一些时间进行清理就无法接触代码（甚至是我自己的代码）。但是，请确保对样式和格式的烦恼以及样式大战的重要性不比将代码投入生产更为重要。

在修改代码并有期限时，通常使用两个规则：

代码很糟糕，但是有可能在合理的时间内找到问题并修复

我解决了一个问题，其余的都完好无损。

代码是如此混乱，以至于很难在其中找到问题。解决问题会立即破坏其他事物。从头开始编写该代码可能比修复它更快。

然后我别无选择，只能重写/重构，直到代码干净到足以本地化并修复错误为止。

该界线的情况是：

该代码是混乱的，真的很糟糕。仍然可以在合理的时间内修复错误，但是代码结构将使其很难维护。任何新功能很可能会引入新的错误或导致性能显着下降。

在那种情况下，代码将是固定的，但是只有在要实现新功能时，才在空闲时间内打开，决不要在截止日期前进行错误修复！

我想知道您在过程中的什么时候发现此问题？

严格来说，在这个我们都不曾居住的神奇理想世界中，所有被提升或部署的代码都应该是完美的。有时候您不一定要务实。

但是，如果您有代码检查过程，则应在测试之前突出显示此过程。如果您一直都在按时完成任务，那么对交付的估计是否就意味着存在问题，即意味着任何开发过程的关键组成部分（即代码审查）都被勒死了？

如果您不花时间使他们成为开发过程中学习的一部分，那么您的初中生就永远不会学会坐下来吸收更好的做事方式。在我看来，您没有这样做。

取决于整体文化。如果最后期限很短，请接受，以后您必须进行清理。如果它们是恒定的，则说明您在结构上正在累积技术债务，您应该处理管理方面的问题。如果他们不能解决您的问题，最好开始寻找其他工作机会，因为公司文化很可能很快会符合达尔文主义原则。

为了帮助将来解决该问题，请制定一份内部《编码标准和惯例》文档，所有员工都必须遵守。

对于当前批次，在重构代码时（但仅在重构时）根据S＆P文档清理代码。

我对编程没有经验。但是，作为一名学生，我经常致力于同行评审和项目合作。如果有足够的时间来完成一个项目，我将继续整理团队成员的代码，以使其更加清晰易读。很多时候，我发现很难在前100行左右进行筛选。在这些情况下，我非常乐意伸出援助之手，帮助教给其他程序员更好的习惯和编码。如果没有足够的时间，我只需复制/粘贴，然后将我的项目放到全局中处理它们不良的界面。之后，我一定会在编码技术方面提供大量建议。对于同行评审，建设性的批评（无论多么不受欢迎）从长远来看只会使他/她和我自己都受益。

总体而言，如果您有时间可以抽出时间，可以教会新手如何进行工作，使每个人都受益。花一点时间，教给他们哪些对您有用，哪些无用。如果您没有时间，请暂时停止他们的工作，并确保在有机会时尽快与他们联系。让他们知道有更好的做事方法，尤其是如果将来与他们合作时。

总体质量的提高远胜于将一个人作为更大群体的“过滤器”。在该说明上：

• 结对编程的工作原理类似于代码复习版，用于理解如何进行开发-就像阅读与执行，讲述与展示之间的区别。观察代码的演变并快速讨论更改，不仅有助于理解重构的原因，而且对于理解重构和良好代码的原因非常有帮助。以我的经验，它比单独开发要快，因为想法会不断地被折腾，最终会获得更高的总体质量，并更好地理解代码和其他人的想法。
• 整理工具可以验证是否遵循了编码样式。这教会了每个人如何格式化代码，一旦开发人员记住了标准，错误就会迅速减少。
  • 将这些作为构建过程的一部分，以确保在提交之前已将其修复。
  • 使用语言模板来确保可以分别检查CSS，HTML，JavaScript和服务器端代码。
• 验证工具可以检查生成的输出是否正常。这些也应该是构建过程的一部分。

最佳实践是获得编码样式指南，并进行定期审核，以使在临近截止日期时，您不会遇到此问题。

我的建议是让您发挥领导作用，并带头进行定期代码审查。管理人员并不会为了确保进行常规代码审查而自上而下，但是我的经验是，当程序员加紧安排并进行常规代码审查时，他们会留下深刻的印象。

对您的员工有很多好处，他们将：

• 学习更好的风格
• 遵循更好的做法
• 学习研究他们在做什么

为自己带来一些好处，您将：

• 在最后一刻的调试中会更有效率（这将始终发生）
• 您的团队和管理层都公认专家和领导者

我可以在“不解决问题的方法”和“不要浪费时间解决对客户不重要的问题”中看到原因。项目经理担心风险，这很好。

我也理解大多数人对这种修复方法不太满意。我也明白

话虽如此，我相信大多数截止日期都是人为的。实际系统的使用寿命超过了最后期限，而您今天所做的错误设计将永远打击您。在解决正在生产中运行的代码中的一些错误决策之后，人们花了几个月的时间交付并花费了数年。

科技债务就是这个词。它有一天会回来，有人会为此付费。

因此，海事组织，我认为您是对已损坏的设计进行正确的修复，而且要专业（特别是针对初级人员）还意味着您必须知道如何接受批评并从中学习，即使它不礼貌。实际上，生活中的大部分时间都不是礼貌的。

任何直接的答案都是极端的。显然，在某些情况下，截止日期太紧，您必须使用丑陋的代码；在某些情况下，代码太丑陋，值得错过改进它的截止日期。您需要的是判断您所处状态的方法，以及可能设定现实期限的方法，以便有时间编写更好的代码。

不要保存清理以备后用。除非您习惯性地有除重构之外别无其他事情的时期，否则没有“后”的理由来整理代码比现在要具有更高的优先级。常规是“红色，绿色，重构”，而不是“红色，绿色，在两个星期内做完全不同的事情，重构”。实际上，您不会更改代码，直到下次由于其他原因再次访问它时，您也可能会处于截止日期。您真正的选择是立即修复或保留它。

当然，假设您计划再次阅读，则样式良好的代码比样式不良的代码更好。如果您打算不再阅读它，那就不要整理它。运送通过测试的第一件事。但这是一种非常罕见的情况，对于大多数程序员而言，它几乎永远不会发生。忽略这种情况，只有您拥有实际案例的详细信息，才能判断修复的成本与不修复的成本（在将来的维护中增加）。

在某些需要维护代码的地方，有些事情要比现在更难解决。这些实际上并没有给您带来什么好处，现在就修复它。最明显的是不容易解决的（空白错误等），因此很难想象您有时间问这个问题而不要解决它们；-)对于那些不重要但属于此类的问题，可以，您的代码有些不理想，但必须务实。它可以正常工作，而且您必须按时完成。用它。

某些事情现在比以后在以下情况下更容易修复：（a）在每个人的脑海中它们都不那么新鲜；（b）编写了其他依赖或模仿它们的东西。这些现在更有价值，因此请优先处理。如果您没有足够的时间来解决这些问题，那么您就需要尽力争取更长的期限，因为您在代码库中积累了债务，下次访问时可能需要偿还债务代码。

固定代码的首选方法是通过审核过程。评论您所遇到的问题，然后将其发送给初中生以进行更改。您可能会举例说明您的意思，而让初级人员在适用于它们的代码中查找所有案例，但不仅要为它们完成代码。如果这样做，您将无济于事。

您应该将常见问题写到样式指南中，指出“不要这样做，而要这样做”，并说明原因。最终，原因是“为了使我们的代码在美学上保持一致”，但是，如果您不准备以合理的理由写下规则，那么您也可能不应该执行它们。只需让每个程序员自由选择。

最后，请注意会无限期调整内容的趋势。收益递减，您需要通过经验学习，在这些经验仍然不错的地方。形成一个足够好的东西的现实想法是绝对必要的，否则您将无法进行谈判，以确保截止日期给您时间来创建“足够好的”代码。把时间花在不够好的事情上。

正如许多人以前所说的，无论扔到空中的任何东西都会永远退缩。我相信整个代码库都具有高度的一致性。当然，某些事情实际上并没有那么重要。例如，过程中局部变量的命名约定。但是，对于任何结构性的部件，应在最终合并到主干中之前立即将其固定。当您查看单个过程或类时，它可能只是有点伪劣，但是如果每个人都提交“稍微难看”的代码，那么从整体上来说，它真的很快变得非常丑陋。

丑陋的代码通常可以在90％的时间内正常工作，但在边缘却会崩溃。通常只需遵循一些简单的规则，就可以确保它不够简单。首先，对于每个程序员来说，必须强制性地定义和记录其产生的每个过程或功能块的确切约束。

其次，对于每个程序，都应针对这些约束条件进行测试。这应该是程序员在提交之前可以（必须）针对其过程在本地运行的简单单元测试。显然，使用适当的测试套件可以更轻松地进行管理，但是即使没有测试，也应该编写测试，并且可能将其提交到可以从构建中排除的局部类中。

第三，具有预配置工具的一套标准化开发环境非常宝贵。TS服务器对此非常棒。每个人都有相同的确切工具（和版本），相同的配置和相同的更新。安装预配置为您的标准的诸如CodeRush或Resharper之类的重构工具，并指示程序员您将拒绝仍然有警告的所有提交。现在，您可以使用团队的代码审查时间来实际改善他们的规则集，从他们的反馈中，您的团队可以愉快地更正自己，而不必在事后不断进行清理。对于程序员来说，从标准正确配置的工具中进行代码批判比从同事或老板那里进行代码批判要容易得多，在同事或老板那里，标准似乎是任意定义的，或者没有被正确理解。如果IDE告诉您您的代码伪劣，没有人会反对它，它将得到纠正。您会发现代码质量将大大提高，整个团队将在几周后花费更少的时间进行重构和清理。程序员也将习惯于规则并停止编写废话代码。

最后，这里的简单解决方法只是给程序员一种改进的动力。根据定义，程序员是有竞争力的。每个人都希望拥有最好的或最快的代码。激励每个人，提高生产力并消除无能的一种好方法是为每个人每周计算一个加权计分板，例如为拒绝的提交和过期的截止日期计分。在每周的团队会议上展示前N名，或者甚至向与本月平均排名第一的人共进午餐。

我建议使用审查工具。如果您有基于Git的存储库，则可以使用Gerrit审查工具。在几次拒绝提交后，团队将学习您要遵循的标准，以后的提交将不需要您进行任何其他工作。

提交将等待您的接受。如果您看到任何应重写的行，则可以编写注释，而您的队友可以根据您的要求自行修复代码。这确实是学习团队成员编码标准的好方法。