其实，程序员可以不加班

技术团队存在的主要价值，就是支持业务的发展。业务发展越快，对技术迭代的效率要求越高，这也是互联网这个行业经常加班的主要原因。

既要、又要、还要，是业务需求的常态，是工作量翻几倍的罪魁祸首。软件复杂度是天然存在的，同时团队合作也决定了项目能否按期上线。好的领域模型设计和自动化测试能够有效降低开发成本，提升软件质量和稳定性。

软件复杂度

一般认为软件 = 控制逻辑 + 数据结构 + 业务逻辑，其中业务逻辑变化较快，控制逻辑变化较慢。软件的复杂度也由控制复杂度、数据复杂度、业务复杂度几个方面及其相互关联而决定。从系统化视角去看，只有边界清晰的模块划分才能长期高效维护，而在实际执行中，由于开发能力良莠不齐、信息传递不到位，蜘蛛网一样的代码普遍存在于各个系统中。

业界普遍的做法是对控制逻辑和数据结构进行抽象剥离，得到清晰的流程和数据模型，从而形成领域内统一的业务框架。而业务逻辑在此框架之上可以实现复用和隔离，大大提升开发效率和理解效率。从业务逻辑中剥离出控制逻辑并不是一件容易的事情，要求开发者既要懂业务，更要懂架构设计，还要注意防腐。

即便已经进行了很好的分层和隔离，还是会有人打破规则。如果是由于需求看起来变态，需要考虑下需求合理性和架构设计的兼容性；如果是开发者图方便或者忽视规则，需要搞清楚是能力问题还是态度问题，对症治疗；如果是需求已经超越了架构的边界，则需要进行重构演进。

团队合作

一个项目需求往往涉及多个方面，有不同的端和领域，各自有不同的人维护多个模块，甚至会涉及跨团队合作。比如后端可能 0.5 人日的改动，受到前端排期影响可能要一周后才能上线。这就导致不同技能、不同模块的开发人员存在互斥锁，团队合作就像多线程一样互相锁，甚至死锁。而且大家的屁股不一样，想要的利益也不一样，有时候甚至出现推诿和利益斗争。

对于小公司来说，一个人掌握多项技能成为全栈工程师可能是比较好的选择。而大公司派系林立，模块划分比较细致，一个人就是一个螺丝钉，让你钉哪就得钉哪。因此开会拉通，对焦排期进度，就成为了项目管理的重要手段，内卷也就自然诞生。

对于平台型团队，需要考虑平台和业务的隔离，控制住一个项目或需求的影响范围。一方面可以降低开发成本，使需求能够快速上线；另一方面，可以在资源短缺时引入外部开发力量，由需求方或外包团队进行开发。这就要求架构能有良好的分层和隔离，把变更的影响范围控制到一个局部的场景，虽然难以实现，但很有必要好好琢磨。

领域模型

正常来说，对需求的理解是随着开发的演进而逐步加深的。在需求开始阶段，各方对需求的理解一般都不深，要经历一段时间的代码开发才会发现思维盲点。到了开发中期才会遇到业务或框架的冲突或约束，直到开发结束上线才能看到需求的全貌。所以前期的调研和分析很重要，但是也很难做到完美。

为了统一大家的理解，可以在架构设计中应用领域驱动设计思想（参考《走向卓越，领域驱动设计的思维方式》）。在领域驱动设计中，推荐六边形架构来强化领域模型的重要地位。让外界系统服务于领域模型，实现领域内部的确定性。领域内部关注如何通过模型及其相关概念，在抽象的层次上把业务表达出来。

自动化测试

凡是重复的事情，基本都可以通过软件自动化实现。接口最简单，给定入参，mock 好对外调用的结果，对执行结果进行比对，很容易看到变更导致的差异，自动化程度比较高。web 页面现在也有手段可以自动化操作，通过脚本触发按钮、输入框的变化，进行页面跳转，自动化的可能性还是有的。

自动化测试可以成为软件开发的常态，甚至每一次 Git 提交都可以单独触发一次自动编译和自动化测试。基于采集和 mock 的线上流量回放可以通过大量录制真实流量而提升场景覆盖率，解决人工测试场景覆盖不全和耗时过长问题。但是自动化测试也存在一些问题，比如比对结果可能受运行环境的影响、部分外部调用无法 mock 影响运行结果。

整体来看，自动化测试在接入起步阶段比较麻烦，编写调试测试用例、回放线上流量比较繁琐，但是构建好投入使用后带来的测试成果还是比较显著的，能够快速发现 NPE、逻辑错误、包冲突等问题，极大降低了变更风险。自动化测试，尤其是线上流量回放，在日常回归、架构升级和重构中已经扮演着越来越重要的角色。