探究软件作坊：关于Code Review的迷思
作坊。从事手工业生产的场所。工具一般比较简陋。个体手工业者作坊由作坊主（一般是有较高技艺的师傅）带领帮工或学徒在生产中实行简单协作。
软件作坊。一种超小型的软件企业形式，一般由3-10人组成。由一位专精业务或专精技术的负责人带领，在工作中实行流程较为简单的协作，基本不会使用复杂或昂贵的工具。软件作坊可以成为粗陋糙猛的草台班子，也可以成为小而美的高效团队。
Code Review。代码审查。在软件开发过程中，对源代码进行系统性检查的过程。通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。
对于软件作坊，严格的Code Review可以有效提升产品质量，从而降低维护成本；同时提高团队的技术水平，有助于团队成长。但在具体的实践过程中，却存在诸多有关Code Review的困惑。
时间紧、任务重，这次就算了
“这次就算了”很容易导致“次次都算了”。再说了，对于软件作坊而言，又有哪件事情不是“时间紧、任务重”的呢？作为团队负责人，真正应该做的事情不是拍板“这次就算了”，而是想方设法让时间不那么紧、任务不那么重，从而尽可能多的给Code Review等质量保障措施留出余地。具体方法包括但不限于：
- 对任务有自己的分析，规避部分不需要做的事情。有些任务纯属锦上添花，并不影响产品的最终商业结果；有些任务则完全是需求方拍脑门的瞎折腾；还有些任务甚至是重复性工作，用现有的开发成果就能很好的满足任务背后的诉求。对于这类任务，团队负责人应当有清醒的认识。就算无法把任务拒绝掉，也应当调整其优先级，避免此类任务占据大量的研发资源；否则，很快就会听到“一将无能累死三军”的抱怨。
- 区分核心项目、普通项目和一次性项目。人的时间和脑力是有限的，软件作坊的时间和脑力资源也同样是有限的，而需求则可以说是无限的。这一矛盾的必然结果就是：要么团队疲于奔命，并在疲于奔命中丧失创新力和团队凝聚力（对于软件小作坊来说尤为如此）；要么就逼得团队负责人分清轻重缓急。哪些是整个产品的核心，应该分配足够多的时间来打磨；哪些是普通的功能开发，可以先把主要的模块做出来上线，细节问题则留待之后再解决，甚至砍掉部分不常用的内容；哪些是一次性项目，应当尽可能压缩它所占用的研发资源。
- 说服需求方接受分阶段交付。在项目的开始阶段，要说服需求方接受交付日期的延迟往往很难。无论有再大的技术困难，在懂市场却不懂技术的需求方面前都无济于事。相对而言，说服需求方接受多阶段交付则更容易一些。在这种模式下，需求方可以早于预期时间（甚至是远早于预期时间）拿到第一个可用的简化版本，自然乐见其成；而软件团队负责人则可借此尝试说服需求方放缓多阶段交付过程中最后几个次要阶段的节奏，从而给最初几个最重要的交付阶段留出空间。
- 选取合适的外部工具/模块来加速开发，避免团队重复造轮子。“工欲善其事，必先利其器”，只要这个“器”的价格在可承受范围之内，那么使用成熟的现成工具/模块总归比自行研发要划算。软件作坊的研发资源是非常有限的，这一有限的资源理当聚焦在产品的核心卖点上，不应该在各种通用功能模块上分散精力。
即使做了各种努力，作为团队负责人，可能依然会发现“时间还是那么紧”、“任务还是那么重”。此时，我认为可以适当减少分配给Code Review的时间，同时适当降低Code Review的严格程度，从而充分利用好有限的Code Review环节，尽可能多地检测出那些低级错误和明显的业务逻辑纰漏。
需求多变，Code Review做了也是白做
这一观点是非常好理解的：如果今天的这个需求明天还不知道是否存在，今天的这个业务逻辑明天还不知道是否成立，那么今天写的这个代码明天又会在哪里呢？在这种情况下，给今天写的代码做严格的Code Review，岂非痴人说梦、自寻烦恼？
事实上，矛盾的焦点并不在Code Review上，问题的根源也和Code Review无关。真正要解决的是“需求多变”及其背后的原因，避免出现“快速试错都是错”的现象。需求变幻莫测，这本来就不是一个正常的状态。在这种非正常状态下，任何好的项目实践都会失效，包括Code Review。
打个比方，如果一支军队的指挥朝令夕改，令部队上下无所适从，我们可以据此认为军事训练是无所谓的、战术筹划也是徒劳的吗？如果答案是肯定的话，那么等待这支军队的结局只会是惨败。对于软件研发来说也一样，既然需求多变，Code Review做了也是白做，那么我们是不是也可以说：既然需求多变，代码写了也是白写，不妨索性胡乱应付一下？如果团队在做的事情一直都是“胡乱应付一下”的话，这样的团队未来会在哪里呢？
团队能力不足，Code Review检查不出来什么东西
这往往是软件作坊的痛点。既然是“作坊”，就不免在发展的各个阶段面临各种人才短板，但若因此而否定Code Review的必要性，那就属于因噎废食了。
事实上，简单的Code Review根本不需要什么高超的技术能力，所需要的不过是“能读懂别人的代码”罢了 — 如果提交的代码令其他工程师感到云山雾绕不知所云，这样的代码又何谈质量与可维护性呢？而对于程序员来说，但凡有些自尊心和自我追求的人，只要想到“我的代码是会给别人看的”这一点，就足以让他/她在写代码时更加上心。
如果团队能力有限，那么Code Review环节可以从一些非常简单的规则做起。比如缩进必须正确，命名必须能让人看懂等等；然后随着团队能力的提高而逐步加大Code Review的严格程度。不能让“能力不足”这四个字成为阻碍进步的挡箭牌。
Code Review好是好，但过于依赖工程师的主观积极性，很容易变成形式化的走过场
是的，从管理的角度来说，如果某个工作环节依赖个体自觉，那么这个工作环节往往是靠不住的；而解决方案也很简单，那就是让Code Review成为日常工作的一部分并计入绩效考核（KPI/OKR）。通过合理的流程设计来保障分配给Code Review的时间，同时保证Review的质量。作为团队管理者，则可以留心注意那些积极参与Code Review并能给出高质量意见的工程师，然后给予适当的表扬与重用。
Code Review占用的时间过多，会影响正常的项目开发
事实上，只要Code Review的严格程度与团队能力相匹配，Code Review环节所占据的时间并不会很多：如果团队能力一般，可以适当降低Code Review的严格程度，只检查最严重的代码错误；而随着团队能力的提升，犯低级错误的现象会越来越少，Code Review的效率也会越来越高，此时不妨适当提高Code Review的严格程度，提升Code Review的效果。除了考虑团队的技术能力外，也可以根据项目的实际情况来调整相应的Code Review的标准。
避免Code Review环节耗时过久的方法有很多，除了灵活调整Review的严格程度，还可以设计合理的流程，避免出现把Code Review当做作业批改的现象；也可以借用外部的自动化工具，让机器来自动检测代码中的问题，节省部分人力成本。
结语
软件作坊的研发资源是极其有限的，如何使用这一极其有限的研发资源来做好Code Review是一个非常有意思的话题。如何设计优化作坊内部的Code Review流程？如何使用自动化工具来减少Code Review上的时间开销？这些都值得团队管理者进行深入的思考。
