浅谈软件研发的复杂性与应对之道
大概在五六年前,有一次我在Google美国总部参加一次技术交流,有一个演讲让我印象深刻,让我至今一直记忆犹新的不是其演讲内容,而是演讲开始的第一页PPT:“别人眼中的Google VS Google人眼中的Google”。我们对Google的软件工程能力可以说是趋之若鹜的,但是Googler对自己的评价确是如此的中肯和朴实。
从『农业时代』向『工业时代』进化
研发效能的现状与挑战
软件研发的复杂性困局
复杂性的来源
本质复杂性:对应的是软件产品的能力提升,是理想情况下的复杂性下限。
随机复杂性:往往带来影响深远的危害,是复杂性中可管控、可优化的的部分。具体包括:
短视效应,急功近利、快糙猛地完成交付,留下隐患 认知负荷,知识未沉淀,学习理解成本高 协同随机性,更多点对点的、准确性难以保障的沟通与协同
以架构腐化为例
架构解耦度(decoupling level)度量的是软件系统在多大程度可以被拆分为独立、可替换模块。
不稳定接口(unstable interface)度量的是接口共同修改的关联度,识别影响范围过广的架构热点。
随机复杂性与效能的关系
双流模型
什么是双流模型?
-
需求价值流
需求状态的流转过程,主要关注者是项目经理、产品经理等角色
-
研发工程流
软件研发流程中的具体操作和阶段性工作产品,主要关注者是开发工程师、测试工程师、运维工程师等角色。
简而言之,双流模型就是将需求价值流与研发工程流关联起来。
双流模型的价值
提升工程师体验 + 降低随机复杂性
当工程师认领开发任务时,不需要离开 IDE 界面通过插件即可领取任务,平台自动完成需求状态流转、分支创建、代码拉取等工作;
工程师开发完成并完成本地测试后,提交代码合并请求,平台触发 CI 流水线,自动完成静态代码检查、质量门禁检查、质量测试等等,并更新需求状态。
不同阶段的效能提升实践
需求阶段
Must-to-have:基本需求,质量如果不达标用户会立刻离开,例如手机的通话功能;这一类型的需求往往需要优先排期
Excited-to-have:实现这类功能的时候满意度增长很快,容易引发口碑传播;可从这一类型中选择成本较低或技术壁垒较高的需求
-
Reverse:尽管从模型来看,这一类型需求是最不理想的,但实际上往往是产品的盈利点,例如信息流广告;针对这类需求,需要结合业务阶段判断优先级
个人本地开发和测试阶段
高效获取开发环境
IDE 精准代码提示
精准代码填充
单元测试的自动生成
轻量级的Mock工具
更多的实践
推荐阅读