如何平衡代码质量与强大的开发人员个性

在工作中的代码审查中，我一直看到我认为“聪明”的代码和模式，尽管不一定会增加代码库的整体质量或可维护性。我在反馈中指出了这一点，并且对此反驳不服。这段代码在回购中并随后投入生产时，我有点担心。

我想保持一支团结一致的团队，所以我不想因过于保留我的意见而引起紧张。我也想为我们的客户创造一个很棒的产品，同时又不要太宽容。

传统上，谁对签入的内容和方式具有“否决权”？

如何在不踩踏脚趾的情况下将有效但又太复杂的代码删除？

我喜欢这句话：

“调试是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，那么就定义而言，您就不够聪明，无法对其进行调试。” – Brian W. Kernighan

一方面，这会使您对过于聪明的代码感到厌倦，因为以后很难调试和扩展代码。

另一方面，有效的聪明代码是学习的好方法。大概对整个团队来说。鼓励作者向他们的同事进行非正式的代码讨论会怎么样？只要确保它确实按预期工作并且在整个项目中确实有意义即可。您不想将其变成毫无意义的竞争！

如果您不认为它增加了价值，那么请提出以下挑战：“如何重构该部分（您已经进行了测试，对吗？），以便使其更具可读性？” 请务必指出，制作精巧易读的代码以制作难以穿透的块很难。

我的建议是扮演白痴，当它需要进行代码审查时可以随意说出您不知道它是如何工作的（如果您的自我需要按摩，您可以说您没有时间弄清楚它是怎么回事） ），并请开发者进行说明。完成后，您可以建议他将所有内容记下来，以备将来维护时使用，并暗示它太复杂了，无法被视为“好”代码。

如果它的好代码太复杂了，那么大多数人都会得到提示，而无需谈论代码质量或开发人员的专业知识。

PS。显然，大多数代码无论如何都是主观的，因此一个人不可能的聪明代码对于另一位开发人员而言可能是合理的，甚至可能是行业标准算法，因此您不能指责任何人直接编写错误的代码（除非明显地犯了错误）就像承包商将字节数组复制到stl列表中，然后将其传递给加密例程，然后将其转换回字节数组一样！）

我的经验法则是弯曲代码质量准则，以支持强大的开发人员个性。当我没有足够的时间深入挖掘时，我总是使用它-顺便说一句，这种挖掘通常很费力（请参见下文）。

此规则基于个人经验。我从狂热地遵循准则开始（可能是任何新手），并彻底地应对每一个偏差。随着时间的流逝，我已经掌握了足够的技能并学到了足够的技巧，可以相对轻松地赢得这场战斗-反过来，这又使我们可以更加专注于学习“胜利”的整体影响。据我所知，这种影响是负面的-“输掉这场比赛”的人正在遭受苦难，生产力下降了-而且，您知道他们的代码200％符合质量准则这一事实并不能弥补这一点。

这一发现使我放弃了大部分战斗，从而导致有更多的时间来分析有问题的案件。我发现，当我深入研究时，通常会发现背后有一个有趣的设计问题，一个微妙的（或不太微妙的）问题只是隐藏在个性争斗的背后。

• 就像我发现我发现31K源文件超出了建议的大小限制（即30K）一样。我的选择要么是花几分钟/几小时的时间来迫使文件所有者以某种方式挤出额外的千字节，要么花一两天的思考和挖掘来发现，例如，有一些库API可以代替全部使用该文件中的代码（以便可以将其删除）。

从最终用户的角度来看，这样的发现有时可能没有多大用处（尽管有时确实会产生深远的影响），但必须承认我在破解这种坚果时所获得的乐趣无论如何值得付出努力……锦上添花指南的偏差也不会消失。:)

您的组织应该有一个编码准​​则/标准文档，该文档会根据开发团队的意见定期更新。该文档可以说明细节，例如：如何命名变量，如何格式化代码等等。该文档还应说明组织期望程序员在编写代码时采用的价值观，包括可读性，可维护性，正确性，效率和遵守标准之类的相对重要性。

应使用该编码标准文件进行代码审查。如果编码标准规定，当两者发生冲突时，程序员应优先选择可读性而不是简洁性，那么在反对“聪明”的代码时您将获得一定的支持。如果标准没有这么说，而您认为应该这样做，那么您可以在编码标准会议上抽象地讨论它，而不用试图在有人的自我在线时弄清楚。

最终，有时确实要做出判断，在这种情况下，最终的决定权应归最终负责代码和/或产品的人员。通常是像高级开发人员，技术负责人，项目经理或工程总监这样的人。如果您是负责人，并且您认为某些代码无法充分维护，那么您就不必害怕这么说。您可以对此表示外交：

山姆，您的聪明才智给我留下了深刻的印象，但我担心这可能有点太聪明了。从现在开始，我需要您从一年开始从事新开发工作，而不要维护它，而且我担心必须维护它的人可能无法完全理解它的强大功能。我知道您讨厌这样做，但是如果您回到我们讨论过的简单实现方法，我将不胜感激。

另一方面，如果您不是负责人，那么您能做的最好的事情就是清楚地说明自己的位置，并说服团队中的其他成员。如果您没有得到经理的支持，请接受这不是您的电话，继续前进。

在您的位置（我有时是其中的一个），我不会删除它，而是亲自请机智/聪明的作者在评论中很好地记录下来，并在可能的情况下，就替代方案和他本可以使用的更简单的著作，包括示例。

我要强调一下这是最好的，因为即使他也可能不记得两个月后的时间里所有这些零碎的东西。

作为示例，一旦他被迫编写智能代码，他可能会放弃使用最简单的代码。

为什么会这样。

• 您承认自己在乎他的著作，
• 你通过问他表示尊重，
• 通过引用记忆/关注点问题，您设计并分解了一个场景，在该场景中必须更改该代码，而在他仍在为公司或团队工作时却无法

（如果没有最后的暗示，这种请求可能会作为公司方面的尝试而被接受，以使程序员商品化，使其可以随时与任何其他代码猴子互换）

以我的经验，通常很难从代码库中获得满足所有要求的代码。

但是，下次要维护该代码时，您可以轻松地提出将其替换为将来节省成本的措施，因为旧代码难以维护。

就否决权而言，管理层显然拥有这一权利。
有时他们是负责代码质量的团队或委员会，在这种情况下，他们也将拥有这种权力。

如果您举一个“聪明”模式的例子，这也将很有帮助。也许你只是反应过度...

在我的书中，“聪明”几乎从来都不是一件坏事，但是我可以同意，聪明与困惑之间可能会有一个滑坡。

像许多其他做法一样，我认为答案取决于它。

• 如果是缺陷，那么绝对需要修复。
• 如果代码有效，则必须在坚持更改代码的价值与明智代码的未来成本之间取得平衡。尽管在开发工作和维护工作之间的比率方面存在经验法则，但各个项目之间的差异会很大。合理一点
• 考虑一下您为什么不能说服团队伙伴需要简化代码？
• 您不必总是使一切都完美。这意味着代码将在无限循环中进行检查，而没有进行任何检查，因为没有什么是完美的（除了我的代码，哈哈）。
• 我个人更希望代码的作者拥有最终决定权。显然，如果他们持续做得很差，那么就必须采取其他措施，但是正如您所说，如果这是非常罕见的情况，那么强迫开发人员更改代码的负面价值可能会比通过修复代码所获得的收益要高。 。

我可以肯定地与这个问题有关。我目前是2个团队的技术负责人，我的工作是确保我们生成的代码尽可能易读和可维护。同时，我知道会产生一些“聪明”的代码，而且我知道我的大多数队友都很难遵循它。

我可以提供的一些意见：

1. 您的团队需要一位领导，如果有分歧，则将做出最终决定。在上一个版本中，我所在的团队没有领导力，这是残酷的。一切都变成了争论，如果您只有几个个性不强的人，他们两个都不愿让步。如果您确实有潜在客户，无论选择哪个决定，团队中的每个人都必须了解潜在客户所说的话。这就是管理层使他成为领导者的原因。

2. 让人们开心是非常重要的。因此，不要将整个团队推向您的观点，而只是将他们推向那里。解释SOLID原则，解释小型和内聚的类/方法/接口的重要性，并在每次看到它们被违反时（例如在代码审查中）重复这些操作。同时，不要让他们重写您不喜欢的每件事。归根结底，您需要在个人表达能力和遵循团队标准之间取得平衡。希望随着个人喜好向整个集团的运作方式转变，两者将融合在一起。

3. 我相信拥有干净，易于理解的类接口比没有任何“聪明”代码更为重要。例如，我们有一个类维护一个条目列表，这些条目通过3种不同的方式进行查找。当前，它仅对所有在较小范围内使用的查找使用线性搜索，但是由于此类的级别很低，因此我认为它的扩展性不是很好。我打算将其替换为使用Boost Intrusive容器的其他类。每个元素都支持同时放置在每个索引中，所有查找将在O（sqrt（N））中完成。是的，它的内部复杂得多，很多人不喜欢Boost，但在外部仍然保留3种方法：Add，Remove，Get。最重要的是，人们可以（出于某种原因）编写所需的任何代码，

4. 保持代码所有权的想法。尽管有时很难实现，因为不同的人可能需要添加/修改一些代码。编写代码时，原始开发人员是该代码的最终所有者。这并不意味着没有人可以触摸它。如果其他人修改了他们的代码，那很好，但是到了最后，原始开发人员将对其进行审查，并对其中的内容负责。无论该代码是简单还是巧妙，都是他的宝贝。如果/如您所预料的那样，错误是由于做出的设计/编码决定而开始堆积的，而不是简单地修正这些错误，请与该开发人员坐下来（由btw修复所有这些错误）并思考这些决定，看看如何做出不同的决定。

我花了很多年领导和管理开发团队。从本质上来说，我在代码方面有点强迫症，而且非常黑白。我已经从经验中学到，在团队领导中进行战斗是最难学的技能之一。是的，标准很重要。是的，可读性和可维护性非常重要。是的，我们都应该努力编写统一的，符合标准的代码。尽管开发人员是人类，但不是代码生成工具。我们有个性，意见，我们感到无聊，我们想学习新事物。

在工作中的代码审查中，我一直看到我认为“聪明”的代码和模式，尽管不一定会增加代码库的整体质量或可维护性。

好...所以他们没有添加，但是它们会分散注意力吗？我们是在谈论编码风格中的个人喜好问题，还是完全不需要编写代码（例如，使用表达式树和反射只是因为使用表达式树和反射很有趣）？如果是前者，那就放手吧。成为开发人员的乐趣之一就是提出解决问题的创造性解决方案。也许（而且我们大多数人都不愿意承认这一点），我们有时会被我们不了解的方法所吓倒，或者不想问或没有额外的精力来学习新方法。

现在，当创造力导致不必要的代码和完全不合理的复杂性时，一定要大声疾呼，并为您辩护。成为团队合作者很重要，但（和让他人）负责也是如此。代码审查不仅与质量保证和学习有关，还与责任制有关。您将脚踩一些脚趾，但是如果您有一个强烈的争论，为什么要花费精力（金钱）来重写工作代码，而在这一过程中应该挫伤自我，并且您想冒风险挤压某人对其工艺的热情，那么您就不应回避将其放在桌子上。如果您是团队负责人，那么这就是您的工作。注意影响，并做到这一点。如果您不是团队负责人且没有权限，则将其交给团队来决定。

在团队中灌输责任心的最佳方法是鼓励他人追究您的责任。如果您保持开放的态度，并在人们建议改进代码时不让他们失望，那么您可能会发现他们更愿意接受您的建议。

从个人经验来看，当发生这种情况时，我会请求允许成为一名自愿对抗性单元测试员来编写测试，以拷打陌生的实现。

我将尽力真正理解代码的工作原理，并尝试以许多不同的方式进行探讨。

请注意，这是一个时间承诺。可能是几个小时或几十个小时，甚至一周的大部分时间。是否合理取决于代码的复杂度是否与需求的复杂度相称。

如果我没有胜任，即说代码在许多测试中都能幸存，我将使自己相信，实现的确比我真正的启发，我将支持将其包含在主要产品中。

根据源控制方法的不同，在开始此测试阶段之前，可能必须将代码临时提交到源控制系统（可能在分支中）。

我的回答因我使用OpenCV的经历而被打乱。有些算法比任何程序员都可以自己实现更复杂。甚至没有博士学位-也许是博士学位的前百分之几。如果代码是那么好，即使您没有量化信任程度的有效方法，也必须相信这样做，违背自己的直觉和偏见。