首先，这是一个 trade-off。一说到 trade-off 大家就应该明白到，这不是一个简单黑与白的问题，没有什么是绝对正确的，要看上下文来做判断，不同的情况会得到不同的结论。要理解上下文，就要有大局观，了解业务和产品，还要了解当前的形势。（我知道这在国内很难，因为中国公司都倾向于把人变成螺丝钉，让大家不要去关心自己工作以外的大局，但这是必须做好的一件事情。）
举一个很具体的例子，Facebook 曾经有一个产品叫做 Flash，可以认为是面向发展中国家低端 Android 用户的 SnapChat。这个产品就一个小团队来做，做了一个季度上线发布，然后又做了一个季度打磨已有功能、增加新功能和搞运营活动。因为一切都是赶出来的，代码里面就存在大量的 technical debt，团队内部就有了一场辩论：到底要继续往前冲做产品做运营，还是先重构代码提供将来的迭代速度。最终团队的决定是继续往前冲。
我们团队跟 Flash 的团队合作，看到他们做这样的决定我当然是不喜欢的，因为他们的代码有 technical debt 影响的不仅仅是他们的迭代速度，也影响我们的迭代速度，因为我们依赖于他们的部分代码。但如果我站在他们团队的角度来思考的话，我会作出同样的决定，因为我知道 Flash 的用户留存做不起来的话一切都是白搭，这个产品过一段时间还存不存在都是问题，所以当务之急就是用一切产品和运营手段把用户留存做起来。
又过了一个季度，带领 Flash 团队的总监见到产品还是没有起色决定放弃，团队解散。这恰恰证明了当初的决定是正确的——能不能把产品做好是决定团队死活的唯一指标，所以任何事情都必须让步给产品的探索。产品探索之所以是探索，因为没有任何方法能保证一个产品必然能做起来，但你拼到最后一刻你肯定会后悔的。如果当初选择了花时间重构，那重构后漂亮的代码给谁继续开发呢？团队解散时整个 Flash 项目的代码就彻底删除了。
如果你在森林里方便时突然看到有只熊，你是先把裤子穿好还是先跑？如果你坚持说，「我们是文明人，面对熊这种低等动物也要整理好着装」，那你自便……
再举一个例子，在 Facebook 另外一个角落里有一个只有一个人的团队，是一个非常资深的工程师负责着整个网站的 JS/CSS 打包系统。这个系统并不是 Webpack 这么简单，而是能够根据整个网站对不同模块的用量来决定哪些模块打包到同一个文件里面，目标是最小化下载浪费（即文件被下载了但里面部分模块不被使用）。他很欢迎其它人来帮他改善这套系统，但对 code review 要求极度苛刻。Facebook 里面 code review 一般有一个人通过了就算通过，但改打包系统代码就算别人通过了他也要拦下来自己再仔细看一遍。
这种对代码质量截然不同的要求是由业务决定的。JS/CSS 打包系统出任何细微的错误都会导致 Facebook 整个网站下一个版本发布失败，如果不是编译阶段就出错的话那还可能把错误带到 JS/CSS 里面去。如果对 JS/CSS 的压缩出了点什么差错，用户能正常下载到文件但就是不能执行，这会严重影响用户体验。因为这个系统的错误可以对整个网站带来灾难性影响，所以对代码质量要求极度高。
总的来说，你没有大局观，你就不知道你在 trade-off 的是什么，所以什么是正确的取舍无从谈起。你要知道业务和产品在乎什么和不在乎什么，你才能资格谈论你取什么舍什么。
如果你已经知道 trade-off 该怎么做，但是别人持有不一样的观点，这时候你必须有理有据地去说法别人。其中一个套路是量化你的取舍，但并不是所有情况都可以量化的。
什么叫做量化？举个简单的例子，如果你跟老板说「这个季度给我 3 个人做重构，明年要整个团队一起做的大项目会变得更容易开展，可以由 10 个人减少到 6 个人也能完成」，老板很容易接受（前提是老板相信你的判断力）。人力资源配置是老板很在乎的事情，如果提高代码质量对人力资源配置有帮助的话，是很有说服力的。
当然你也可以拿业务和产品的指标说事，但你需要言之有理，就算有些数值是估算的，总体上来说你也要能说明为什么提到代码质量会带来更好的量化结果。如果你说明不了的话，那别人肯定想要做一些能直接带来量化结果的事情，例如做更多的新功能，更快的完成新功能。
程序员你做到后面就会发现你必须要能做好销售的工作，你做不好你作为程序员想做的事情就没人愿意买单。所有事情最终都是要有人买单的，你想要提高代码质量就比需要有人愿意买单，就算这真的是合理的事情别人不认同你肯定会遇到阻力，最终你还是要想办法把代码质量这件事情兜售出去。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
