There is a wonderful channel called Code Review in Stack Exchange, it provides for a kind of question and answer style to review code for programmer.
Code Review Stack Exchange is a question and answer site for peer programmer code reviews.
Code Review不是一个新词，甚至是老生常谈。这次我们不讨论它的方式和规范，而是从商业的角度上看待这个问题。没有国外IT公司的开发经历，我们只基于国内的开发环境来看待这个问题。
论点
-
开发者大都是带着排斥心理去接手老项目的
这不是在否定开发者的心态或者工作态度。假想现在突然有一个项目要我接手，首先对这个项目作出评价，就优缺点而已，其实我是先找缺点的。先把所有的毛病和奇怪的地方先梳理出来，先默认断言它是错误的，然后否定上一个结论，如果没有找到合理的解释，那就是一个问题/缺点了，如果找到了当然就忽略。直到最后我才会开始思考到底哪些地方值得算是优点的。
对于一个没有上下文的项目而言就真的是这样，相反，如果是在Github上的一个开源项目，我们首先会看项目的Star, Fork, Commit和Contributor的数量等，然后决定开始以一种什么心态来阅读这个项目的源代码，这是有很大区别的。（当然也确实存在有些大项目后期被改残了的。）
-
老板需要人来维护已有的业务逻辑
这应该是定理了吧，毕竟在不考虑业务逻辑大变化的前提下，现有的代码毕竟是老板请人花钱写出来的。对于后来的开发者而言也不能说随便就重写或者重构的。
-
Code Guideline vs Code Review
就我个人的认知而言其实Guideline其实只针对多人协作的编程方式，而且Guideline的目的是在新人加入一个项目之前应该了解的编码指南，它算不上是一套规则，最多勉强算是一个language style guide。Code review更侧重于对已有代码提出的质疑，也包括对不满足guideline的问题。
以下部分地方简称Code Review为CR。
-
小公司大都是没有code review这个workflow的
毕竟老板只想着找人来完成自己公司的业务实现，只关心it works这唯一一个结果。有些老板甚至在内心里也认为开发者也完全只是为了那份工资才来协助完成这份工作的，他们根本理解不了那些真正写代码的人。
-
Code Review到底做了什么
这一点算凑数的，只是为了加一个链接而已。 CR的主要作用一直都是优化并维持代码的高质量。
-
Code Review到底对谁有利
- 老板，也就是到底省不省钱。如果没有CR或者中断了一段时间的CR，新人接下来就是要大重构甚至重写了，这没什么问题，只是要花更长的时间，也就变相花了更多老板的钱。（好吧，有些外行老板只会压榨开发者的时间和加班让他们的完成这个事情，这也是常有的事情。）这是一种隐性的利好。
- 开发者，其实我觉得这个几乎不算是一个答案选项。没有CR，开发者只会按照自己的一贯方式来完成一个项目，这其中也包含一些坏习惯，比如随便留一些hacking/magic code，temporary fixes等等。CR也并不能给开发者提供一个最佳的学习方式，因为从CR中学习别人的编码思想并不如直接阅读优秀的开源代码有价值。正如天天刷微博学习碎片知识和阅读完整知识树。有了CR之后，只会给开发者增加额外的时间来完成项目进度。唯一的好处可能只是在有限定性的规则和约束的同时给后续增量开发制造了一个舒适的编码体检。
-
Code Review之外还有（应该）什么
单一的CR并不是完整的，它只是在每一个迭代的增量更新中优化一部分设计而已。一个项目的完整大框架设计不应该单单依赖于CR，所以架构设计还是非常有用的。
需求
公司/老板把Code Review这个流程外包。
对于不同项目每个公司一定会有自己独立的一套架构设计，针对服务器，前端，客户端等等。这一点对于老板而言可能还真没有省事的解决方案，只能找开发者为自己单独设计，其中也包括为了涉及到的保密问题。相比于CR，我认为保密级别的问题还是相对低不少的，这其中还可以通过技术来很大程度上来解决这个问题。
设计
客户方把项目代码托管到自己指定（类似Bitbucket Server，简称Server版）或者服务方的平台（类似Bitbucket Cloud，简称Cloud版），接收代码之后由客户选择是否混淆符号，选择哪些代码文件可见。Cloud版允许所有Reviewer查看和review所有项目代码，Server版可以是邀请制+合作制，只允许指定Reviewer来查看和/或review指定项目代码。两个版本都可以有免费和付费制，并基于贡献值建立Reviewer的声望值。
托管
从托管安全的角度上讲这个业务如果是Bitbucket来做是相对比较有信任感的，毕竟有大厂背景以及他们现有的其他优秀的托管衍生服务。要加上这个业务也是最容易也最让人能够接受的。
保密
鉴于这是一个主要toB的项目，必须要让企业对自己托管的代码放心，即使是Atlassian这样的大厂，也还是推出了上面提到的两个版本的Bitbucket托管服务。
混淆
以基本的符号替换为例，这是有必要的。不管是针对公众还是企业针对自己的其他部门，都一定会有这个需求，主要是让老板放心托管。当然，混淆的数据还是需要加密处理并一起由托管服务负责，也需要加密处理。
加密
加密的核心是为了为技术付费，不让人（轻易）破解。针对的数据包括代码文件，混淆符号表和review的内容。Server版可能会脱离中心服务器的控制，所以至少可能还是需要license授权的方式才能访问系统。
Reviewer
需要有完整的Reviewer用户系统，经验，tag，语种，声望，奖励等。从这个角度来说，Stack Overflow是非常好的借鉴。没有声望的创作内容是没有评定价值的，没有奖励的创作是不可持续的。
奖励
包括声望，现金，甚至还可以有Offer。
KPI
老板的钱会花得有理有据，不然最多可能只是一个一次性消费。要有报告，统计被采纳的解决方案top 10和总数量，团队内部开发者的评价，Reviewer对项目的评价等等。
生态
在设想建立这个供需关系的时候，我们先不和公司现有的工作流进行对比。
无论哪个老板都不想自己的项目最终被搞成一堆臭狗屎，然后一波又一波的换人来重构或重写。对开发者的规范和警醒也是有必要的，CR在一般公司内部难以维持我认为有几点原因：一是领头没有带好，这是一系列协作流程的最终结果；二是依靠团队内开发者的相互监督建立起来的规则大都是弱化的，无法长期维持；三是老板只顾眼前利益和计划，当然大部分时候也是因为老板也没得选（解决方案）。
引进外围的Reviewer并不会对现有的项目开发者产生直接冲击，只会是约束效果和让自己更自律。对老板而言只是花另一小部分钱来维护自己的项目而已。
周期
传统的CR最大的弊端应该就是会拖延项目周期，毕竟对某些老板而言有时候时间比钱更值钱。传统的团队内部CR在时间上一般会因为Reviewer的工作计划有些冲突，最终导致代码合并时间点延后，甚至可能block其他开发者的进度。
解决这个问题的核心在于Reviewer的数量级和直接的奖励制度，良性循环才可能有最直接的效率输出。
证明
None
总结
None