如何做程序的需求分析和设计？

这篇文章以一个成员列表功能作为例子，很有启发意义，作者的思维过程和方法值得学习

分析的时候，我们要分析需求和难点。

分析需求的方法是做需求的陈述处理。要区分“做什么”和“怎么做”，把这两部分独立出来，“做什么是固定不变的”，而“怎么做”可能经常会变。举个例子，我们准备做一个成员列表（下图），产品经理告诉我们姓名拼音排序。

我们有时候不能完全听产品经理的，如果真按姓名拼音排序编码就没有可扩展性了。如果某一天产品经理说需要把VIP会员提前，那么你只能再去修改排序的程序。这个需求中始终不变的是排序，按姓名拼音只是排序的一种方法。我们在设计数据库的时候应该把排序字段设置为数字而不是拼音，再写一个拼音转换为数字的算法即可，这样来应对后面排序规则的变化。比如，VIP会员要提前，只要修改对应用户数据库的排序字段数值即可，不用大改程序。

我们可以用XMind作需求分析，先把看见和听见的需求一条一条地列出来。然后对每条需求进行分析，看看能否区分“做什么”和“怎么做”。如果能区分，在这条需求后面建两个分支，并把分析结果写上去，如下图：

需求过了一遍后，我们需要思考程序哪儿可能有难点，再把难点列到Xmind中。比如，成员列表这个功能，难点可能有：
1.如何把中文姓名转换为拼音
2.如何把拼音转换为数字

然后，我们再想想这两个难点的解决方案。我们在网上搜索，发现有中文转拼音的开源库，直接用这个库就行，把解决方案写在对应难点的后面。另外，我们还应该做一个简单的Dome，测试一下次此方案是否真的能解决难点。

程序员习惯用二元思维，往往认为不是“是”就是“非”，一个难点不能完美的解决，感觉就是不能解决，相反，我们要有优雅降级的思维。假设我们要做一个特殊的缓存功能，缓存到服务端是最完美的，但有难度，不好实现。这时候想想能不能优雅降级，不能缓存到服务端能否缓存到客户端；缓存到客户端的方案并不完美，比如用户可能会手动清空缓存，但是有缓存总比没有好，那么我们能不能做呢？

我们再分析刚才的第二个难点，拼音转换为数字的算法，我们可能定义a转换为1，b转换为2，c转换为3.但有一个问题，我们对人名的第一个字排序了，要不要对第二个字排序？比如“张三”和“张飞”两个人名，第一个字“张”的拼音首字母都是Z，我们还需要对“三”和“飞”转换为拼音排序吗？要做完美的解决方案的话，是要对第二个字排序的，那么怎么排序？假设我们在这里卡住了，暂时想不到好的解决方案，很多人会觉得这个功能做不了、不能做饿了，我们能不能优雅降级一下，先对第一个字排序，以后想到其他解决方案再完善呢？

设计这一步，要体现程序怎么写，我们要设计出数据库的表结构、API接口以及前端页面等。设计也可以在Xmind中完成：

设计这部分一定要体现程序如何开发，不能还是列举需求，要说明建立什么程序文件、建立什么类，以及类有哪些方法，方法的具体处理过程。在XMind中我们经常会用这些断句：“当XXX条件成立时做XXX”“调用XXX方法”。

XMind在列出这些“处理过程”时就能发现很多重复的逻辑，我们应该把这些重复的逻辑独立成模块（封装为类或含函数）。对于这些要封装的模块，我们在列XMind的时候就要想好，而不是编写代码边想，这样会不断推翻以前的代码重写，浪费时间。

在设计类的时候注意“正交设计、类要有专职、委托优于继承”。类方法的处理过程要详细，在实际写代码的时候照着XMind实现代码即可，那个时候就不用想程序的逻辑了。

对于新手来说，写代码之前把所有细节都想到是有难度的，他们要边写边想，写到具体的地方才知道有什么细节。但这样的习惯很不好，写着写着代码逻辑就会变乱。程序员一定要养成写之前先想清楚的习惯。从现在开始我们慢慢养成写代码之前列XMind做分析和设计的习惯，写完代码后再对比之前列的XMind看看哪些是之前没有想到的，慢慢积累经验，时间长了分析和设计会做的越来越好。

我们在XMind中设计好有哪些接口和模块还有利于团队的沟通和工作的分工，评估每个模块的开发时间。因为XMind列的比较细，每个模块的时间往往能以分钟或小时来估计，如果有些模块还必须以天为单位估算时间的话，那证明这个模块还能再细化。

《内外兼修——程序员的成长之路》读书笔记