一次项目开发中,收获的经验和教训

总结:

数据融合项目自2018年10月中旬开始,至2019年2月上旬止,经过了接近四个月的开发进入稳定版。在此次开发过程中,在各个方面都遇到了一些问题,最终影响了开发的效率,和产品的质量。但是,也从中吸取了经验和教训,提升了自己。

概述:

项目成立的初衷是,针对现有监察委数据融合系统存在的,无可视化、效率低下、难以普及、难以操作等弊端,提出做出高效率的数据融合的v版。

在基于原系统的需求和设计上,进行了初步改良。 因此没有需求和产品的介入,直接进入了设计开发阶段。导致了需求不明确,项目蓝图不清晰。继而出现开发阶段需求反复调整。联调和测试阶段无可靠依据。

改良方案是:

  • 利用codis的map存储特性,自动将同一key的不同数据进行整合,继而通过搭建集群、使用pipline等措施提高整合的效率。
  • 利用kafka的partition独立消费机制,实现任务的分布式创建执行,使融合程序达到简单方便可横向扩充资源的目的。可根据任务量修改部署执行的环境、可通过集群技术增加组件的吞吐量,不至于因程序瓶顶而降低融合效率。
  • 同样采用分布式技术执行融合过程。
  • 采用es作为容器存储融合的结果,加速查询效率。

个人心路历程:

我加入项目组时,融合程序的日程是,即将开发完毕,在初步自测功能和性能。

所以我从项目使用的相关技术组件,环境搭建,以及程序设计实现的角度去了解整个融合程序。

由于前期需求工作的缺失,不足够完全清楚程序为了解决什么样的实际场景,又最终要达到什么样的效果,以及程序后续的被应用场景。

对程序的理解直接来源于,原数据融合程序的数据库设计,而个人对数据库设计的理解仅仅达到了我以为的程度,细节上的误读导致了后期才发现一些存在的不合理性。

即使是开发,也不能仅立足于技术和设计,还要结合需求场景等等因素,从本质上去理解程序的意义,给自己的设计以及开发指引方向,提供灵感,使工作更加合理,减少不必要的麻烦,提高工作效率和代码质量

然后由于个人对业务上的不够熟悉,可视化系统原型设计上,没有很好的参与。对功能理解不到位
仓促的做接口的设计,定义了很多不合理的参数,后续开发中一改再改。没有达成统一清晰的接口定义,在实现上也略显混乱。
同时,由于前端同事加入项目组时机过晚,也没有参与可视化原型的设计,也对功能不够理解。同时原型图设计的不够详尽,仅有页面没有交互,以及接口定义的种种问题。

使得前端同时在开发过程中,不能有效提出自己的想法和见解,过于被动依赖后端同时的支持,而需求变更等等问题,使前端工作进行缓慢,并且大量精力浪费在了讲解接口,功能,设计等方面。缓慢的进度也让所有开发人员感到疲惫倦怠。

无论是前端和后端人员,应该是直接对需求和功能负责,在需求传递时就应该到位,并参与原型设计,在理解工作目标功能设计等基础上,相互平等,相互协调,各司其职,达到思维碰撞,共同完成一个合理的、友好的、高效的功能。

希望在接下来的工作中能够吸取上述经验和教训,少走弯路,更高效率高质量的完成工作。

发布了15 篇原创文章 · 获赞 1 · 访问量 4715
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览