目录
1.第一步：整理需求，理解需求，辨别需求（简单用流程图画出你的基础流程（这段考虑系统外的输入输出，正常流））
2.第二步：考虑每个相关联的 名词的逻辑联系，画图类图，以及他们的状态图。
3.第三步：考虑用什么方案去实现，自己要想一个，但baidu和google也要想多1~2个，一个方案容易卡很多时间，因为你把所有的鸡蛋都放在一个篮子里，如果送过去目的地的人是小偷，那你就全军覆没了。
4.第三步：画方案的流程图，如何到达结果（对编程有一个指导作用）
5.第四步：考虑每个方案性能（多少个循环），可扩展性（是否可以套用设计模式），兼容性（是否有旧版本的代码需要处理），安全性，经济性，简单。 当然这些都是要时间限制来进行评估的
6.第五步：想好了这些，编码可以开始编码了。
实例
1.转账功能
1整理需求，理解需求，辨别需求（画活动图）
注意，活动图的每一个长方形都是写为用户可能的操作。这里只不过是一个实例，你也可以有自己的操作
image.png
题外话：为什么要先把系统操作制空？因为这时候还处于需求阶段，我们假定功能已经实现
其实也用了简单的测试驱动的思想。假设他已经实现了，我们要想如何测试他。
我们现在开始从测试的角度出发去思考。首先测试肯定要考虑的是异常流（用户会如何错误的操作），
再考虑正常流（客户如何正确的操作才会成功）
首先我们必须有一个思想前提是，系统的编码实现是我们程序员编码实现的，而我们程序员
经常老是想到了“转账成功”这一部分就开始编码，这可能就造成了BUG连连
这时候可能在系统的流程图那里会产生N步操作
什么生成表单，请求第三方支付系统接口，第三方接口返回，然后返回编码进行过滤处理...
这时候就可能考虑少了转账用户错误（输入了溢出范围的数字/溢出类型范围的数字，不填
表单），转账系统错误（遗漏了处理）
但要对用户界面友好（这些系统编写校验代码处理，并在前端上返回友好的报错提醒）
也少考虑了恶意用户，他们频繁请求，或者通过接口请求一些溢出的数字/错误的类型（通过
权限/操作日志去过滤）
最后还要考虑是否只有这个入口才能通到系统？如果冻结的用户想要转账，是否不行，这时候
就要考虑是否有状态图
第二步：搜索名词，找出联系，画出状态图
涉及到的名词有 用户，金额，转出方。
开始设想他们有什么状态了。
用户可能是冻结用户，正常用户，删除用户
金额可能是溢出的金额，正常的金额（正整数），负数金额
转出方非法（地址不合规，是否被中途篡改等）
用户类图
image.png
找出这图里的联系
用户与用户在转账之间的关系是？
一对一，一对多？多对多？多对一？
这个步骤是考虑到他们的 （转账）或所有的操作得如何设计。相当重要
为了简单，我们现在只考虑单笔转账
用户的状态图，用来补充类图是否有思考的遗漏
image.png
第三步：尝试转账操作的画时序图（也是为了补充类图）这时候注意你处于
image.png
最右边的系统级别那里，开始填充吧
image.png
然后不停的问几个问题（所以最好用草稿纸来画，再最终用电脑画）
1.看着图能实现代码吗？
2.图里有没有解决上面提及的问题
3.有没有正确的返回对应的对象
具体实现方案
请求的限流由tomcat限制
checkUser将要解决是否是冻结用户的问题
checkRequestValidate 将要解决防止偷换报文的问题
validateParam 将要解决 数字溢出
chckUserRestEngouh 将要解决 用户余额书否满足的问题
checkPayCode 将要解决将用户的支付密码提取下来进行校验的问题
等
这时候这些操作的流程图也要画好
这时候这些操作的流程图也要画好。为什么要画好流程图，注意，你要准备编写代码实现了，你得有具体的实现逻辑，不要边写边想。边写边想很容易考虑到最简单的方案，而不一定是最好的。
注意，流程图我建议要用英文画。
为什么不用中文？个人觉的中文博大精深，容易出现
image.png
然后去找其中你觉的模糊实现的方法
例如 如何解密这个userId等 百度搜几个方案
一步一步来。
5.第四步：考虑每个方案性能（多少个循环），可扩展性（是否可以套用设计模式），兼容性（是否有旧版本的代码需要处理），安全性，经济性，简单。 当然这些都是要时间限制来进行评估的
这里也是我的知识盲区，所以暂时不考虑展开
6.第五步：想好了这些，编码可以开始编码了。
网友评论