负责的项目发布了一段时间，在这期间，发现了不少逻辑流程上欠考虑的地方。这个项目当初开发的时间比较紧，相对来说也不是部门核心业务，因此流程相对来说不是很正规。基本就是产品经理将交互图丢过来，几个重要的点文字标下，然后口头沟通下需求，就开始开发了。在发布后，陆陆续续发现了一些当初考虑不严谨的地方，因此希望能在新版本进行改正。在我看来，成熟有序的开发流程，某种程度上也代表着更加具有逻辑性的思考方式。最近查了些资料，也和前辈们沟通了下，现在来浅谈下心得。
明确需求
一个功能，如果能明确其输入是什么、输出是什么、在什么情况下期望发生的行为是什么，那么开发起来会清晰许多。产品经理给出的需求，并不一定就细致到足以支持开发。比如我在开发wifi相关的功能，产品经理可能只会说要一个wifi列表，点击列表中的wifi会开始连接，然后顶部展示wifi连接状态。那么如果wifi开关关闭了的表现应该是什么？wifi连接失败的表现是什么？可能这些细节都没有明确。如果在没有明确的情况下去进行开发，可能就是想到哪里写到哪里，想到哪个细节就处理哪个细节，对整体架构没有掌控，导致代码凌乱难以维护。更糟糕的是干脆遗漏细节，缺少对部分情况的处理，直接影响用户体验。我不太清楚是否这些是产品经理负责，但不管怎样，如果线上出了问题，作为开发肯定脱不了干系，所以还是自己要把握好。如果发现不明确的问题，可以再和产品讨论，把问题抛出来让他们去想解决方案，但不可以不考虑这些细节问题。
那么怎么细化需求呢？据说开发是要需求文档的，但我这个项目仅有简单的交互图。去查需求文档写法，发现也没有统一的标准，只要明确功能的形态即可。而咨询一些开发前辈，他们提议简单使用excel表格，将功能细分剥离，写明每个功能的行为，并且多想一些使用场景的case，明确在这些场景下功能的行为。因此我使用这个思路来细化我这个项目的需求。
细分功能
模块
划分功能的第一步是划分模块，而不是直接划分成最小的原子feature。这个一是分类清晰，二是为了之后考虑场景用例方便。事实上实践发现，很多用例是可以以模块为单位来考量的，可以在不遗漏case的情况下，尽量减少需要说明的内容。还是拿wifi列表的功能举例，页面上部是展示wifi状态的状态栏，下部是wifi列表，状态栏还有断开wifi等按钮，就是那种最普通的wifi连接界面。那么很明显的，上部状态栏和下部wifi列表可以分成两个模块，因为做的是完全不同的事。如果需要还可以继续划分子模块。依据就是场景、行为有一定的一致性的一些功能。feature
模块划分到最后，一些无法或无需再划分的功能，作为一个个feature存在。到了feature这步，就需要明确此功能非常具体的一些行为了。比如wifi连接栏中会展示当前wifi的ssid，这个功能可以明确为“展示当前处理的wifi的ssid，不可为空，不带有双引号，不可有<unknown ssid>、0x等非法ssid”。这样细化后，就很明确每个功能点究竟要做些什么了。举例
对于上述wifi列表的页面，细化后可能的样子如下：
使用场景
在每个功能定义清楚后，还需要考虑使用场景才能使得功能及逻辑严谨。这里的使用场景，其实类似于测试用例，但不需要那么详细。也就是考虑用户可能有哪些操作，进行这些操作后，期望我们的feature对其的响应是什么。只有全面考虑了使用场景，才不会致使在开发过程中遗漏某些情况，导致成为用户眼中的bug。举例如下：
这里，我直接在上述细分功能的表格后，直接写case，这样feature和case联系较紧密，比较直观。同时这样可以灵活地区分针对整个模块的case和需要区分feature的case。这边的使用场景的罗列基本就靠干想，当然也可以参考黑盒测试的一些方法，不过不用像写测试用例那样一步一步写的那么细，基本场景表达清楚即可。
了解相关技术
这一步和上一步，私以为其实很难分先后。如果没有明确的需求，怎么知道要去了解什么技术？但如果有些技术点不清楚，功能行为也很难定义。比如之前举例的，定义ssid的展示，包括“不带有双引号、不可有<unknown ssid>、0x”，如果不是在开发中发现系统提供的广播信息中会包含这些内容，行为定义也不可能说的这么明确。另一个例子，测试反馈表明，在部分机型上，必须要开启GPS才能获得wifi列表。对于这个情况，在大规模机型测试前也是不知道的，自然也没法明确对这种情况的处理。所以现实中，可能难免还要摸着石头过河。
但从理论上说，还是需要充分了解相关技术。所谓充分了解，并不是需求里说要有“连接wifi”功能，就去google下，然后复制搜出的代码，虽然对于新人以及在时间紧的情况下，可能很多人都是这么做的。这么做永远只是在使用二手货，搜出来的代码可能已经过时，或者并非最优。如果有时间，还是需要去看一手资料。像android开发，最主要的可能就是api文档。比如要确定网络是否真正可连，如果直接google搜索，那么搜出来的基本是使用ping的方法，但如果仔细阅读文档，会发现在6.0以后，是直接有api支持这个判断的。如果项目仅支持6.0以上，那么就可以直接调用api，写出即可靠又优雅的代码了（详见之前博文）。
相反，如果只是根据需求搜索技术，获得的可能是过时而片面的代码。因此感觉如果有时间，相关技术的一手资料要好好了解下。
其他重要步骤
今天先详细讲两方面比较有体会的部分的心得。以下是一些目前认为比较重要的，但还没实际操作的步骤。等之后涉及到了再细讲。
- 流程图
- 设计模式
- 提高效率的技术与库
- 单测
- 线上测试用例补充
