其实,程序员可以不加班

2021-03-24 From 程序之心 By 丁仪

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

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

软件复杂度

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

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

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

团队合作

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

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

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

领域模型

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

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

自动化测试

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

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

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

本文来源:程序之心,转载请注明出处!

本文地址:https://chengxuzhixin.com/blog/article/200083.html

发表感想

© 2016 - 2022 chengxuzhixin.com All Rights Reserved.

浙ICP备2021034854号-1    浙公网安备 33011002016107号