完美主义者最大的特点就是过度追求一件事情的完美，他们看什么东西都不会完全满意，因此经常陷入深深的矛盾之中，殊不知这个世界上根本就没有绝对的完美，将精力投注到工作中、生活中各个方面，努力改善，乐此不疲。至于吗？程序员中的完美主义者又会怎样呢？
许多程序员文化是建立在完美代码的理想上：代码不仅能够运行，而且也必定是干净、优雅的。我们以巧妙地构建解决难题的对策为傲。然而这种完美主义可能不利于团队的成功，因为完美主义常常导致个人分歧。
然而能得到所有人公认的完美代码标准并不存在。对于完美代码，每个人都有一个略微不同的审美观点，这意味着我们每个人都有自己的想法：什么样的代码看起来完美。如果我们都是由完美主义来驱动——希望我们的代码看起来像我们想要的样子，那么我们最终会与队友发生分歧，因为我们每个人互相反对，只是为了让代码库看起来像我们所想看到的样子。
伦敦一位资深程序员Daniel Irvine就在博客分享了他对完美代码的看法以及对策。
当我成长为一个程序员时，我发现有一些小技巧，可以让团队避免因为追求完美代码而发生冲突。下面就让我们来看一看。
对代码库的唯一要求就是，它是可用的。通过一个简单的方法来验证，如果它经过完全覆盖测试并通过，就可以证明是可用的。除此之外，每个测量都是主观的。
当你阅读其他人的代码，不要去想如果是你写的话会怎样。不要试图在你脑海中重写这段代码，让它存在就是它的方式。
用制表定位键（Tab）还是空格键（Space）？两个还是四个空格？为你的左括号设置同一行呢，还是另起一行呢？我不知道如果只有一个单一的编程语言的话，是不是就不会有这种争论？解决这个问题的标准方法就是使用书面编码标准，这会为团队的代码带来一致性。
不幸的是，很难形成完整的编码标准。总是会有灰色区域导致了潜在的分歧，如命名、模式、对象建模技术等。
而且，他们团队定下的规则有时会引火烧身。
我曾经所在的团队，对编码标准有过如下规则：“任何函数不得超过7行代码”。事后看来，这个规则，还不如没有。虽然我仍然赞同这个观点，但这一规则还是激起了很多混乱和争辩。团队成员在编码的时候不能全心投入，因为需要总是想着这个规则。还有人则走向另一个极端，永远拒绝接受它。总之，我们团队花了大量时间和精力，来保持遵守这个规则。
试想，那些时间如果用来结对编程或是一起改进代码该有多好。所有的规则都有一定的代价，并且，尽管规定事无巨细，团队成员们仍然可能在其它事情上存在分歧。
虽然我仍然尽量保持编写简短的函数和方法——通常少于七行——但我不会让它们成为必须遵守的规则。
让代码库成为自己的标准，而不是写出什么规则。
我通常会迅速合并Pull Request（略：PR），即使它对代码有很大的改动。这样做有两个原因。第一是等待PR修改可能阻塞其它同伴的工作流。第二点更微妙，基本代码保持可延展性是非常重要的：这意味着，要时刻准备接受修改。“完美PR”文化阻碍了这一点。它促进了代码在主分支是“黄金”，并不应该再次改变的概念。如果我们转而允许不完美代码进入主分支，那我们会鼓励更高的变化率。团队成员会学会问自己：“我看的代码足够干净吗？”
这有点违背直觉：允许主分支写入不完美代码可以提升项目质量。
那么，审查PR的更好的方法是什么？
我的策略是这样的。我首先通读整套变更，标注任何可能重要的事情。然后优先给出反馈，最多给三条修改建议给出意见。其它的就不管了。
我很少就编码风格问题进行评论，比如多出的空格，或者没有很好缩进的参数列表。如果代码是可延展的，有人可能在以后会清理它。同时，这些风格问题并不会妨碍程序的运行。
对于任何多于几十行的代码，是否能称之为完美，取决于观看者的主观印象。如果你期望每个人以完全相同的方式解决问题，那么你就错了。如果你对代码应该是什么样有很高的标准，那么你将会感到失望。
为你的队友提供空间，让他们能按自己的心意设计和编码，并鼓励每个人在系统设计时平等的发挥作用。
当你的团队写出的代码与你想要的不一样时，不要与他们争论。要记住，在团队中保持健康工作关系，长远来看是有价值的。所以也许你要牺牲你个人对质量的愿景。
我鼓励程序员每天花一些时间，回顾并反思自己的开发技术的发展。思考自己和团队每天的效率如何。这个月管用的下个月不一定行得通。特别在团队成员的技能从新手到专家成长的过程中，这一点尤为显著，这一点尤为如此。所以，尽量找出并改掉你身上那些开始给你带来更多伤害，而不是更多帮助的习惯吧。
今日荐文
点击下方图片即可阅读
推荐一个对技术人员的成长很有帮助的线下会议，将于4月16～18日举行的QCon全球软件开发大会（北京站），目前已经邀请来自Google、Facebook、LinkedIn、Airbnb、百度、阿里巴巴、腾讯等公司的100多位一线技术专家，是难得的线下交流学习的机会。具体详戳 「 阅读原文 」惊喜不停！
![]()
