项目总结

历时一个多月的地狱式开发（每晚都忙到11点以后，偶尔1、2点，没有节假日和周末），项目终于上线了，虽然有各种问题，但还是觉得应该总结一下得失，便于提高自己。

由于刚转岗到现在的部门，刚来就参与了项目，负责的是项目中的一个模块，属于核心业务，而且之前完全没接触过这块的业务，亚历山大。

项目开始第一周，天天开会，基本就是在开会中度过，下午开会，晚上开会，每次会议都要2、3个小时，结果一个星期过去了，项目几乎没什么进度。(⊙﹏⊙)！到第二周才开始开发，十几个人封闭式开发，技术方案是别人定的，直接照着开发就行了。。。

我复杂的这块业务逻辑非常复杂，初略算了一下就有13种情况，后期开发过程中，不断发现有遗漏的场景，最后到底有多少种情况，只能说大概有近20种了吧！！！事情已经够复杂的了，可大佬们还觉得不够，在数据库里冗余了一堆字段，而且还对外开放，作为检索条件。有几个字段是要作为条件，去第三方接口查询一下信息。其中有一个字段涉及到主业务流程，如果查询不到或出错，抛异常，记录日志，程序终止，只要查询到信息就行了，信息内容不关心，现在对这些信息作了冗余处理，并对外作为检索条件。其他字段查询的信息都不是我的主业务逻辑，记录一下日志，查到就做冗余处理，并对外作为检索条件。出错或查不到，都直接忽略，程序继续往下跑。

在开发测试阶段，经常会获取不到信息，导致下游业务从我这里检索不到，锅就甩给我了。向大佬们反映这问题，可大佬们说，“你用这个字段从第三方获取的这些冗余信息，在他们那里是一定存在的，而且如果调他们的接口出错，都有抛异常了，程序就停了，所以最后数据落地时，一定会有这些信息。” 就这样给我驳回了，理论上来说，这样是没错，是能获取到这些冗余信息，但意外往往在不确定的时间、不确定的地点、不经意间就出现了，怎么能这样打包票呢？！！而且这些冗余信息，完全可以让下游业务自己去第三方获取检索，然后通过id到我这边来查询，本身就下游业务自己的事，为什么要提他们做了呢，做得越多错得越多。表里的字段已经够多了，大概有十几个字段，估计有10个字段是作为检索条件的，可以各种检索，多了这些冗余字段，而且还作为检索条件，索引都不好加，索引加多了，影响写入速度，到时出现了慢查询，DBA来找你了，锅还是你的。如果第三方的这些信息变了，你还得去同步，虽然大佬们说，基本不变，可以不考虑，不用去同步。呵呵，如果变了，然后下游业务从你这里检索不到，问题又出在你这。在大佬们的世界里，我的技术方案是没问题的，出了问题也是因为你技术太菜。

产品原型是在线形式的，就不用自己去下载了，倒是挺方便的。可如果产品经理什么时候偷偷改原型了，你也不知道。原型评审完后，经常出现今天做的东西，明天就和原型对不上了，而且原型处处是陷阱，有些东西隐藏得很深，找产品经理的话，还会喷你不仔细看原型。

经过一个多月的开发，期间遇到无数问题，程序反复改，终于昨晚上线。可上线前十分钟，突然要加需求，原型中是没有这个需求的，产品经理却说是你们自己考虑不周，而且这里的逻辑已经够复杂的了，前面已经说过，有近20种情况了，然后大佬们同意了加！！！没办法只能匆匆的加，测试简单测试一下，就上线了。结果上线时，这里出问题了，锅还得你背！！！

各业务方之间是通过dubbo进行数据交互的，在开发过程中，突然出现了Spring-security安全验证，导致用swagger测试接口时，必须要用户名和密码，找了半天才发现，在引入其他业务方的dubbo接口时，他们把自己的一些业务包也放到了对外开发的maven里了，造成了依赖继承。

一些总结：

1、不要做多余的事，做得越多错的越多；

2、关键的地方一定要有日志记录，方便排错，也避免后期扯皮，有日志为证；

3、不要相信任何第三方返回的数据，必须要校验，包括对象里的属性都要校验，避免出现NullPointerException；

4、对外提供接口时，一定要注意数据安全性，过滤敏感信息，避免造成数据泄露。

5、对外提供maven包时，将外接口和业务逻辑放在不同的包里，尽量保证接口包的干净，不要有其他多余的包，避免造成依赖继承，影响到其他人。