ZARRO

@chaoyebugao 是的，最终决定把数据库也隔离了，也就是变成了测试环境。

@cloudzhou (不小心点了回复) 但是缺点是由于共享 db 导致无论如何都无法保证不影响线上数据。由于公司各个服务调用链路比较复杂，一时无法解决，而影响线上数据又是无法忍受的，所以就下线了预发布环境。取而代之的是加强对测试环境的管理。不受未发布的功能影响→任何需求都通过泳道发布互不影响(也就是一个需求一个环境，但共享测试环境数据库)，只有当天要上线的需求由 qa 合到测试环境进行回归(在此之前先在泳道验收)，然后每天自动将 master 分支发到测试环境。数据真实→qa 自动化测试用例。
至于配置相关的内容则是通过发布计划、金丝雀发布去解决的

@cloudzhou 是的，这说明你们工程管理很优秀。但楼主的问题就是工程管理问题，所以我认为预发布环境不是解决楼主问题的关键。
如果功能可以在预发布环境回归验证，那么就可以在线上环境回归验证。如果不好验证，或者影响面很大、需要灰度，那开发的时候做灰度逻辑，而不是依赖环境。预发布环境优点是数据真实，且不受未发布的功能影响。

nextjs 。总的来说 v0 用什么就学什么

共用数据库其实也有很大隐患，前司几次生产事故就是由预发布环境引起的，后来就下线了这个环境(下线的过程中也出现了几次生产事故)。通过引入预发布环境来解决工程管理问题，但却又因此引入了一个新的工程管理问题……

就像用了 springboot 就很难回去 spring 一样，jetbrain 爽在开箱即用和统一

嗷嗷，开关啊，貌似看审错题了。。。

热水器智能开关很方便，定时任务提前烧水，下班回去或者早上稀疏的时候直接就有热水。空调用空调伴侣，也是定时任务开暖气，冬天直接无痛起床。

一个人开发怎么来都可以，所谓规范更多的是用来解决多人开发的问题的。从多人协作的角度来看，两项目耦合同一个数据库就是不好的设计，因为这意味着 A 系统的开发者修改公用表的逻辑的时候需要去评估 B 系统是如何使用这张表的。解决这种耦合方法就是去划分领域，如果 AB 都是一个领域的，那么没必要划分成两个项目。如果 AB 领域不同，那么公用表是属于哪个领域的呢？是否要引入第三个领域 C 去做这一块逻辑？一般而言哪个系统写这张表就归谁，其他系统通过接口访问即可。不太理解你为什么要选择一种既不是单体又不是微服务的架构。你应该考虑的不是将 dao 变成公用的然后“复制”成两份给两个项目使用，而是该考虑这两个系统是否有独立部署运维的需求，如果有，考虑微服务，如果没有，合并成一个真的单体。
架构方面的书可以看《凤凰架构》，批判性的了解一下 DDD 。设计模式随便找些网站都能看到，但是关键是知道什么是设计模式。为什么这么多人用设计模式用的这么生硬，越写反而代码越难看？因为他们不理解设计模式只是在特定场景下的由一系列重构组合而成的解决方案。从这方面而言《重构》是一本好书，你可以注意到书中介绍的重构方法是极其的简单，并且部分方法之间是互相冲突的。这揭露出抽象化和反抽象化都可以是一种好的重构，重构没有银弹。之后你再去看那些设计模式，你就可以去推导，他们是由哪些重构组成的，其中各个重构的效果是什么，当前你需要哪些效果，如何去掉那些你不需要的重构。这样在解决问题的时候就不需要去硬套设计模式而引入一系列你还不需要重构导致代码笨重，产生过度(早)优化的问题。如何去应用 DDD 也如此思路。