DOP（Delivery-Oriented Programing）面向交付的编程

前言

交付效率和质量保障是每个技术leader都要重点思考的问题。一直以来我都在思考通过什么样的方式作出改变，做架构的时候希望可以通过开发框架来解决，做技术leader的时候希望平台化的方式来提高，负责产品、技术、测试综合团队时候又有了新的思考。

技术团队的职责

作为技术团队，我认为有三层职责

1、满足业务快速创新

2、通过技术驱动业务的边界

3、通过技术手段形成商业壁垒

在有限的成本内，满足业务快速创新快速迭代是基本，只有做到第一点，才能有更多的精力做到第二、第三。

是什么影响了效率

归纳起来有四个主要原因

1、沟通效率的问题

2、范围共识的问题

3、代码腐化的问题，水面下的冰山

4、工作无法量化的问题

沟通重点应放在需求合理性的讨论上，而不是因为边界不清、职责不明引起的无意义的扯皮；研发重点应放在解决业务复杂度、技术方案设计上，而不是放在熟悉别人的代码在腐烂的代码中挣扎；应该思考在如何创造自动化工具提升效率，而不是低效重复的劳动。

一切从交付物出发

需求从提出到落地，需要判断业务的各种场景，需要有多种角色参加，经历项目的各个阶段，输出各种资料，是个复杂的过程。有没有一种方式让它变的更简单直接，这一切要从最终交付物出发。

我们交付的是什么？我们交付的是代码，当我们把代码规范了，让代码能够直接表达业务功能的时候，我们发现这些问题都有了答案。

DOP(Delivery-Oriented Programing)面向交付的编程

代码即需求。面向交付的编程倡导通过架构设计，规划代码、分析代码和相关数据，提升需求交付效率、改善质量。

什么样的系统是DOP系统

1、业务相关

代码可以明确表达业务需求与系统架构的关系，需求方和交付方可在同一个架构背景下沟通，提高沟通和交付效率；

2、交付可量化

代码和相关数据可被分析，通过大数据技术，能够量化交付需求，同时可以持续优化交付需求；

3、开发框架通用

开放框架通用，方便技术团队人员调配和协同，开发、测试把主要精力放在需求交付和技术方案上；

4、一杆子能力

团队中有更多的人具备整体架构思维，让相关角色能够快速评估需求改动范围和工作量，快速达成共识；

5、自动化工具

通过对数据的分析和处理，具备全链路的自动化的能力，包括不限于设计、交付和运维。

DOPF(Delivery-Oriented Programing)面向交付编程开发框架

一种面向交付编程的开发框架实现，通过代码的规约，让系统变得可分析、可量化、可优化；

• 系统划分成服务Se、模块M、功能St、步骤P，通过扩展功能和实现功能的步骤来实现需求；
• 大图就是由若干系统、模块、功能和功能步骤组成；
• 基于大图沟通，基于功能范围达成共识，通过功能点数量量化交付，通过框架规范防止代码腐化；

1、基本概念

• 架构（Architecture）：系统的组织架构，各系统在组织架构中的位置和关系；
• 框架（Framework）：开发规约，定义了系统开发的规范，包括代码的结构，分层等；
• 域（Area）：架构中系统的区域划分，有横向的垂直领域划分，也有横向的公共领域划分；
• 应用（APP）：一个应用，一个代码工程；
• 服务（Service）：系统对内部和外部统一提供的接口和实现，是系统能力的门面；
• 模块（Module）：即系统内部功能的划分范围；
• 功能（Story）：实现服务，通常情况下只负责组织功能实现，它是一个模版模式；
• 步骤（Plot）：实现功能的具体步骤；
• 管理器（Manager）：负责二方、三方服务调用的封装；

2、开发规约

• 调用链路：调用链路遵循Serviceç》Story》Plot》Manager的调用关系；
• 避免功能、步骤之间的交叉依赖，功能（Story）之间的调用须通过service调用完成，相同模块内相同参数的任务可以复用Plot，但要控制规模；
• 业务逻辑须在步骤（Plot）中实现，步骤（Plot）内要控制代码行数，保障代码的可读性，如果步骤代码过多要考虑进一步拆分步骤；
• 代码的目录结构有严格的规定，一级目录结构是系统纵向分层，module目录下实现系统所有的业务逻辑代码；
• 框架有对注释的开发约束，开发者要遵循基本注释的要求；
• 任何不符合框架约定的代码或结构，定义为异常代码；

代码结构的复杂度决定了开发和维护成本，规约明确规定了服务功能调用的线性层次关系，这大大降低了代码复杂度。

3、框架能力

• 灰度能力：软灰度，在服务层（Service）做灰度分流，控制多功能（Story）执行，可以按参数做流量分发控制；
• 动态编排能力：可以动态编排功能（Story）内部执行的步骤（Plot）；
• 自表达能力：可以自表达它在大图中的位置，它有什么，它做了什么；做的好不好；
• 被分析能力：系统产生的数据，包括静态的代码和动态的日志可被分析，通过数据分析可以发现问题，优化交付以及一些自动化的工作；
• 统一日志：代码按照服务、功能和步骤组织后，系统的日志统一成为可能，通常情况下开发者不需要额外打印日志。
• 自保护能力：系统之间有限流降级的能力，系统内部有资源隔离的能力；

DOPX 面向交付编程工具系统

遵循DOPF开发出的系统，标准化了代码、日志，即系统的静态数据和动态数据。通过对这些规范的数据的分析，我们构建工具，提升效率质量变得有更多的可能。

分析代码，我们可以生成系统大图、我们可以判断代码质量、可以评估交付的需求量；分析日志，我们可以提高运维效率，快速的发现、定位问题原因，直接到具体问题代码。

第一个工具，系统大图

系统大图，即系统架构图，他是由代码分析而来。通过系统大图我们能够全面了解系统组织架构，有哪些系统，系统中有哪些服务和功能，系统分解的是否合理，代码是否符合架构规范。

由于我们的架构是面向交付需求设计的，所以系统大图分析出来的是功能需求的描述，这样就让需求方和实施方能够基于这张大图沟通，提升沟通效率、方便达成共识。

系统有什么、是什么、做的好不好，不懂技术的人也能看明白。

 

第二个工具，运维管理

DOPX的运维工具是解决快速发现和定位问题，系统DOP改造之后统一了代码结构和日志，我们分析日志可以快速定位具体的问题代码。

摆在我们面前有两个问题需要解决，一是众多系统和服务该从何入手发现问题，二是如何在海量的日志里快速定位问题。

在这我们提出两个概念，即发端和发端指纹。

设想一下，是什么让系统运行、服务执行？

• 发端，功能或者服务发起的源头。只要是系统运作都会有发起方，可能是打开页面，可能是外部系统调用，也可能是任务调度，无论内部调用多么复杂，都有源头。服务可能有成百上千，但发端大概只有他的十分之一。
• 发端日志，发端发起调用，会经历多个系统，多个服务、多个功能和步骤，就像是发端的足迹一样，在每一个环节都会产生日志，把他们串起来就是发端链路日志，但是这个日志太过庞大。
• 发端指纹，发端日志的概要数据，涵盖发端日志的关键信息，包括节点顺序、节点状态、节点耗时等信息，这大大减少了日志分析的数据。通过对发端指纹分析和对比，就做到了快速发现问题和解决问题。由于我们的节点是到具体的实现类上，我们就可以轻松的发现问题代码。

有了发端、有了发端指纹，排查问题变得简单了。基于发端做监控报警，基于发端的指纹分析对比快速发现问题原因，减少故障损失。

第三个工具，交付管理（共识管理）

需求交付的过程其实是不断达成共识的过程，需求共识、设计共识、时间共识。一个团队是否高效，也是在于能否快速达成共识，执行落地。dopx的交付管理更多的是解决如何帮助团队成员快速达成共识的工具，或者不断的提高达成共识的能力的工具。

 

范围共识度，表示各参与方对需求的理解情况。理想情况是100%最好，这样效率最高，在有效得工作范围内，实现了交付。如果低于100%，就会存在需求遗漏或者过度交付的情况。

举例来说，测试和开发的共识度来说，如果低于100%就会存在测试覆盖不足或者测试范围大于改动范围的情况。但这些是理论情况，实际的项目中会有其它因素存在。有了DOP的支持，这种共识度的评估，变为了可能，我们可以通过分析代码来看最终的交付范围，同样可以反过来看交付过程中范围评估的是否合理，以及各角色对范围理解的好与坏。

交付管理主要做两件事

1、对各参与角色范围共识的训练，是不是以最小的工作量做到满足需求；

2、由于代码可以被分析成交付的功能点，我们可以做到对交付本身的量化；

第四个工具，自动化测试

有了规范的代码、规范的日志、统一了发端，我们实现自动化测试便是水道渠城的事情了。从发端入手，我们大大减少了测试的接口数量，对发端测试用例的覆盖，保障了对外提供服务的准确性。

测试代码同样基于DOPF开发框架，这样就做到通过分析测试代码来表达测试用例，通过分析代码可以评估测试工作量，测试范围。测试团从队手工测试转化为编程开发测试，通过自动化测试代码的沉淀，我们可以让测试工作更有效、更高效。

同样由于我们的日志是标准化的，我们可以通过录制日志来生成测试数据，同样可以根据日志判定测试的覆盖情况，代码、日志的标准化带来了许多的便利。

结尾

DOP核心是让代码、日志标准化，让代码直接表达业务需求和系统架构，这么做的好处是我们通过分析代码、日志可以做更多的工具，提高交付效率和质量，可以基于需求的场景来完成高效的沟通和需求交付。