从菜鸟到架构师（十六）

        李明到公司后，我也不再孤单，我们正式开始开发项目。

        我们公司在上海有一个合伙人，大多数外包单子都是从上海那边接来的，我们负责开发，因为上海的单子较多，而且价格也比成都的高。

        公司成立后的第一个项目是一个款社交APP，它是基于视频交友的APP。该项目的客户是上海的，我们叫他张总，他是上海滩的桑拿行业老大，业务涵盖了整个上海桑拿行业，并且涉黑。黑社会混迹了十多年，他想洗白，所以想进军互联网，所以和贵州的合伙人陈总找到了我们公司做APP。

        项目接下来后，客户很专业的把需求文档发给我们。需求文档写的很详细，包括界面截图，所需功能应有尽有。

        我和李明讨论了开发方案后，也和客户进行了一些沟通，大致确定需求后，就开始开发了。

        当时确定的需求有商家管理（就是展示桑拿行业的商家）、社交（包括一对一、群组）、朋友圈、商家排行、附近的人等功能。我开始根据这些功能确定架构，数据库采用MySql，web框架用的是SpringMVC，API接口用的是resteasy，社交功能采用第三方平台（这里就不列出具体的平台名了，不然又有童鞋说我有打广告的嫌疑了，呵呵）。

        把框架搭建好后，我就开始设计数据库，其实一开始我们开发都很顺利，各种接口一气呵成。在开发过程中，客户又增加一些需求，要增加附近的群组功能，希望能显示附近的群组，这个功能和附近的人不一样。附近的人就单纯保存用户的坐标信息就行了。但是附近的群组是多人聊天，我们当时想的方案就是创建群组的时候选择位置，这样也最简单，客户也同意了我们的方案。确定好后，后端开始增加表字段，修改接口，前端又增加界面。

         这下总算好了吧，给客户演示了APP后，他看到微信有一个功能是在聊天界面输入指定关键词就能自动播放指定的gif图，比如输入“生日快乐”，显示很多蛋糕在界面上。当时我们用的第三方平台并没有提供这种功能，如果要开发，肯定需要我们自己写，那工作量可想而知，而且我们是做外包，图的就是快。我们当然不同意，就和客户胡扯。

        扯到最后也没个结果，这个项目也一拖再拖。最初的需求和客户后来各种改动已经大不相同，这个项目感觉快挂了，我也实在不想做了，因为做的揪心。袁总最后外包给了一个人来做这个项目，让我去做其他项目。

        那时，公司的项目很多，但是公司没有什么人，我也只招了一个后台开发人员，名叫韩东，Android端李明招了个妹子，名叫高晓红。我们的做法是先接到公司来做，如果公司的人手不够，会继续外包给外面的程序员来做。

        这个社交APP项目成功甩手之后，我以为后面的项目应该会好很多，可谁曾想坑一个比一个多，一个比一个深。

        这个项目之后，公司又给了我一个新的项目，是基于微信公众号的一个商城，该商城以卖卫生巾为主。

        因为当时分销很流行，所以很多人想做这类项目，说白了，其实就是互联网的传销，只是国家法律没有对这类系统明文禁止，不构成犯罪。

        这个商城的项目的需求大部分和普通的电商雷同，区别在于，他有分销机制，也就是总部可以授权给下面的经销商，经销商可以继续授权给经销商，从而成为该经销商的 子经销商，任何人都能成为经销商，然后由每个经销商去推广，当用户从该经销商的推广地址成功购买后，该经销商将获得相应的分红，并且他的上级经销商也能获得红利，最高到上3级。

        这类系统是比较复杂的，当时客户发的需求不是很明确，我当然也是似懂非懂的，以前也没有开发过类似的项目。我按照一般电商的方式开始设计数据库，搭建框架，编写代码。在涉及到分销系统的时候，我和韩东开始讨论思路，其实数据结构很简单，分销商有上下级的关系，所以设计一棵树就行了，主要是分红的算法，我们讨论了很久。如果不考虑性能的话很简单，就是一级一级的查询数据库，然后按照规则计算的红利，给指定用户加上就行了。虽然不是自己的项目，我完全可以这么做，但是我还是想思考出一个比较好的解决方案，这样对我以后的生涯也比较有好处。

        我们研究了很久，保证性能的最好方式就是通过一条SQL语句来实现，但是不太行得通，最后考虑用存储过程来实现，虽然不止一条SQL语句，但是它是在一个事务中，避免了多次连接，多次提交。