总结：
数据融合项目自2018年10月中旬开始，至2019年2月上旬止，经过了接近四个月的开发进入稳定版。在此次开发过程中，在各个方面都遇到了一些问题，最终影响了开发的效率，和产品的质量。但是，也从中吸取了经验和教训，提升了自己。
概述：
项目成立的初衷是，针对现有监察委数据融合系统存在的，无可视化、效率低下、难以普及、难以操作等弊端，提出做出高效率的数据融合的v版。
在基于原系统的需求和设计上，进行了初步改良。 因此没有需求和产品的介入，直接进入了设计开发阶段。导致了需求不明确，项目蓝图不清晰。继而出现开发阶段需求反复调整。联调和测试阶段无可靠依据。
改良方案是：
- 利用codis的map存储特性，自动将同一key的不同数据进行整合，继而通过搭建集群、使用pipline等措施提高整合的效率。
- 利用kafka的partition独立消费机制，实现任务的分布式创建执行，使融合程序达到简单方便可横向扩充资源的目的。可根据任务量修改部署执行的环境、可通过集群技术增加组件的吞吐量，不至于因程序瓶顶而降低融合效率。
- 同样采用分布式技术执行融合过程。
- 采用es作为容器存储融合的结果，加速查询效率。
个人心路历程：
我加入项目组时，融合程序的日程是，即将开发完毕，在初步自测功能和性能。
所以我从项目使用的相关技术组件，环境搭建，以及程序设计实现的角度去了解整个融合程序。
由于前期需求工作的缺失，不足够完全清楚程序为了解决什么样的实际场景，又最终要达到什么样的效果，以及程序后续的被应用场景。
对程序的理解直接来源于，原数据融合程序的数据库设计，而个人对数据库设计的理解仅仅达到了我以为的程度，细节上的误读导致了后期才发现一些存在的不合理性。
即使是开发，也不能仅立足于技术和设计，还要结合需求场景等等因素，从本质上去理解程序的意义，给自己的设计以及开发指引方向，提供灵感，使工作更加合理，减少不必要的麻烦，提高工作效率和代码质量。
然后由于个人对业务上的不够熟悉，可视化系统原型设计上，没有很好的参与。对功能理解不到位。
仓促的做接口的设计，定义了很多不合理的参数，后续开发中一改再改。没有达成统一清晰的接口定义，在实现上也略显混乱。
同时，由于前端同事加入项目组时机过晚，也没有参与可视化原型的设计，也对功能不够理解。同时原型图设计的不够详尽，仅有页面没有交互，以及接口定义的种种问题。
使得前端同时在开发过程中，不能有效提出自己的想法和见解，过于被动依赖后端同时的支持，而需求变更等等问题，使前端工作进行缓慢，并且大量精力浪费在了讲解接口，功能，设计等方面。缓慢的进度也让所有开发人员感到疲惫倦怠。
无论是前端和后端人员，应该是直接对需求和功能负责，在需求传递时就应该到位，并参与原型设计，在理解工作目标功能设计等基础上，相互平等，相互协调，各司其职，达到思维碰撞，共同完成一个合理的、友好的、高效的功能。
希望在接下来的工作中能够吸取上述经验和教训，少走弯路，更高效率高质量的完成工作。