四个月总结之V1.0和V2.0

在上篇博客中，我列举了我这四个月来的在公司中的一些工作内容，以及在工作内容中的一些小感触，这些感触和工作经验将伴随我在以后的道路中越走越长。回到正题，上篇博客中我也说到了我们部门在获取竞彩数据源（足球篮球赔率、足球事件等主要信息）LSport的XML数据源中，我们先后迭代了两个版本，可以说这两个版本发生了翻天覆地的变化。

老版V1.0

V1.0中，我们用的框架是SSM+HProse+Memcache+Tomcat，我们采用的是传统开发模式，传统开发模式我指的是这两个方面，第一个：面向过程；第二个：测试环境以及生产环境采用老套的部署方式。

先说第一个方面：面向过程。为什么这么说呢？我个人认为面向对象中的一个重要概念—封装、抽象不够，我分析了下，大概如下：

从XML数据源到入库的过程中，逻辑混乱

LSport数据商给我提供的是XML文件，所以就涉及到XML文件的解析，XML文件我整理了下，包括以下两种，第一种是赛前（专注于提供各种赛前赔率），第二种走地（专注于走地中的赔率以及走地过程中的足球篮球比分变化和足球的红黄牌、进球、点球的事件变化）。这两种XML在解析的过程中，完全是按照过程去解析的，写在了业务逻辑中，当业务逻辑中需要XML数据源中的某种数据的时候才去取值，然后进行下面的业务逻辑。比如：

（其实下面的逻辑还很多，我就不全截图）

逻辑分层不明确

没有一个确定的三层或者四层概念，将业务逻辑糅合到一块，比如说你会在一个方法里面找到既有解析XML数据源的业务，也能找到对赔率或者走地过程中足球产生的事件业务逻辑，也可能找到对数据进行CRUD的操作 。这在后来给我的维护带来很多麻烦，在哪里都能看到CRUD，我想根据C和U的内容数据给其他部门提供服务的时候，我是把整个所谓的Service层中的所有类仔仔细细的找了个一遍。

命名不清晰

比如说ScorersParserImpl和ScoresParserImpl，不知所然，得进去看里面的注释或者里面的代码才能知道这两个实现类是干嘛的。

字符串拼写在代码中，没有抽象出来，如果我发现写在代码中的football现在要改成soccer，那我岂不是，要ctrl+shift+f，查找所有的类中的football，即使查找出来也不一定能够改正确，万一你在写soccer时错写成socccer，或者你漏掉了一个football，这样就即花费了时间也花费了精力。但是如果你将其抽象出来，那么你只需要改一处便实现了更改多次。本来2个小时的工作你只需要1分钟就能搞定，而且还降低了错误出现率。比如：



唯一值得我高兴的事情就是，还好知道面向接口编程，还好不是千篇一律的Class、Class、Class。

项目部署方法老套

说到另外一点就是部署，V1.0的部署就是生成.class文件，扔到tomcat中，然后重新启tomcat，持续集成？没有！！不管是在测试还是在生产上都是这么做的。说到这里，就因为在项目部署这块没有一个完善的体制，还出现了这么一个问题。在本地，业务逻辑正常无误，部署到测试环境，业务逻辑正常无误。紧接着部署到生产，功能出现问题，问题反复试了很多次，反复查找，找不到问题所在。最后我们boss将整个jar包替换成测试环境中的jar包，生产环境恢复正常。如果在项目部署这块有了一个完善的体制进行管理，这样的问题不会出现了吧。

当一个人拿着这样一个项目的时候，感觉整个人都是乱的，影响心情，后面的人在接着在这个版本上做的时候，心境可能就不一样了，可能就会想着，这项目都已经成这样了，我还想着分层、想着抽象、想着封装、想着面向对象、面向接口干嘛。这是一个恶性循环啊。

新版V2.0

再看V2.0，这个版本是在我们组另外一个Java开发雷明完成的。使用SpringBoot+Mybatis+HProse+Memcache+MQ实现的。在上篇博客中，我也提到，V2.0和V1.0相比，最大的不同点就在于V2.0是一个将面向对象体现的淋漓尽致的一个版本。为什么这么说呢。

第一：V2.0面向接口编程；

第二：将LSport数据源XML的解析和业务逻辑处理以及数据入库分开，清晰明了，不混杂。V2.0,大体也就分为这三个主要的方面，XML解析，业务逻辑处理，数据入库，这三方面完全分开，也就是说先进行XML解析，然后解析后的XML数据封装到实体中，传到业务逻辑处理拦截器中进行业务逻辑处理，然后将经过业务逻辑处理完了的数据封装到实体返回，进入下一层进行数据入库。好处不用说，彻底分开，你是你，我是我，所以不打扰谁，谁也不插手谁的事情，出现错误之后也方便查找。

第三：分层明确，归类明确，命名明确。既然能将XML源入库过程分为三类，那分层岂不明确了，谈到归类和命名，我不得不说，雷明做事太细致，对待V2.0，就像对待自己的孩子一样，发现那里归类不明确，命名不明确了，不管多麻烦，都要求自己改过来。这一点，我必须向他学习，我做事就有点将就，如果发现改一点需要改好多，或者是说改了就意味着这块逻辑需要重新测试，我就会变得将就，从他身上，我知道了将就就是懒惰，就是在害自己，就是一种不懂得提高。看下我们的归类和命名：



第四：使用MAP，减少list的使用，减少双层循环。这一块我主要想说下在V2.0中我们解决了一个V1.0没有解决的足球走地中产生的红黄牌、进球、点球事件的一种时间回退的现象，这块逻辑处理的很巧妙，期待下篇博客吧，哈哈，肯定能让你体会到Map的奇妙，以及利用Map来减少循环，甚至是双层循环的现象。

第五：使用枚举封装公共字符串常量或者公共方法。V2.0大量使用枚举，将赔率的类别，足球篮球的节次信息都写在了枚举中。也在枚举中写了一些公共方法，然后筛选出自己想要的数据，这个我也会在下一篇博客中说明。看下枚举中一些信息：



第六：使用抽象类，封装公共方法。不多说，大家都明白的东西。

第七：成熟的一套项目部署体制，不再出现V1.0中因为jar的缺少或者jar包的不正确而导致的问题。

其他

后来我在将足球的走地事件（红黄牌、进球、点球）入库，将这些逻辑处理从V1.0加到V2.0的时候，我就深刻体会到面向对象和面向过程的不同区别，看着两个人写的截然不同的代码，让我感触颇深，相比较V1.0，我更喜爱V2.0，V2.0让我不再将就自己，也深刻让我做到精益求精，以及面对自己做的项目的一份小心，深怕破坏了他的整个和谐，严格要求自己，也要做到像雷明一样，工作不仅要在一定时间内做完，还要将自己想到的东西，能用到的东西运用进去，并且能不断回过头来做一个旁观者来读这份项目，细化其内容，改掉以前的一些不成熟的东西，让项目越来越好。

其实，不外乎，这也是做人的道理，虽然有人也老说过去是过去，明天是明天，能把握的只有现在，但是如果不回头看自己的过去，深刻反思过去，以一个旁观者的心态来看过去，就很难看到过去的不足，这样，怎么在现在乃至明天提高自己，不再犯类似的错误。

从你是怎么来看待一个项目，就能看到你是在怎么做人。