这篇文章以一个成员列表功能作为例子,很有启发意义,作者的思维过程和方法值得学习。分析需求的方法是做需求的陈述处理。要区分“做什么”和“怎么做”,把这两部分独立出来,“做什么是固定不变的”,而“怎么做”可能经常会变。举个例子,我们准备做一个成员列表(下图),产品经理告诉我们姓名拼音排序…

正文如下

分析

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

分析需求的方法是做需求的陈述处理。要区分“做什么”和“怎么做”,把这两部分独立出来,“做什么是固定不变的”,而“怎么做”可能经常会变。举个例子,我们准备做一个成员列表(下图),产品经理告诉我们姓名拼音排序。
图片描述
我们有时候不能完全听产品经理的,如果真按姓名拼音排序编码就没有可扩展性了。如果某一天产品经理说需要把 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 列的比较细,每个模块的时间往往能以分钟或小时来估计,如果有些模块还必须以天为单位估算时间的话,那证明这个模块还能再细化。


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

++++++++++20 元出售此书++++++++++
[

图片描述][4]
图片描述][4]