一个需求的反思
上一篇博文写到了要编写适合测试的代码，后来几天又深入地思考，重新梳理下一些不清晰的概念点。
产品提出的需求是什么
在实际的工作中，一般来说，产品在召开需求评审会时，会邀请开发来参与评审，如果开发人数很多，往往只会邀请开发经理来参与评审，参与评审完后，由开发经理来分解模块，分配给相关的开发人员。这从产品需求到真正开发人员中间多了一道，会有需求信息传递的损失，这是不可避免的。
产品在需求规格说明书上面进行的需求描述，是从产品的视角出发，通常专注于正常的业务流程，描述方式是从正常的用户视角在正常环境下执行一趟业务流程，很有可能没考虑错误情况和异常情况。如果涉及到的业务流程较为复杂，会附加上 程序流程图 来帮助梳理理解，这没问题。
小结：产品提出的需求是从正常运行的业务角度、用户角度来提出需求。
在召开需求评审会时，要求开发经理和具体开发人员一起来参与，这样可以减少信息传递中的损失，提高沟通效率。
开发开发的需求是什么
个人看法，程序员在开发的需求包含了产品提出来的需求，其范围比产品提出来的需求要大。如果是不会思考的开发，只会一板一眼的按照产品提出的需求来做，那最后很有可能把自己给绕到坑里面去。对于业务逻辑的 走向，谁有最全面的视角和理解能力呢？我觉的，应该是一个追求卓越的开发。产品和测试都是从黑盒子的角度来看待程序运行，只有开发知道业务的每一步做了什么，它的下一步做了什么，最终表现的又是什么。
产品对于异常和错误的处理，往往没想那么细，而开发实际上大部分在和错误和异常打交道，这个地方，个人觉得借用Unix文化中的“提供机制而不是策略”这个角度来进行界定。产品人员需要提供业务流程正常或异常的机制，具体实现的策略由开发来决定，如果产品有相关的思考，可一起纳入思考，如果没有，则开发决定后将错误异常处理反馈给产品即可。
因此，程序员开发的需求，可以具体分为以下两点：
-
经过具体开发人员过滤后的产品需求。具体开发人员在动手设计前，需要在心中走一片产品需求，发现有哪些不妥的地方，要及时和产品反馈，从专业的角度给出修改意见，反复沟通数次，才完成过滤业务需求的这个步骤，这是在进行具体方案设计前必须做的，具体方案针对的一定要是经过过滤后的需求，而不能是原始的裸需求。
-
非业务需求：
2.1 复用性：当需要特定功能来实现需求时，一定要查看当前工程中是否已有提供相关的工具类以及现有框架中业务流程。如果已有工具类，那就不要自己再造轮子。如果现有框架中已有通用的业务流程处理，而自己的需求是在通用的基础上，增加自己独特的部分，一般情况下，有三种处理方法：- 自己的业务类重载基类通用处理虚函数，先调用基类通用处理流程，再进行特有业务的处理。
- 在基类通用处理中加上一个虚函数钩子，默认实现为空，在派生类中的虚函数中实现特有业务处理。
- 如果基类在通用流程处理完有对外发通知的动作，那么派生类可以订阅该通知，在相应的响应中做处理。
上述三种方式，推荐第三种方式，通过消息来解耦合。
2.2 内聚性以及可维护性
新功能的添加，要以不修改、不影响原有功能为前提条件（如果一定要修改，则要和上级一起来评估影响），在此前提条件下，相关类似的操作，一定要放到同一个地方聚合起来，不要处理正确情况的代码在A除，处理错误情况的代码在B处，这样不利于后期维护。
2.3 可读性
团队作战，每个人都会遇到不好的代码，或者是别人写的，或者是以前自己写的。在添加新功能时，如果是新建文件，那么一定要按照团队最高标准来写，如果是在已有文件上修改，那么只需修改与本次任务紧密相关的代码可读性，不要想着来个大招。借着新需求或者改Bug的机会，小步慢跑地来重构。如果在此过程中，发现别人写的不好的地方，可以将相关的修改以patch的方式通知他人，而不是擅自修改。
2.4 性能
在一些重试场景下，要注意新增功能对系统整体性能的影响，不能因为新增功能的加入，给整个系统埋下了潜在的性能异常点。这里举以 “关联账号登陆重试” 例子介绍下：
应用背景：A账号登陆成功后，底层会发起其关联账号A1的登陆操作，A1登陆状态决定A账号中某个子模块的可用性。在生产环境上发现，关联账号有一定几率会登陆失败，会影响子模块可用性。需求方提出：当A1账号登陆失败时，发起重试登陆，直到登陆成功。
开发分析：登陆失败的原因有多种，比如超时，后台不稳定，后台处于不可用状态等等，如果是因为非超时而重试，从业务稳定性上来分析，会给已处于不正常的后台增加增大的负担。
最终流程：
登陆过程本身有一个定时器来界定超时，当登陆超时发生，立即重发登陆请求。
如果是登陆失败，则不再重试。
测试测试的需求是什么
经过前面的分析后，那么可以得知，开发实现的是两方面的需求：
- 经过开发过滤的业务需求
- 开发具体实现的流程
对于第一种测试，测试人员可以根据产品提供的需求文件来提前编写一些测试案例，然后在测试阶段，按照案例来进行测试。
对于第二种测试，开发只有开发完成后，才能明确可测试点，需要对外提供该业务的业务流程图，并标注一些可供测试的锚点。给出的锚点不会覆盖所有的业务流程点，对于那些测试无法覆盖的点，开发要自己保证这些中间状态的流程正确性。
