当时觉得大家做事的氛围和风格还可以，可是后来就逐渐发现，企业文化这东西真不是那么容易改变的，尤其对于这样一艘巨轮来说，逐渐 Oracle 的一些缓慢和笨重的老毛病就慢慢散播开来了。团队之间的扯皮越来越多，一年中的 code freeze 时间占比越来越大，org 中开始有越来越多的 program manager 专门催进度……我觉得自己做得不够果断的是，我确实看到了这些问题，却没有足够警醒和趁早行动（其实也是因为懒……）

– 四火的唠叨 《入职后一些零散的感受和思考》

我自己也一直在想，找工作如何判断团队或者公司有工程师文化，是否是个高效的值得加入的团队呢？

反向面试的时候，问一下，团队的上线发布流程是怎么样的，发布周期又是怎么样？code freeze大概都是什么时候？这都会是不错的问题。

  • 冗长的发布，开发工程师没有发布权限，基本上都是团队笨重的表现；
  • 总是有code freeze，团队的迭代效率不会高，而且大概也是系统稳定性差带来的后果。

而我，已经经历了两家公司，每周固定一个发布窗口，发布由QA操作。有稍大一些的活动就会 code freeze。原因大概都是：

  • 周期性发布：因为线上的问题通常都伴随着发布，周期发布可以减少发布次数，发布的次数少了，出问题的概率也就少了；
  • QA执行发布：开发和部署职能分离；确保QA在发布后可以执行线上的回归；
  • Code Freeze：和周期性发布原因类似，通过避免发布来避免可能引入的新问题；

个人认为，团队流程上，重点应该是更敏捷更高质量的发布，不是单纯通过增加流程来确保发布的安全。个人也赞同有 code freeze，但是反对有任何的活动，都提前很早就开始 freeze。