我感觉这是不能一概而论的。情况不同，处理方式不同。

复杂的业务系统，有时候你本地跑起来也没用，即便是单体架构。因为你本地未必有数据。如果每次写一个业务功能，都要写对应的单元测试、mock 这个业务各种场景的数据，那开发进度会大受影响。随着业务发展，可能还要写各种数据迁移。 如果这个业务是重要的（比如，飞机航班）、商业价值高的。那这样做没问题，也应该这样做。但是如果只是前景都不明朗，就投入一两人力的探索性系统，这些都不重要。提早把过多精力，放在这些方面有点浪费了。

我理解 OP 的感觉。我也很讨厌这种无法启动的项目。我觉得我们能做的事大概就是，在接手项目时候，所需要的适应时间成本一定要计算进去。这其实是切换上下文带来的时间成本，别说是接受别人的项目。回头维护自己过去写的项目，你可能都需要有不小的上下文切换开销。时间充裕了，至少不会因为时间问题加剧这种情绪。

偶尔听说一些，一些风水理念，感觉是有点道理。例如：镜子不对床、不对门、不住在风口（穿堂风）、单灯不顶头。感觉有点道理的项，自己也会有所注意。没细致了解过，所以看山看水那些也就听听，一愣一愣的，太玄的就不去细究与跟从。

以前有看到代码注释放个佛祖的，我觉得这种也蛮正常的。只要不魔怔、不要本末倒置了就好。代码 BUG 少，一定是写的人努力来的结果，而佛祖在这里能起的作用，估计最实际的是让写的人心理状态自信、平稳。他要是平时不努力，没有实力，放个什么都没用。

另外，我每次回老家都要给爷爷、家里供奉的（我也说不出来名字 T_T ）、天公上香。对祖先是缅怀，也祈求保佑家人平安。对上，可能就祈求得比较泛一些，都是比较大的面，很少祈求私家的事。 我不会去祈求明天让我中个 500w 彩票，或者让我能有什么贡献极大的科学发现，又或者考试能满分，面试通过，升职加薪，年终绩效满分。。。。。。这就很可悲。三分天注定，七分靠自己打拼。

OP 提到的那货非常的可恶，为了兜售自己本末倒置的理念，给别人下“诅咒”！

随意。prettier 配置好，加上 githook ，让它自动去 format 。

纯前端团队，建议单引号，毕竟不用按 Shift 。 夸语言团队，可以使用 双引号。在一些语言里，单引号表示 char ，双引号表示字符串。

@0o0O0o0O0o 真 ~ T ~ M ~ D 的好。感谢~

新手，弱弱问下。有状态应用部署在 k8s 中，为什么挑战会比较大？ 指的是大规模、高可用 redis/kakfak/zk 集群吗？

@Goooooos 原来 redis 还支持操作~ 谢谢！

@rrfeng 我也想过这个方法。就是语义没那么明朗。

原来大家都是不依赖 CI 工具的语法写 CI Job 的~~


@FlytoSirius 关于 secret ，至少我感觉 Jenkins 里的 secret 不是很好用。才萌生了把配置放入加密代码中的想法。

@CivAx 谢谢~ 我去了解下。

说得很对，主要就是 PromQL 还不熟。 之前在生产环境上，把服务搞 OOM 过。准备自己搭一个学习环境 来玩一玩。

@Frankcox grafana 里我看了下，主要都是根据 namespaces 的维度来看资源使用情况的，刚好没有节点的。metrics 我相信是收集了，只是没有配置对应的图表。 后续去看看怎么配置。

@salmon5 w(ﾟДﾟ)w 哇哦！ 感谢，感谢~

企业大到一定程度，肯定是要追求私有化部署的。别致盯着国内看，你看看国外，Google 会把服务部署在 AWS 上吗？


你说的更多的是中小型企业，据我上一份工作的经验，这类企业大部分是接受 SaaS 的。

我自己觉得 DSL 多了，要记的东西就太多了。不同的 DSL ，等于有不同的编程语法。

但是矛盾就在于，DSL 本质上是沉淀的结果，总不能每次写个新东西都从二进制开始吧？

只能说希望同领域、同场景的 DSL 语法最好趋于相近，能有一个统一；不同领域、不同场景的 DSL 的语法，能遵循一定的规律。

据说，候补多的话，会动态加开列车。有人这样买到票吗？

这样挺好的。成熟化的软件领域就得是这样。假使，每次要写个 web 项目，都要先写一个 web 框架、db 框架、甚至要写个新的操作系统。

总还会有新的领域会出现，等待有识之士去占领。

@maocat 之前 2022.1 出的时候，升级之后也是各种 bug ，我才退回到 2021.3 ，结果就一直用到现在也没什么大问题。

哈哈哈~

@yinheli @ss098 这个倒是，我也是这样做的，resource “代码化”，进而方便管理。

@arloor “掌控感” 用得很精准，我也是这样觉得。那么多参数看起来会紧张。