如何引导程序员新人按正确的流程开发? 第1页

1. 用GitHub或类似的现代平台
2. 平台上设置禁止直接push到主干，所有的修改必须fork后走Pull Request
3. 启用CI（持续集成），提PR时平台自动执行CI步骤，失败的不能被合并（不准开任何后门）
4. CI加入linter，确保代码规范；所有代码规范必须要可由linter检测，代码规范/linter配置规则也要针对实践中发现的问题不断补充细化和更新
5. CI加入单元测试，代码的测试覆盖率至少60%以上，核心模块测试覆盖率必须90%以上；所有发现的bug必须由造成bug的人负责补上单元测试
6. 每个PR强制要求改动代码行数小于100行，新人要求小于60行，以利code review
7. 每个PR在CI通过后必须有其他人进行过code review并approve，否则不能被merge，新人的代码必须至少有两人review和approve（比如新人的mentor和相关代码文件或目录的owner）
8. 针对每个PR自动部署一份到测试环境，方便自测或提供给测试团队进行必要的测试
9. 每2周检查近期bug，总结经验教训，特别是重复犯的错误一定要建立机制去防范

【警告：评论区凡是类似『不现实』之类的蠢话的，直接折叠。】

【更新】

从评论区看，主要的不理解在于第6条。第6条的关键其实不在于具体的行数限制，而在于确保code review是可执行的。具体来说有以下几点：

1. 再厉害的工程师，同时可handle的代码行数（理解代码的意图，并能把代码在脑子里跑起来）的能力是有限的，而且理解他人代码明显比自己写代码要困难。所以一次性review的代码量必须控制在一个范畴内。否则reviewer要么无法高质量完成review，要么需要更长更大块的时间去进行review，从而降低整体效率。
2. 一个PR上的commit/review动作是异步的（reviewer不可能中断手头工作去立即review代码），同时又是线性交错的。想象一下你在并行和异步编程时的经验，critical region越小，整体性能才会越好。我们希望一轮review（reviewer看代码提出意见，committer响应意见提交修改）要尽量快速，否则一个pr来回几个回合用上好几天，效率低下，大家都很疲劳，项目管理和排期的风险也增加。
3. PR越大，reject成本就越高。因为成本高，所以committer会很抗拒被reject，比如找借口先合并进去再慢慢改，reviewer的心理负担也变大（我为什么要不通情理，做坏人？），双方的argument也可能会更激烈，对团队和谐不利。技术决策最忌讳掺杂非技术因素，技术债都是这么积累的。所以必须尽可能降低沉没成本。
4. 上述两点均会导致committer和reviewer之间的关系紧张，commiter会专找好说话的reviewer来review代码，reviewer也不愿意总是『block』其他人的工作，从而逐步放松代码质量要求。所以PR太大，会显著增加code review逐渐无效化的可能性，这是人性所决定的，不是其他因素可以左右。只有控制pr的规模，让大家日常的commit/review动作都颗粒度变小，代价变小，才能尽可能的让code review保持快速有效，高质量，和日常化，从而建立持久不变形的code review团队文化。

关于一个功能是否能用100行写完。当然很可能是不行的。但是谁说一个功能要直接对应到PR的？我们希望工程师合理拆分功能，功能需求本身可能是一坨，但对应的技术模块可能是若干个，完全可以也应该一个一个来啊。我们还希望工程师合理规划，分步骤进行设计和编码，谋而后动。人经常高估自己的能力，觉得自己已经搞明白了，真的实现起来才知道不是那么回事情，结果做了很多无用功，走了很多弯路。人也经常低估自己的能力，觉得太难了，做着做着就放弃了。把大任务拆细拆小，能让工程师和技术管理者时刻心里有底，更容易摆脱这种高估和低估的困扰。

另外一些细节问题，比如feature branch、boilerplate code是否可以超过100行之类的？见评论区我的回应。

首先，你得要有流程。

其实让新人按照流程开发并不难，问题是你的描述显示出你公司根本就没有流程。也根本没有人来维护这个流程。

你希望凭空诞生一个莫须有的流程，然后在没有任何人维护流程的情况下它能够自主自然的运转起来，这是不现实的。

所以题主，你需要的是先建立你公司的流程，只要你真的建立好了流程，那么流程自然会出现在新人开发的过程中，无法规避，不会因为他是新人就变得不存在了。

---

高票说的那个方案，同样也建立在这个前提下，首先要有流程，然后还要有专人来保证这个流程的执行。如果那个 code reviewer 的人不存在，那么高票的那个方案就没法执行。

为什么 code reviewer 需要专人？因为如果让他写代码，他的产出可能比看代码要高；让他写代码，可能获得更大的成就感；让他写代码，可能会觉得更有趣。——对于大多数程序员来说，看代码都是比写代码更痛苦的事情，如果可以，不会有人愿意把时间浪费在看与自己无关的代码上。。。一个能写代码的人自然会抗拒 code review 这件事情，除非完全剥夺他写代码的任务，才能让一个人安心看代码。

---

  Ivony 网友的相关建议: 
      

我觉得需要引导正确的流程的是贵公司吧，一个程序员可以随便改改代码就上线？

---

  qiongmanong 网友的相关建议: 
      

很多新人刚开始的时候真的是战战兢兢的，生怕犯错，生怕问stupid的问题。反正就是诚惶诚恐的。作为老人，帮帮他们呗。让他们脱敏，一般大公司也有新人会犯错误的预期，大家都会遇到the first one million mistake，然后一般也是no blame的政策。

如果你想让新人按照正确的流程进行开发，很好呀！

那你先给新人写出规范的流程，然后让他们刚开始的时候学习流程，回答他们遇到的问题，手把手教一下重要的地方。

上面就是大部分正规it公司有的流程吧。而且不管是实习还是全职，刚开始肯定会给个一两周的ramp up，然后也有training sessions。跟着这些走完应该对公司的写代码，review代码，提交代码有个大概的认识，然后有问题就赶紧问。写两个starter tasks就差不多了。

而且一般mentor或是组里的人还算nice的，毕竟以后要共事那么久，大家也都是从啥都不懂开始的，最好还是对新人好一点点吧。

等他们搞个两三个月，能力提升了，也慢慢不需要手把手教了吧。

---