@
DarkCat123 方法不绝对，我只是说其中之一，还有一个东西就是，提前写设计文档画 UML
我一般要求自己和带的人用 markdown + mermaid 反复画状态转移图， 和状态流程图，和业务流程图。
第一步 ， 后先审图， 一般一个事情， 三图合一（互相验证没有明显看出来 bug 就基本 ok ），但是一般 3 年以内工作经验的， 都不用 review code，直接 review 这种图，就能发现一堆未考虑的点以及 bug，或者 case by case，抽象做的不好， 图巨大务必还很难看。 这是第一步。 把东西想清楚想明白。 一般都是 keep it simple （设计可读性 + 设计复杂度）的一个 trade off
新人 审 5 轮，老人审 3 轮。 防止出现设计完全是 bug，或者实现出来，没几天就推翻重写重设计（这个很多软件工程的书里都写的很明白，比如人月神话之类的，越早期的投入，越降低之后的投入，这里越少的投入，后面投入是指数级上升）
第二部， 写代码，写完代码 review， 一般来说 5 年以内的工程师，自己熟悉的领域不会出大问题（ 3 年左右，还是会出现设计没考虑到实现不好做，或者写代码的时候发现欠考虑了），能做到设计文档和代码 1：1， 但是， 如果有新领域和跨部门配合，还是会出问题。 review 代码的时候，让其自己的设计文档和最后的代码实现进行 PK 。
一般来说，会出现几种情况（设计文档里命名和代码里不一致这种低级错误，推荐第一次提示，第 N > 3 次直接考虑劝退或劝跳槽, 态度问题无关工作经验，起名都没法 1：1，我怎么能信得过代码实现和设计 1：1 ？）
1. 手懒，实现的简单，设计了但是没实现或者弱实现
2. 想多了，代码实现的时候，过度设计
3.设计能力大于实现能力， 设计的很好实现不出来 =>增强一些奇淫巧技和代码套路的学习
4.实现能力大于设计能力， 代码里充满了奇淫巧技，做复杂了 ， 很难和 2 区分，需要 review 的人个人能力碾压，才能识别出来， 这里需要考察代码 readable，更高维度的 readable 就是看了设计文档很轻松能对应上代码段， 这里一般是更高维度的 DRY， 因为他们 Repeat 的是之前的小范围的实现方式
12 其实是 34 的低级版本，其根源就是设计和实现阶段的脑力和体力的输出配比不均匀，我个人认为工程师代码讲究的是设计和实现的期间脑力和体力的持续稳定输出。 减少心血来潮，和状态不好的随意 /敷衍输出。
做到这点，基本上，代码这边儿就到头了（单纯字面意义的代码，不包含背后业务水平、管理水平、人力架构，项目架构（类似于怎么在合适的时间、合适的项目进度进入合适的人）这些东西）