三个指标, 使得开发人员迈向 "完美" 的圣殿

2017.9.17, 深圳, Ken Fang

我们搞软件开发的, 应该要有些 “指标” 来驱使着我们自己能不断的持续改进；永远的朝着 “完美” 的圣殿前进⋯

@ 平均需编写多少行的代码, 才能完成一个特性或服务的开发？ @ 平均需花费多少的时间, 才能修复一个缺陷或运维事故？ @ 外部用户平均需花费多少的时间, 才能感受或认同代码的价值？

我想, 有追求的开发的人员, 都会在每个季度、每个年终, 用这三个指标来 “度量” 自己；驱动着自己, 深度的思考着：

@ 用函数式编程, 使得代码由 “调用的结构” 转换为 “堆叠的结构” , 是否会更好？怎么做会更好？平均开发完一个特性的代码行数, 会不会更少？怎么做会更少？代码更简洁了, 但又能同时使代码, 更具有可读性？

@ 用 Cloud Native 的架构, 使得产品的架构由 “单一”、 “中央集权”, 转换为 “分布式” 、“地方分权”，怎么做会更好？关键技术 : 分布式事件的处理, 该怎么做, 才能使得每个服务的 “边界” 是有价值, 有意义的？使得每个服务不仅能 “持续” 的提供价值, 却又能 “不会” 影响到其他服务的运作？更重要的是：使得每个服务有 “自愈” 的能力；使得产品的运维的事故, 真的可用 “罕见” 来形容, 使得运维事故修复的时间, 真的可用 “极短” 来形容。

@ 用团队恊作, 将 “使用者体验” 在需求分析、软件设计时, 便已融入到软件开发的思维当中；该如何做, 使得用户能在 “最少的交互” 下, 就能完成工作? 该如何做, 才能使得外部的开发人员, 在调用 “最少” 的 API 、关注 “最少” 的 API 参数下, 就能完成开发？

当我们能运用了有效的度量指标, 我们才能真正的明白, 为何需在: @ 编程语言 @ 编程方式 @ 软件架构 @ 团队协作上, 持续改善？

“能持续改善的开发人员、有追求的开发人员, 是值得被尊重的, 是值得被珍惜的。”