项目简介

赶集上门洗车业务服务器端，分为两部分：

• 为洗车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做奖品，团队解散后也没去要过来，哈哈。