1.前言
看过太多的称得上“三无”的软件，就是无需求、无设计、无注释。严格的说来，他们的网站建设需求和设计其实还是有的，只是没有用文档记录下来而已，但是注释确实真的没有。这些软件从大到小都有，但是他们都有一个共同的特点，就是“难维护”。前几天和同事聊天，听说一个XAML的实现要重写了，用本地协议代替，然后再去考虑和XAML兼容。虽然我没有看过这个项目的代码，但是我知道这个项目基本也是“三无”。当然这个情况也是三无的重大特征之一，就是前脚走人之后，后脚是“看不懂、下不了手”，结果是还不如重写来得简单。从员工角度，当然不会有什么不妥，但是从公司和产品的角度，则是属于“无谓的损失”。
一个对自己有要求的程序员，应该保证自己不出产“三无”项目
“规范化”可以解决项目的“三无”问题。而且这个一直是我所推崇的，正好有网友开始了12306ng项目，所以也就拿这个例子过来，跟大家汇报一下我的设计思路，同时也作为我在公司开设此类课程的备课。
2.网站建设设计
软件的设计过程其实也是一个推导的过程，这个过程的每一个步骤之间都有着各种关系：要么细化，要么印证，要么补充。我之前学习设计的时候，以为看着课本，依据什么“自顶向下”或“自底向上”就可以一步一步将系统设计出来，可是后来发现我错了。相信正在学习设计的朋友也应该会有这样的感受。
电脑和人脑相比，最大的区别是前者一个线性系统，而后者是一个非线性系统。所谓的非线性，通俗点讲，就是颠三倒四，左右开弓，文艺点讲，就是讲究“螺旋式上升”，总之就是说“机械式”的“一蹴而就”动作，人脑是不擅长的，当然，天才除外。
设计也是如此，它本来就是人脑的处理结果，所以它的过程也必然是非线性的。一种设计方法，要想被人容易学习和接收，它本身就要是一种包含“螺旋式”改进的机制，也就是戴明环的PDCA过程（Plan-Do-Check-Adjust），不过在设计过程中Plan的因素不明显，主要是DCA的过程。
在做系统设计的过程中，最大的感受就是不要限制自己。记得当年我为了完成设计，满足“自顶向下”的要求，刻意地限制自己不去深入地思考，结果当然是失败。当然，“限制”不仅是刚谈到的思考层次的限制，更重要的是突破工具的限制。所有的工具都会给思想甚至工作进度带来限制。迄今为止，最好的设计工具依然是“带橡皮头的铅笔”和“纸”，所以诸位要好好地利用它。
3.网站建设需求
如何做出一个比它更好的系统呢？答案就是“更仔细地设计”。在“更仔细地”设计之前，我们需要“更仔细地”收集好需求。
软件的需求就是软件要实现的“目的”。各位千万不要一提到“需求”就当作了“需求文档”，文档只是需求的一种表现形式而已，另外一种常见的表现形式就是程序员们大脑中的记忆。蹩脚的程序员经常通过嘴传递需求，他们宁可不厌其烦、一遍又一遍地说，也不愿意花一点时间一次性写下来，他们无法忍受客户的一次次需求变更，但却不在意自己每次说出的同一个需求都有些走样。
3.1.第一步：用例分层
这里我们用UML的用例图（UseCase）来表示需求。
用例图也是分层次描述的。所有系统最顶层的用例图（零级用例）都差不多，都是一个圆圈围绕着很多角色，区别就是角色有多少，以及圆圈里写的字不一样。这次我们的圆圈里写的是“12306ng火车票订票系统”，外围的角色只有2个：用户和管理员。
一级的用例图就完全不一样了。我把它分为了7个部分，一级用例名称和其包含的二级用例名称说明如下：
1. 用户管理：注册，登录，退出，密码找回，信息查看，信息修改，用户验证，用户查询
2. 查询：时刻表，余票，联程规划，晚点
3. 订单：下单，取消订单，修改订单，订单查询，预订
4. 票务：订票，取票，改签，退票，车票查询
5. 资金：付款，退款，查询到帐，银行对账
6. 票池：入票，出票，查询票池，修改票池
7. 维护：参数设置，词典维护，拓扑管理，日志查询，备份，恢复