justdoit123

链式操作的场景其实没那么多。

倒是可以多借鉴一些函数的功能，对常用的 list （或者数组）、dict 等操作进行封装。

我写 python 看到满屏幕的 [x for x in yyy if ba la ba la] 都看麻了。

另外，要提醒。这种链式组合操作的性能其实不好。当然，大部分场景无需考虑。

但是，如果你在写一个很基础、会被高频调用的功能，这点性能损失可能就会被百倍千倍的放大。如果是这种场景，建议还是在一个 for 循环里，把要做的几个操作（ filter 、map 、reduce 等）一次性全做了。

ebs 还是有问题，k8s pv/pvc/pod 会出现卡死的状态，绑定关系也无法真正解除。nnd

前端 4K 显示器算是刚需，毕竟 UI 要看得细。但是电脑嘛，M2 16G 内存以上的 macbook 完全够用了。

说真的，这毕竟是公司的资产。只要没影响生产力就算可以了。事情听起来是膈应人，但是作为员工也没得多提什么要求。

@JoeDH 没人比我更懂售票！ 没！！！人！！！

@qxmqh 我们现在是有业务开发的时候。尽量做一些清理工作。太多太多功能了，其实可以不要的。这些僵尸功能不清除，要合并单体也是够麻烦的。

我们核心的功能是个人数据同步、社区、会员三个业务模块。但是却附着大量产品经理们的“快速实验功能”。

@kuanat 非常感谢老哥的经历分享！

我们的 common 库（基本等于工具库）也有类似你说的不一致问题。

1. 改动不兼容。依赖的地方迁移不干净。后来要求，尽量不做不兼容改动。实在要兼容，旧的别动，写个新的。扩展到本主题的常量、DTO 代码，也是这样的道理。不过这种事情，就怕人偷懒。一偷懒，埋下运行时的雷。

2. 这个 common 库，在各个业务 repo 里是以 git tag 的形式进行版本依赖声明的。类似你说的 ”对应的 commit“。但是因为各种“时过境迁”的原因，大家不得不共用一个测试环境。测试环境的代码，经常是开发分支合并在一起的。还有很多细节没必要展开来说。 总之最终导致，这个 common 库的 git tag 不对，在测试环境未必会暴露出来。基建支撑不足的弊端就体现在这里了。现在只能用千叮咛万嘱咐的方式，告诉大家。改了 common ，第一时间去升级依赖。

后续把常量代码也迁移到 common 库后，这样的问题依然会发生。不过，总比现在会好一些。现在的维护心智负担更大。

@183shl 这个方案的阻力就在这里。

我们其实有一个 common 库，里面放了一堆 utils 、架构 base 之类的代码。之前的 leader 强调，这里面不允许放入任何业务逻辑相关的代码。所以以前常量也没放这里。

团队的人会觉得改这里面的代码，还要去升版本，很麻烦。

有时候就直接在业务 repo 里，也写个 xxx utils 。


我觉得你说的最后一句是有道理的，复用很强的再抽到 common 。这样就比较平衡。偶尔一两次的依赖，就直接抄一遍。依赖次数多了，再抽到 common 。很明显一定会被依赖很多次的，一开始就直接写 common 里。

@sampeng 几乎没有 code review 。

说得难听点，现在最好的 "code review" 就是测试 + 一上生产环境就挂掉。没埋雷，半夜爆炸就不错。

所以，我才想多引入一下非人工的花销来尽量保证稳定。比如：

1. type hint 。有点作用。
2. 写 DTO 而不是一个 dict 满天飞。不然回头维护的时候很慢热，记不住 key ，经常导致 KeyError 。也算有点作用。
3. 常量共享而不是用到就“手抄”一遍，这种手抄还会抄错。


不怕各位笑话。我们还有一个“运行时的常量共享方案”是这样的：每个服务提供一个接口返回本服务的一些常量定义，然后服务启动的时候，去请求一遍这些常量定义。 我感觉是很难用。运行时、纯动态，你写代码的时候，根本不知道自己引用的值存不存在。IDE 也无法给你补全。