代码质量是优秀程序员的底线，你居然说不重要？

   <p style="text-align:center"><img src="https://simg.open-open.com/show/27a28e5e8f013302e68caf5e1c95a656.jpg"></p>    <p>最近dash iOS 开源，infoQ推送了一篇翻译： 从Dash iOS开源说起，不要过于追求完美代码 。我读完的心情就是干死他，一本正经的胡说八道。每段都是先提出一个正确的概念，然后就展开表达混入害人的概念，这种写作手法让人不齿。</p>    <h2><strong>追求代码质量是一个优秀程序员对自己的要求</strong></h2>    <p>许多程序员文化是建立在完美代码的理想上：代码不仅能够运行，而且也必须是干净、优雅的。我们以巧妙地构建解决难题的对策为傲。然而这种完美主义可能不利于团队的成功，因为完美主义常常导致个人分歧。</p>    <p>我想任何一门工艺、手艺，从业者想要把他做的更好，这是一个非常自然的目标。</p>    <p>首先作者的标准非常之低。而且我觉得能运行、干净、优雅就是完美的代码了?这只是优秀还不是完美。完美主义不利于团队成功，难道20个人闭着眼睛瞎写就有利于成功？软件是因为质量差、性能差、维护不到位、功能不稳定容易失败，还是因为软件易维护、迭代快、发布慢了几天容易失败？有团队因为过于追求完美主义失败就是不要追求完美的原因？excuse me？</p>    <p>能得到所有人公认的完美代码标准并不存在。</p>    <p>因为你最后也赚不到全部的钱，你就不要赚了？你是只咸鱼别人也不能有理想？</p>    <p>这个世界很多人不懈的追求，不停的逼自己，追求完美才推动了这个世界变的更美好。你不能因为这件事情最后做不到一百分，就不去做。优秀的人会让自己逼近这极限。这是一个优秀的人对自己的要求。</p>    <p>也许会有限制，有所妥协，我觉得作为一个工程师，你应该要保证自己的代码质量，虽然做不到所谓的“完美”，然而我们应该对自己赖以生存的代码质量有要求，除非你是只没理想的咸鱼。</p>    <h2><strong>追求完美不是在商业项目里抠细节</strong></h2>    <p>我们追求代码质量，但是不是一定要在写好完美的代码后才能提交。也可以是一边写一边迭代改进。可以是回头恍然大悟的重构。也许我们项目也有时间工期的限制。我们当然要先保证功能的完成，然而这就是优秀工程师和平庸工程师的区别：平庸的工程师只能写出平庸的代码，优秀的工程师会在这些妥协的条件下做到尽量完美的代码。</p>    <p>再一次。代码质量是一个人的不断追求完美代码过程中的能力体现。如果你的目标从来只是能运行，你也写不出好的代码。</p>    <h2><strong>能用不是代码的标准，能被维护才是代码的标准</strong></h2>    <p>对代码库的唯一要求就是，它是可用的</p>    <p>这话体育老师看了都会哭。你自己身边哪个产品的目标是能用就行？</p>    <p>认为代码只要能运行就可以通过这是非常短视的行为。一个软件项目的生命周期并不是在你写完这个功能后就结束了。成熟的软件项目需求会变，也可能会增加新的需求，也可能你写的这个代码别人用到而别人误解了你的Api造成整个软件的问题，可能你写的逻辑有问题只是没发现（比如线程同步）后期的人员来调试。所以目标只是为了能用，不去考虑后面这些问题，到时候只会花费更多的时间。追求完美就意味着把后面的这些维护成本也计算在当下。最好的结果就是现在就写出没有bug好维护的代码。</p>    <p>大公司重视软件质量不是因为酷，不是因为他们工程师屌，是因为这样才是最好的方式。不去看看这些优秀的顶尖公司怎么做就靠在村头听村支书指点江山？</p>    <h2><strong>没有代码规范一百个人写出一百种风格怎么维护？</strong></h2>    <p>我曾经所在的团队，对编码标准有过如下规则：“功能不得超过7行代码”。事后看来，这个规则，还不如没有。</p>    <p>这种傻叉规则当然是不如没有，但是不等于代码规范就不重要啊。规定一个代码的最大的长度是没有理解这样做的意图：一个函数应该只做一件事。应该考察这个函数的复杂度是不是过大而写了这么长。不是简单的定一个不能超过5行还是10行的标准。</p>    <p>规范可以灵活的变动，很难说一个空格还是一个tab好，但是代码多了以后为了其他人便于维护就需要有一个统一的规范，约定的上下文。如果每个人都按照自己的习惯写代码这个场景就和全国个人的说自己的方言一样。没错，这也能听，但是考虑一下工程效率，这是不划算的。唯一的难点是，很多人恐怕是不懂得什么该制定统一的规范。</p>    <h2><strong>不合格的代码merge进来留着过年改？</strong></h2>    <p>我通常会迅速合并pull请求，即使它对代码有很大的改动。这样做有两个原因。第一是等待PR修改十分煎熬，会打消团队成员的积极性。第二点更微妙，基本代码保持可延展性是非常重要的：意义、准备和期待去改变。如果我们允许不完美代码成为主干，那我们会鼓励更高的变化率。</p>    <p>颠覆我世界观。等待pr会打消积极性？你们一个PR是要半年？这也是成员素质的问题。通常一个程序员每天至少一次提交。实际正常的话每天提两三次很正常。一个程序员半天写的代码你要review多久？我觉得如果不是你的review效率有问题就是他写的代码实在是让人看不懂。</p>    <p>第二点我觉得有点搞笑，总结就是：代码写的差后面维护的人就会来改，提高变化率。想想好像好有道理哟！</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/229c4ba74a2f1011db7b4b11ca4636a6.jpg"></p>    <h2><strong>优秀的工程师价值还体现在可以让身边的人变得更好</strong></h2>    <p>当你的团队写出的代码与你想要的不一样时，不要与他们争论。要记住，在团队中保持健康工作关系，长远来看是有价值的。</p>    <p>没想到你们老外也看新闻联播，打造和谐社会啊。</p>    <p>为什么要code review？就是可以通过一个优秀的程序员把关指出代码的问题，提高质量。作为技术负责人，如果对代码都不闻不问，那我来做好了。每次直接merge还要review干嘛。每个人都有权限推到master不就得了。提高幸福感？</p>    <p>每个人工程师都是从菜鸟到熟练工，再到大师一步步走过来。中间肯定都会得到更多经验的人的帮助，这也是我们提倡的开源共享精神的体现。我想如果每个优秀的工程师都不会拒绝帮助身边想写好代码的工程师。这也是一种精神的传承。</p>    <h2><strong>最后</strong></h2>    <p>有的代码质量差，就是差。这和他是不是成功了没关系。我们既然靠写代码谋生，就应该对代码有追求，对代码有自己的审美判断。</p>    <p>一个人人品差和他是不是有钱没关系。dash的成功只是说明了在这个项目的代码量下这样的代码质量可以交付出一个稳定的产品。仅此而已，不足为道。</p>    <p>代码质量真的只是一个底线。在这条底线之上，才有可能谈稳定，谈伸缩，谈性能，谈架构。达芬奇不会觉得画好一个鸡蛋有什么值得称道的地方。</p>    <p> </p>    <p>来自：http://www.cocoachina.com/programmer/20161201/18246.html</p>    <p> </p>