kdd0063

这无非是技术人带点戏谑性质的玩笑罢了，真裁员都是按着指标人数无差别进行，他们就是知道再招一堆人需要啃半年这坨代码和文档也一样不会影响裁你的决定

无状态应用那点复杂性当然无所谓。但是有状态应用，同时又存在比较高的一致性需求的时候，搞出问题就很吓人了，有时连回滚的可能都没有，因为找不到一所有相关方都认同的一致状态。
这个问题上研究了少说有几十年了，有银弹大家早用了，难不成谁当真喜欢熬夜顶着黑眼圈和发翁的脑袋上线？ No silver bullet!

祝愿这个狗 b 产品早死早超生

难道生产环境敢直接 k8s 升大版本？这未免也太心大了。好歹搞个灰度环境用金丝雀策略试试水吧

- 怼天怼地，觉得不懂技术的都是傻叉
- 无法理解和接受绝大部分技术是绕着业务转的
- 觉得自己是单纯因为技术好所以被付钱
- 看不起貌似简单的技术产品也能挣钱，从来不会去分析背后的商务和人性需求
- 除了技术的一亩三分地一概不关心，导致很难从挖掘，分析，售前，技术实现到售后理解一个完整的商业运作链条

@rhoasneg 这种 code ，除非是不这么写服务性能直接下降一个量级才能容忍，而且起码必须有详尽的注释，这些条件都不符合可以直接毙了

这看你从什么角度看问题了。如果从 tech lead 的角度来看，项目代码的风格统一，可读性与可维护性是第一位的，很多时候甚至比性能收益更重要。这段 PR 带来了更差的可读性，可维护性，因为数据量很小所以根本不会体现多么高的性能收益，几乎属于纯粹的炫技行为，这几个点一叠加，必定是要打回重改的。

- 名校很了不起？这行当最不缺名校的
- OI 的很多风格用到工程里就是 shit
- 你那么多次无效 if 怎么来的自信？
- 你就是 CMU 科班的，团队有编码规范一样要遵循