我的工作生涯中关于项目的需求和功能分析（保洁公司项目）
欢迎提出建议。
这个项目是刚进公司的一个比较小型的项目，而且那时候因为刚自学完编程，对所有东西都不是很了解，现在想来确实有很多地方可以优化和修改的部分。
依旧是需求分析和功能分析，不牵扯到具体实现，如果有的话也是平台无关，任何语言在某一个方面都是相通的。
比如mvc架构的框架，就是那么一回事，m是作为模型和数据存储,c作为控制用户请求的返回结果，v则是展示。
不管是php java 还是 c# mvc框架都是这样的道理。
又比如 orm框架，核心内容都是封装数据库，以更便捷，简单，容错性更高的高层封装了sql的复杂性，加入一些语言特有的特性和优势，核心内容就是封装复杂性。
昨天又看了一下 java 的 spring文档，spring 作为一个 framemwork ，核心内容是 aop框架，而aop框架是什么呢，说白了就是一个懒惰的程序员，不想写 很多 大部分内容相同，而小部分不同的类，就做了spring。
也就是 不在类的内部创建，而在类的外部创建，通过一个控制类来注入这个类需要的内容。
例如有一个 数据库操作类，这个类需要一个连接类来连接到数据库，一般的写法就是 在这个类中 new 一个连接类，通过这个类来访问数据库。
而 aop 则是在这个类中创建一个 接口（或者抽象类），aop框架在这个数据库操作类实例化时，注入你在注解（配置文件）中实例化你指定的那个数据库连接类，并把这个连接类注入到这个数据库操作类中，这样就是一个最基础的 aop 操作流程。
现代的大型程序，不光是数据库操作类中的连接类是注入的，甚至连数据库操作类也是注入的，所有对象都可以注入，依旧是在配置文件中声明后， aop框架托管注入对象的生命周期，只要在程序入口初始化一下aop框架就可以了。
所以我个人的理念，就是尽量使用新版本，新版本做的事要比旧版本的多，那么相对时间就更能专注在业务上。
毕竟没有提升为什么要更新版本，不过有些框架会强制需要新版本，比如 spring 4 以上就需要 至少 java 6以上，推荐 java7 或者 java 8。
当然公司指定用什么版本，那也没办法只能照做。
好像扯远了，接下来是保洁项目分析。
- Pc端主要用于展示，同时因为执照的原因，所以pc端不能有付款的功能，所以pc端功能相对来说简单一些。
- 手机端除了展示之外也包含微信公众号支付，并且制作的时候据说会有 app部分，当然到现在网站已经没了,好吧刚看了一样，好像是服务器到期了，然后今天续费。。
- pc端首页要有项目展示，翻图，以及公司详情，实际上pc端就是普通的公司网站首页再加上查看订单的部分。
- 手机端首页，翻图和项目名显示。
- 项目详情和付款方式，商品有三种形式，有服务类，商品类和，是最麻烦的步骤了，这一部分到之后再说。
- 订单生成和查看。
- 微信公众号付款。
毕竟是我接收的第一个项目，所以实际内容比较少，不过能说的部分也挺多的。
首先是 pc端，根据需求分析的话，pc端是 普通公司首页网站再加上用户中心。
公司网站就不用说了，不过需要显示项目名和实际项目描述，这一部分依旧是单独抽取出来，包含项目名称，项目详情和价格等。
也就是说，pc端整个内容就是 用户中心 加上 公司介绍 以及 项目展示 这三个部分，核心就是从数据库获取数据。
接下来是手机端。
要我说的话，手机端其他部分和pc端是一样的，区别就是 增加了 商品显示模式和支付功能。
支付功能很好解决，先查看官方的api，然后再网上找一下有没有对应平台的 高级接口，复杂的反而是调试部分，单就功能来说，就是照着文档做就行了。
最复杂的部分是商品的购买模式，这部分原本有2种模式，1是服务，保洁公司的服务就是保洁，那么就需要在生成订单时知道什么时候去服务。
同时普通商品是有数量限制的，也就是说普通商品是存在总库存和已购数量。
又因为需要生成订单和订单中的商品，同时又因为商品又是有时效性的，比如做活动的商品和普通的商品价格和数量肯定是不一样的，如果用户在特惠的时候买的东西，过几天后在订单系统中看到的价格却是普通的价格，
又或者反过来的情况，那么这个订单系统是存在很大问题，所以这里订单设计为订单主表，存放订单编号（微信订单号是有服务器生成后传给微信）和其他信息，然后订单商品表存放用户购买的商品和服务，这里的商品和服务，
是不保存商品表的主键的，而是复制商品表中的字段，比如商品名，数量和价格，这样用户订单中的价格就是用户购买时候的价格而不会随着运营修改价格而变动。
那么就很简单了，商品表存放商品类型，根据这个类型来生成页面中的 是否作为服务或者商品的购买方式。
同时生成订单时，保存订单主表和订单商品表，然后使用一对多关联，这样订单中的商品数量和价格就不会随着商品表的数据修改而修改，也便于查账对账。
但是之后甲方又来问题了，首先就是商品是存在购物车的，但是服务确没有购物车，这里就要做一个判断来让商品类目中，哪些类目允许存在购物车中，哪些类目不显示购物车。
还有一个问题就是甲方希望增加多种支付模式，商品和服务的支付模式就不说了，在这个基础上要再增加三种：
1：阶梯支付模式：随着购买数量的变动而变动价格，例如买10盆米兰要100元，而20盆却只要150元
2：基础+计量单位/x元 模式：例如拖地扫地服务 基础 100元，在这个基础上每平方增加10元。
3：多选择模式：一个服务下有多种选择，比如家政服务，家政服务包含了很多种类，扫地，擦玻璃，清理冰箱，清理燃气灶等等，这里每种选择都要有对应
的价格，数量和用户备注，也就是可以选择只擦玻璃，或者选择擦玻璃扫地，同时用户需要选择对应的数量，然后填写备注。
那么就要再详细分析了，首先阶梯支付，在商品中增加模式字段，然后添加一对多的导航属性，也就是商品价格表，当在页面中判断到是这个属性时，查询对应的商品价格，生成价格下拉菜单（下拉列表之后绑定javascript事件onchange即可）。
然后是基础价格+计量单位/x元，使用原本存在的价格后再加上一个单价字段即可实现这个功能。
最后是多选择，这里 我选择了最简单的做法，就是在原来的订单商品表中增加一个用户留言即可，然后页面展示部分做出对应修改。
那么整个项目做下来，对我最大的收获其实就是初步掌握了项目分析能力，当然这里主要是业务方面，业务实现细节反而不是很好。
总之又做了一些微小的工作，很惭愧。
