zhazi

规则引擎

你说的细节是什么？

不去整天创新的程序员才会让人有安全感，
见过非常多的程序在进行所谓的创新，其根本原因就是读书少，见识浅。
人家几十年前玩剩下的他捡起来玩的乐呵呵，然后自造词汇美其名曰创新。
还见过一大堆人对着已经设计很完善的组件进行再次封装，屏蔽了好的设计。暴露出自己的愚蠢，美其名曰灵活。
能够遵守已存在的规范，照着官方文档进行 best practice 就会让人有安全感。
就怕又菜又爱玩的

你说的分层是软件架构设计，跟用什么工具没关系，跟什么语言也没关系。
层是分离职责和管理依赖关系的方式。 每个层都有特定的责任。 较高层可使用较低层中的服务，反之则不行。
传统的三层应用程序有表示层、中间层和数据库层。 中间层是可选的。 更复杂的应用程序可以多于三层。

编写设计文档的同事和开发的同事在设计和实现的时候没有考虑很多特殊业务上的场景以及异常的处理。
1.提前介入
我觉得你既然是顾问，就需要在编写设计的文档的时候参与进去，提前将特殊业务场景，用户故事交付到文档。
2.划分测试边界
只保证业务流程相关问题。像边界值，像 happy path 都由研发去负责
3.选择正确的角色
（要么我自己去重构一遍，可工作量很大，并且我还得从头问一遍业务上的细节），从这句话看出你连自己的定位也没分清楚，测试可以戴多顶帽子，产品，用户，运营。但裁判不会下场当运动员的。并且重构不是为了消灭 bug ，而是让 bug 暴漏出来。

@ZGame 笑死……