你说的细节是什么？

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

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

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

@ZGame 笑死……

笑死，op 来找认同，结果被按着头喷。
水平不高的人当 ld 是这样的

while true 每秒检查一次就行了

我来讲讲为什么执着于要最大的权限
是因为程序开发生产要在运维搭建的环境上部署
很多运维的暗箱操作让程序员对整体环境的不了解
针对系统环境的陌生
让 debug 的成本增加
以及对于出现问题的排错思路被带偏到其他方向
比如有的运维会对程序员的程序进行内存限制，权限限制，网络防火墙，安全策略
说到底还是因为运行环境不模式
这也是 docker 的镜像的容器隔离来带的好处

但是跟你帖子里说有些差别的是，程序员不应该去碰生产环境。
但是如果生产环境和开发环境不一致，那么是运维和公司级别的锅了。

屌回去即可，老子出来打工不是听你屌的，能说就好好说，不能说闭嘴

哥们你这个东西我 19 年带 4 人队 15 天做过一个，你这个怎么做 2 年的呢

我知道你很麻，但是你先别麻，

据我所致有相当大一部分程序员连“RFC”都不知道是什么

其实领导也不关心是 token 还是 session ，他只关心他自己

打工的，犯不上生那么大气。

这也能卖钱？ https://github.com/apache/doris/discussions 这里不收费啊

看下 abac 基于请求者拥有的属性授予对服务的访问权

没口琴，差评

没必要 unzip 直接 vim 进去改就行了，打包时可能会有其他步骤，zip 时被忽略了

都这样了，还优雅呢…… 你这问题就不优雅

@hui9000 阿里的东西不讲规范，写的随心所欲，迭代的随心所欲。没有测试。没有文档。没人维护。

JHipster ，虽然我自己是不喜欢用这种技术，但是 JHipster 会在文档里对自己的行为做出解释，这一点就给个 70 分了