项目简介
赶集上门洗车业务服务器端，分为两部分：
- 为洗车APP提供服务的接口
- 洗车业务相关的管理后台
从整个项目上说，虽是个创业项目，但需求针对性强，从洗车仅一点上切入，易于发力。
相比曾经经历一些创业项目中，产品总是摸不住方向，不知何处发力，试错成本太高，做到最后都迷茫该做什么，怎么做。还有些项目，铺开面去搞，结果摊子太大，顾及不暇。
赶集易洗车与之相比要好太多，对我来说，做这个项目感觉很舒服。负责时间：2014-11 至 2015-08
框架代码
主要开发语言是PHP。典型 LNMP 架构。
代码框架是赶集网多年积累下来的老框架，对于老框架，工程师都是能够理解的，不过还是想说一说。
- 简易实现的路由分发
- 没有清晰的分层概念
- 有一套简单的DB访问工具类
- 对其他架构系统调用封装访问很全面
- 赶集所有频道都使用一套框架代码
总之，有优有劣。
业务代码
虽然使用了类，但仍然使用了面向过程的思维在开发。代码复用性、可扩展性比较低。由于业务简单代码耦合还不是很严重。
代码没有分层也是问题。
项目发展过程
框架的改进
赶集易洗车框架和其他MVC框架的诟病一样，表现层逻辑直接调用数据访问逻辑，并没有业务逻辑层。于是劈出一个目录，存放业务逻辑层代码。建立规范约束DB层和表现层，老的业务逻辑代码日后慢慢迁出和重构。
面向对象
老逻辑中类的作用只被用于聚合。多态和继承并没有被使用。
对DB层的再次封装
在DB访问类，由于历史原因，用起来特别不友好，也有让新人不易察觉的逻辑陷阱。
对此，我使用了Service Locator Pattern + Proxy Pattern 这两个设计模式，对原DB层再次进行封装，简化上层对DB层的调用，添加缓存的优化。之所以使用这个方案，主要是根据项目当前情况，有如下考虑：
- 不能抛弃和重构原有的DB访问类， 因此选择再其之上再进行封装。遵循开闭原则，不对老逻辑进行改动
- 原有DB访问类有逻辑陷阱，因此使用Proxy Pattern，把陷阱的规避放到proxy类中，优化对外的接口
- 原有DB类，每一个数据表都对应一个DB类，全局只需初始化一次，但会在不同的地方多次调用，所以选用Service Locator Pattern，每个DB类，初始化1次便缓存起来，供之后逻辑重复使用
用了上面的方案后，代码可维护性和可读性都提高了。
展示列表的封装
后台有很多的展示列表页面，主键往往是一样的，比如都是订单的ID，但是其他的列，有的一样，有的不一样。可以看成，不同的列表页面，就是不同的列的组合。
使用Decorator Pattern 对其进行重构。这个设计模式比较简单，但是实在是特别好。在我之后的开发工作中，凡是遇到列表，开发的时间估计就能缩小一半。维护的成本则是更低。
具体业务开发
具体业务的开发，也许是最枯燥的工作，不具有挑战性，只能付出劳力。估计只有在机器人程序猿出现后才会解决这个问题。
关于团队
团队每周有分享，可怜创业项目排期紧张，团队分享没有坚持几期，后来慢慢停掉。原因我认为可以从两个方面看：
- 随着业务压力的增大，团队给予技术成长上的提升关注也会消弱。
- 人有惰性，团队往往也是如此。
我在团队分享3次，《地理区域和点关系计算》、《代理和反向代理》、《PNI》 ， 分享积分是团队最高的，本来有一部kiddle做奖品，团队解散后也没去要过来，哈哈。