上一篇文章简述了我的日常需求分析方法，需求分析完成之后就进入系统设计阶段，真正的工时估算和开发测试计划，都是在做了一定的系统设计之后才能做好的。
不想做工时估算和做到哪里是哪里，是一个态度问题。工时估算困难，估算不准确，从而导致每次开发测试发布计划形同虚设，是一个技术活问题。
系统设计做得太详细，就太费时，在今天高举敏捷开发的时代，开发人员都是不做具体系统设计就开工的，所谓快速迭代和快速试错。但是，实际上我们看到的是，遍地都是越来越难以掌控和理解的系统平台，特别在加入几个没经验的新手之后，原则性错误都能频频出现，事实说明全盘抛弃系统设计而直接做到哪里是哪里，是不可取的，返工修复Bug和返工修改流程，是最浪费时间的，总体上耗费时间加起来哪里是敏捷开发，这不是我想要的。
这么多年来，只要参与开发，我从没丢掉用UML来做需求分析和系统设计，即使主管不要求，我也要自己快速用UML设计一个来理清楚自己的思路，然后去写代码，同时，在写代码过程中，不断伴随修改UML设计图，尽量保持设计和实现同步。
UML2.0共有13种图，不是每次系统设计都要全部用上的，根据80/20原则我们使用一部分图来设计系统就足够了，能让我们把需求分解成一个个具体任务，非常容易做具体任务的工时估算就可以了，一般也足够支持我们做具体的编码实现了。
1. 系统设计的工具与方法
在系统设计过程中，一般用到哪些工具和土办法呢，如上图：
- DDD: 领域驱动设计，虽然它的一些命名和方法让人难受，但是它高度关注业务领域的思想是很优秀的，从业务功能去思考系统设计，而不是从技术实现角度去思考系统设计，是我最看重和最常用的，至于其它并不重要。
- UML: 统一建模语言，那是必须用的，我不喜欢用什么脑图、PPT画图、或者其它什么新式软件工具，UML几张设计图足够从静态和动态角度来表达我的系统设计了。
- ER设计：毕竟绝大部分是做一般的企业业务系统开发的，跟数据库打交道太多了，数据结构大部分是表设计，ER设计基本能满足。
- 回访：在做流程设计过程中，自己实现的业务流程到底对不对，有时最好回访一下需求提出者和利益相关人，对他们说说自己对需求的理解和设计方案，看看他们的理解如何，听听他们的再次对需求的叙述，自己设计对了吗。
- 咨询：咨询在这一块更熟悉的老同事，是一个事半功倍的好方法，有时别人一句话提醒就解决了我们的难题。
2. 系统功能性设计
- 用例详细分析：一定要对需求分析阶段得到的用例图，不断详细分析揣摩，从实际分析出的功能点出发做系统分析设计，不要抛开用例图，动不动就从自己臆想的技术角度去做设计，这个现象见得太多了。
- 关键流程设计：如果存在复杂的流程，对关键流程要做一个恰当的设计，详细到什么程度自己把握，就是能指导自己编码实现就可以了，用UML时序图或活动图基本就可以了。
- 关键类和包设计：关键类设计是非常重要的，都不用多说，包和子系统设计也是顺带的事情。
- 数据结构设计：数据结构的重要性毋庸置疑，程序=数据结构+算法等著名论断不少，而数据库表设计是最重要的设计，这个必须做好。
- 系统组件设计：我们设计的类和包到底分布在哪些组件里，这些组件是怎样关联的，是需要搞清楚的。
- 系统部署设计：最后就是软硬件系统的部署问题，清理各个子系统是怎么部署的。
3. 系统非功能性设计
- 考虑可用性和友好性：你们叫我做什么，我就做什么，其它一切不管，这种想法要不得。特别做前端界面的开发人员，软件功能可用性如何、实用性强不强，用户用起来麻烦不麻烦，都要考虑一下。做后台的开发人员，系统安装升级和维护，麻烦不麻烦，都要考虑一下。
- 考虑性能问题：速度如何，用户不可能等几分钟才看结果，即使功能正确了对用户也没有用。
- 考虑资源使用情况如何：对做后台的开发人员，至少要考虑CPU、内存、磁盘和网络的开销吧。
- 考虑数据量如何：如果你的系统属于大数据类的，数据会随着时间不停增长，那么这个问题很重要。如果你不考虑，刚上线是很正常的，说不定1个月之后某天就出大问题了。
- 考虑系统安全性：系统安全性常常是我们在开发过程中忽略的问题，说不定某天就被不明人员轻易攻破了，所以至少基本的安全问题要同时在设计过程中就考虑到。
4. 总结
系统设计主要是两个大方面：功能性设计和非功能性设计，非功能性设计常常会被我们遗忘或部分遗忘，导致系统上线之后或运行一段时间之后不可用，所以我们不能忽略。
