从需求到程序设计

讨论这个问题之前，先举个例子。
一家公司找了一个建筑公司给他们修建一栋大楼，问是先有房子还是先有房子的设计图纸？
我想这个问题大家都会很肯定的回答是先有设计的图纸吧。
那么，这里再问一个问题，大楼的设计图纸是怎么来的，是怎么设计的？
这里可能有些同学就有点懵逼了。
解释：大楼的设计图是根据客户的需求来的，比如说客户希望一楼是接待楼层，那么这个就是客户的需求，既然是需求那么在设计的时候就需要考虑到这一点。再比如说一楼接待楼层需要的功能有公共卫生间，前台接待台，会客区等等的服务区，也是需求，也是功能，那么设计的时候也需要考虑进去。
所以我总结了一个结论，一个好的设计必然和对客户需求的了解程度是直接相关的，也就是说你对客户的需求了解的越深，那么你设计出来的图纸才有可能更好，更符合客户的心意。

其实，程序开发也是同理同样的，在接手一个项目的时候如果我们拿到手直接就开始做，也许最后也能开发出客户需要的系统，但是你的系统肯定是结构复杂，对象之间的耦合性大，不易于维护和升级，不易于二次开发添加新的功能等等等的局限，且如果你不太了解客户到底需要一个什么样的东西，那么你在开发过程中是很痛苦的，因为需要一边写代码还得想我这样写是不是符合客户的需求，增加了工作量，增加了开发难度，还很伤脑筋的。

所以，在接手一个项目之后。 公式： 程序设计 = 数据结构 + 算法
1、我们首先需要做的就是多和客户沟通，了解清楚客户究竟希望开发出来的系统需要实现哪些功能，多了解了解，多花点时间，才能便于开发，才能在开发系统的时候有一个完整的认识。
2、当我们对客户的需求有一个详细的了解后，我们可以根据需求整理出系统需要实现哪些功能以及需要配合功能完成的扩展和组件。
3、根据需要实现的功能、扩展和组件我们就可以整理出整个系统的数据库结构了。
4、设计系统的目录结构以及用户访问体系。
5、开发编写功能组件，这个时候和前端没有任何的交结点的，不过前端可以在这个时候设计展示界面了。前端做完后，后台只需要将前端需要的数据，通过各个功能组件拉取出来展现出来就完成了套接绑定了。
6、前后端整合，做到了这一步，就需要后台从功能组件中拉去数据，传递前端。
7、测试、排错、找BUG
8、编写文档，供客户使用。

根据开发步骤了解客户的需求是第一步，所以，如果你在执行第一步的时候就有点跑车了的话，那么后面你在后面开发的话是很恼火的。 所以第一步也是很重要的。

根据每个人的编码风格的不同，所以不同的人对相同的需求有不同的设计模型，但最典型的就是MVC模式了。

但我喜欢在基于MVC模式上延展更多的功能层

• Controller 层： 业务逻辑及流程控制的耦合点，有关于业务特性的代码绝大部分在这里实现
• Business 层： Controller层和Service层的中间层，主要起一个呈上接下的左右，有关于复杂的业务逻辑，可以在这一层实现，举例：
  获取商品信息：首次访问先判断redis缓存中是否有商品信息，如没有则从Service层获得商品信息，再将商品信息缓存至redis，第二次访问就直接从redis中返回商品信息
• Service 层：可以看做是一个部门的集合，一个部门可以提供多种服务，如数据的获取，业务的操作接口（账户冻结、解冻），该层可多级嵌套，一个服务也可以分为多个子服务，服务与服务之间应该依赖的是接口而不是其实现
• 工厂层：主要对ORM进行管理，数据的CURD操作都在这一层执行
• ORM 层：承接系统与数据库直接访问的中间层。
• Components 层：工具包所在层