大多数程序员文化都是建立在完美代码的理想基础上的：代码，不仅是可工作的，还是干净和优雅的。我们自豪于构建巧妙办法来解决疑难的问题。但是，这种完美主义可能会不利于团队的成功，因为完美主义往往会导致个人的分歧。

在全球范围内没有公认什么才是完美的理想的代码。每个人都对代码有一个不同的审美，我们每个人对此都有自己的想法。如果我们都是完美主义者，欲望会驱使着我们让代码看起来是我们所希望的那样，那么我们最终会与我们的队友陷入分歧。我们将会彼此互相抗争让代码变成我们各自想要的样子。

作为一个经验丰富的程序员，我发现避免团队冲突的一个有效的办法是停止对完美代码的关注。下面是一些例子，讲述如何将这个概念应用到你自己的工作中。

不要被教条束缚

对代码的唯一的要求就是它的运行。一个简单的验证就是，如果它能完全的测试覆盖，那么这些测试就是通过的。除了这一点，每一种质量上的测量都是主观的。

当你阅读别人的代码时，尽量不要去想你喜欢的代码是什么样子的。尽量不要在你的脑海中进行重写。就让它以它的方式存在。

精简你的编码标准短或完全抛弃标准

制表符还是空格？两个空格还是四个空格？同一行还是新的行要大括号？我不知道一个单一的编程语言，是不受这种类型的辩论的。打击这一标准的方法是使用书面编码标准。这给我们的代码带来一致性。

不幸的是，它很难形成完整的编码标准。总是会有灰色地带，导致潜在的分歧。命名，模式，对象建模技术，等等。

定下的规则有时会让我们作茧自缚。

在我曾经工作过的一个团队中，它的编码标准中有以下规则：“任何函数都不应该超过7行代码”，在事后看来，如果没有这个规则，我们的团队会变得更好。尽管我仍然同意这种观点，这一规则引起了很多混乱和争议。这一条规则引起了大量的请求修改的评论，人们需要不断的提醒，一些团队队从来没有相信它。总的来说，我们花了大量的时间和精力维护这一规则。

那时候可能是更多的是请求配对并一起改善代码。维护每一个规则都要有一个代价，并且你可能对这些规则仍然有分歧。

虽然我还有写短的方法，通常不超过七行。让代码有自己的标准，而不是写出规则来。不要让硬性要求束缚自己。

通常，即使有明显的改进，我也会合并请求作出代码。我这样做有两个原因。第一个是等待修正可以阻止其他团队成员。第二个是更微妙的。重要的是，一个代码库应该始终保持可延展性：有意义，准备和期待改变。“完美的代码请求”阻碍了这一点。它促进了在主分支代码是“黄金”的概念，应该不再改变。如果我们允许不完美的代码转化为主，我们鼓励更高的变化率。团队里将总是问这个问题“我看的代码是干净的吗？“

这有点反直观，以不完美的代码为主实际上可以使提高质量。

因此，有什么更好的方法来审查需求呢？

我的策略是，首先了解整组变化，记下任何可能很重要的东西。然后我会优先考虑我的反馈意见，并限制我的意见为至多三个。剩下的一切都是单独留下的。

 我最不可能评论的问题就是，像错位的空白或不缩进参数列表的风格问题。如果代码是可锻造的，有人很可能在未来的一些时间来清理代码。同时，这些风格的问题不会伤害任何人。

扩大视野

对于任何超过几十行代码，完美都是在旁观者的眼睛里的。如果你希望每个人都以同样的方式解决问题，那么你就错了。如果你对所写的代码应该是什么样的有个美好的愿景，那么你会失望的。

给你的队友空间来设计他们觉得合适的代码。鼓励每个人在设计中都是平等的。  

当你的队友写的代码看起来不同于你想要的东西时，不要和他们争论。记住，在你的团队中长期保持健康的工作关系是有价值的。因此，也许牺牲你的个人视野是可以的。

我劝你每天多花一些时间来反思你的开发技术。想想如何更有效的为自己和为团队服务。这个月的工作可能下个月不会再做了。这是从新手到专家特别真实的团队成长技能，所以，一定要不断寻找你的过程中一开始伤害比他们帮助更多的部分。

【英文原文：https://8thlight.com/blog/daniel-irvine/2016/11/11/perfect-code-is-an-illusion.html】

{测试窝原创译文，译者：亚然}

译者简介：亚然，软件测试爱好者，长期从事软件测试工作