作者 | 张海英
来源 | 阿里开发者公众号
研发过程中，开发同学在接到一个需求后，必须要回答两个问题：做什么（WHAT）、怎么做（HOW）。本文就开发与测试在拆解需求时面临的共性问题，结合自己过往的经验，总结的一个实用的方法。本文不讨论技术选型，仅从思考逻辑上总结应该如何拆解与实现一个给定的需求。欢迎讨论。
理解需求拆解的关注点
以带UI的需求为示例，来看拆解需求过程中的关注点。看下图，停留20秒，思考两个问题：（1）从无到有实现以下需求对应的功能页面，需要做什么？（2）以下页面中只修改指定区域的元素，又需要做什么？
上文两个问题代表两种需求类型：第一个问题对应新功能的实现，第二个问题对应已有功能的修改与维护。无论是新功能，还是历史功能，都需要关注如下点：
将上文提及的关注点进行抽象与分层后，会得到如下一张图：
抽象后的架构层次图可以帮助我们理解实现的层次划分与结构设计。但是，一般来说，抽象意味着抹平细节。对于一个新手开发或者新手测试来说，需求实现或者测试过程，不仅要关注抽象层面的架构设计，更需要关注实现过程中的细节。接下来对于上文提及到的关注点，下文会展开说明。（在一个多角色的团队中，实现一个需求，不仅有自己，还有其他角色的开发、测试、PD、运营、数据等，理解关注细节才能保障交付质量）。
通过关注点看实现需求要做些什么关注点1：需要多少UI
要绘制多少UI组件、要增加多少UI页面，首先取决于“需求文档（PRD）”、“视觉交互设计稿”。对于开发来说，请重视需求评审、视觉交互评审。对于质量良好的需求文档或者视觉设计稿，文档中给出的UI组件/页面范围一般就是开发要实现的UI范围；对于质量差的需求甚至是一句话的需求，UI范围则需要研发“梳理确定”。无论需求文档或视觉设计稿质量如何，研发人员在需求评审、视觉交互评审、技术设计、编码实现过程中都需重点关注“异常逻辑”。什么是异常逻辑？比如，一个查询类的需求，“查询结果为空”“查询时无网络”这类场景就属于“异常逻辑”。很多时候，新手容易出问题或者遗漏的地方就是异常逻辑的处理与显示。
需求拆解阶段，关注UI如何实现的同时，也请务必关注UI的展示对象，包括：图片与多媒体内容（CDN图片、OSS图片文件、base64编码后的图片）、文案（文案的长度、多语言翻译的来源）、RTL（Right to Left）适配。已一个支持17种语言甚至是更多语言的海外APP开发为示例，这些内容虽不影响开发进度，但是会影响需求在交付时的质量、或者是到了需求实现后期补作业。
实操方法：需求拆解的时，对于UI范围，可以拆解出如下内容用于辅助后续研发实现：
UI范围：功能页面范围、页面状态及状态的变化逻辑、界面的异常逻辑态等等页面元素的拆解：列表元素、卡片元素、动画元素、UI特效等（这个也是沉淀通用组件的依据）UI展示的对象：文案的范围、多语言翻译的来源、RTL适配的范围、图片、短视频等。关注点2：数据从哪里来？这里的数据是包括用户直接感知的数据与富媒体内容流，也包括用户不感知但是用于支撑功能的研发类型的数据。数据的来源包括：网络数据、本地存储的数据、内存数据。不同的数据类型，需求实现的处理有差异，例如：
网络数据：需求拆解时候重点关注接口文档、接口名称、接口返回的数据字段（包括字段类型、范围、字段名称等等）、接口对应的团队或具体的开发、接口的上下游链路（示例：搜索的接口会涉及广告、算法等）、接口测试与联调方式等。对于新手，需求拆解的时候还需要确认：数据网关类型（MTOP网关、Node编排后的数据、Web网站对应的数据网关等），明确网络数据调度所用的域名（比如，部分APP交易功能的域名与非交易功能的域名是分开的，调度方式也会有差异）。本地存储数据：需求拆解阶段，要明确本地存储数据还是自己负责还是使用他人的能力。如果是自己负责则需要进一步判断数据是写本地数据库，还是写本地文件；如果是他人负责，数据的读写方式与接口是什么。内存数据：需求拆解重点关注内存数据的读写方式，数据使用后的释放方式。富媒体内容流：图片、短视频、直播等多媒体流。需求拆解时关注这些内容存储的形式（以图片为示例：图片是CDN的URL，还是OSS的文件地址或者ID，甚至是base64处理后的编码结果）；同时还需要判断这些展示能力是已有的还是需要新引入等。总结来说，“数据从哪里来”很好记忆，但是，在真实的研发过程中，“数据从哪里来”往往是研发过程中最容易出问题的地方。以网络数据为例，典型的问题有：联调环境不稳定、接口返回的字段未遵守约定、接口上下游数据链路不通导致无法测试等。即使需求完成并且交付上线，也还是会有各类问题，比如：引入了新CDN导致现有的图片/短视频加载过程的优化策略不支持，导致线上反馈性能或者是稳定性问题等。
对于“数据从哪里来”，在拆解需求的时候，一定要关注到每一个字段。这么强调，既因为这个点既影响实际投入工作量，还特别影响交付的需求的可用性与质量。
实操方法：进行需求拆解的时候，围绕数据从哪里来，可以拆解出以下内容：
数据逻辑的分层结构图（根据实际需要）功能与数据接口的对照关系、接口文档、接口的承接平台、接口的Mock方式等功能的数据流转与逻辑流程图关注点3：数据与UI如何关联？“数据要到哪里去，怎么去”，也可以理解为数据绑定。对于有一定复杂度的需求，“数据与UI如何关联”很大程度上会决定这个功能的实现与维护难易。需求拆解的时候，无论是选择MVC、MVP、还是MVVM，数据绑定这个过程比较考验开发人员的设计能力。我个人将数据绑定总结为如下几种
单向数据绑定：数据变化自动驱动UI刷新，代码实现会体现为各种Observer或者Observable等。双向数据绑定：数据改变的同时使视图刷新，而视图改变也可以同时改变数据。无所谓数据绑定，数据关联到UI是过程式的编程，体现为：加载数据、加载成功手工代码上屏等。当然，以上总结是简化后的总结。对于新功能，建议需求拆解的时候，反复理解所需的数据源、充分理解UI范围，结合控制逻辑，仔细提取关键特征后，充分设计后再进行编码等操作。设计的时候多借鉴团队内或行业内的最佳实践。
对于维护类型的需求，特别是有浓重祖传特质的功能（比如2013年功能迭代至2022年的需求），则要花点时间理解原有的关联关系，这个很有可能是一个不大不小的难点。比如，有的历史功能在实现的时候，数据与UI的关系是通过EventBus/消息广播类的事件触发；还有的功能数据在独立进程加载，加载完成后通过进程间通信再通过事件通知机制绑定数据到UI。总结来说，部分历史功能在最开始的实现，会用到各种酷爽的方案，但是到了后期维护，这类酷爽方法则会以一种超长技术链路或者拗口的技术链路呈现给维护者，变成一座需要咬牙才能翻阅的“山”。本质上来说，编码不是人与机器的交流，而是人与人之间通过写作的交流。对于一个维护性质的功能，掌握原有关系的一种方式就是植入各种测试性的代码辅助自己理解。
实操方法：拆解时，数据与UI关联，可拆解出的内容（数据与UI的关联，建议将“克制”作为自己的原则）：
功能的数据流转与逻辑流程图代码设计、数据关系流转设计等等数据状态变化、UI刷新时机等关联所用的绑定能力、数据变化后的通知机制等关注点4：用户行为响应相对于上文提及的三个点，这一点相对容易。对于带UI的需求，按照如下范围拆解与实现即可：
归纳需求文档或设计文档中的用户行动点，包括：点击、上下滑动、左右滑动、长按、开锁屏、虚实键盘响应、缩放手势等等。行动点的常见处理：页面跳转、tips/toast/弹窗等展示、动画处理、界面缩放、界面关闭等需约定的接口或规范：页面跳转的schema/传参、二三方能力唤起的方式等点击查看原文，获取更多福利！
https://developer.aliyun.com/article/1009743?utm_content=g_1000368765
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
