YMU2.0开发总结

YMU2.0上线了

经过9月紧张的战斗,Mars版本终于在10.1假期前上线。YMU2.0,即Mars版本从6月下旬开始,原定8.31上线,整整被推迟了30天。由于进度延迟问题,9月份公司强制加班,工作日每天晚上加到9点以后,同时周六再加班一天。

<o:p> </o:p>

本篇文章简要介绍Mars版本开发情况及一些经验教训。

开发目标

Mars版本主要有以下三大类目标:

<o:p> </o:p>

UI改版

  • 增强功能操作界面的易用性;
  • Official website也需要全面重新规划风格,并充实内容。

<o:p> </o:p>

一般功能改进

  • Report管理:进一步精化报表;采用velocity技术来实现报表模板;报表内容与用户时区关联;
  • Alert管理:告警粒度从service细化到monitoring source;进一步规范化alert rule
  • 进一步规范化各对象(customer, user, YMU-NODE, service)的状态及其转换;
  • YMU-NODE的安全性增强。

<o:p> </o:p>

系统架构升级

在不远的将来,customer数量、及并发访问会大幅增长,Public Beta版本的架构肯定不能满足要求,在Mars版本做了以下改进以达到初步的功能分布,并增加扩展性:

  • 前台程序原来全部在Web server中实现,无法实现分布处理,因此Mars版本剥离一些功能出来,形成独立的程序,从而实现功能上的分布;
  • 负载均衡:实现web server的负载均衡方案,以适应customer数量增长的需要;
  • 可靠性:初步实现数据库mysql的可靠性方案,以应付可能的数据丢失问题。

项目组结构

项目组结构大致如下:

  • 项目管理:1个,兼产品管理;
  • 系统分析:1个,那就是本人;
  • 前台组:1team leader,前期3个开发人员,其中一个新来的,而且WEB开发不是很熟;9月初开除了一个低效率的开发人员,随后加入一个新人;实际上做最多工作的是两个老程序员,9月份新加入人员做的工作很少,还占用了指导人员(team leader)大量的指导时间,真是得不偿失;
  • 后台组:开始有两个开发人员,其中一个老的,一个新加入的;由于工作安排问题,新加入的只是在练手,对Mars版本根本没有帮助,9月初因为效率问题不予转正;
  • QA组:一度达到4个人,其中一个team leader,到9月份时只剩下两个。

进度延迟原因

分析一下延迟的原因,主要有以下几点:

<o:p> </o:p>

前期规划时间不够Mars版本的前期规划(需求、技术验证)只是进行了大概12周的时间,很多功能需求都是比较粗的、未经过全面讨论,也未与程序人员进行充分沟通。这样造成两方面的问题:一是工作量无法精确评估;二是后面开发过程中有较多的修改、细化和返工。如使用google map来展示监测源及结果就是在开发过程中增加的特性要求;另UI改版成Yahoo Mail Beta的风格也是开发进行后才确定的,工作量还不小呢。<o:p></o:p>

<o:p> </o:p>

Project plan不够充分:进度规划时,时间点及功能知识只是根据市场策略来定,而未考虑具体的工作量及人力资源情况;同时开发人员做计划时,总是存在乐观估计个倾向,未能充分考虑任务的复杂性和工作量。因此,从某种角度看,该计划从一开始就不是很实际的计划,多次delay也就在所难免了。

<o:p> </o:p>

人力资源问题:人力配备上,从数量上看,应该算不错的了,但有些人员的素质还有待于提高。其实,从公司成立以来,人力资源一直是个问题,没有能补充进充足的、合适的programmer。另外,在前面项目前期,大家都有些松懈,没有更早紧起来,浪费了不少时间。如果大家都能像9月份这样的工作干劲,可能就需要这么多的delay,或有更多的测试时间,从而有更高质量的版本。

<o:p> </o:p>

新技术原因: 为分布式、性能、容量等考虑,技术架构做了较大的升级。主要是public beta版本着重于功能,未充分考虑适于分布式,大规模系统和HA的架构,因此造成Mars版本较大的架构升级。目前也只是做到前台功能的分布,已经独立出NSS, RGS, ADCS, AGMS, CMSIFS等可分布部署的SERVER,后面还有很多架构方面的工作需要做。这些升级采用了Socket通信, Multi-Thread等在以前版本中未使用过的技术,这明显增加了coding, testingintegration的时间。

<o:p> </o:p>

版本规划问题Mars版本的目标还是比较宏大的,前期规划需要3月完成,并规划了几个可发布的子版本。实际工作过程中,由于工作安排问题及UI风格调整等原因造成子版本是不可发布的,只能总体发布的局面,这样总体进度就比较难把握了。

<o:p> </o:p>

现在总结一下,其实还是可以分割成多个可发布的、粒度更小、更易控制的子版本的,如可先完成UI改版,给用户更好的体验;其他功能及架构改进则可根据优先级安排到不同的子版本中。

<o:p> </o:p>

这是个重要的教训,我由此体会到了迭代开发的重要性。以后规划版本时,可以半月为基准,最多不超过1个月。

<o:p> </o:p>

关键点控制问题:在Mars版本开发过程中,主要抓了前台Server的设计及code review,取得了一定的效果;但对关键点控制还是做得不好,还有很多漏掉的。

Instant check功能,是老功能,就没有特别关注,9.28部署上去时,发现了很长时间不能显示检查结果的问题。经检查,发现代码中存在很多问题,经改进,效率提高了很多。实际上对用户来说,这是个很重要的功能,因此需要把它列入关键功能,做重点检查、Review和测试。

<o:p> </o:p>

还有登录功能也存在较大问题。现在输入密码后,要很长时间才能进入操作界面,这对用户体验绝对是灾难性的。而且该问题是我们的customer发现并提出来的!

<o:p> </o:p>

功能复杂度增加原因:每个user增加了time zone,并需要体现在报表、alert和客户通知邮件等,这给RGS, AGMSCMS等的设计和开发增加了不少复杂度。

总结

Mars版本延迟发布的教训是深刻的,需要我们在以后的版本开发中加以避免,为用户提供更快、更好的服务。在互联网时代,你不需要完美,但你一定要快,一定要根据用户需求、竞争对手情况快速进化,如果慢,那你就死定了!

<o:p> </o:p>

互联网法则“快鱼吃慢鱼”是一条你必须遵守的法则!

<o:p> </o:p>

资源下载链接为: https://pan.quark.cn/s/3d8e22c21839 随着 Web UI 框架(如 EasyUI、JqueryUI、Ext、DWZ 等)的不断发展与成熟,系统界面的统一化设计逐渐成为可能,同时代码生成器也能够生成符合统一规范的界面。在这种背景下,“代码生成 + 手工合并”的半智能开发模式正逐渐成为新的开发趋势。通过代码生成器,单表数据模型以及一对多数据模型的增删改查功能可以被直接生成并投入使用,这能够有效节省大约 80% 的开发工作量,从而显著提升开发效率。 JEECG(J2EE Code Generation)是一款基于代码生成器的智能开发平台。它引领了一种全新的开发模式,即从在线编码(Online Coding)到代码生成器生成代码,再到手工合并(Merge)的智能开发流程。该平台能够帮助开发者解决 Java 项目中大约 90% 的重复性工作,让开发者可以将更多的精力集中在业务逻辑的实现上。它不仅能够快速提高开发效率,帮助公司节省大量的人力成本,同时也保持了开发的灵活性。 JEECG 的核心宗旨是:对于简单的功能,可以通过在线编码配置来实现;对于复杂的功能,则利用代码生成器生成代码后,再进行手工合并;对于复杂的流程业务,采用表单自定义的方式进行处理,而业务流程则通过工作流来实现,并且可以扩展出任务接口,供开发者编写具体的业务逻辑。通过这种方式,JEECG 实现了流程任务节点和任务接口的灵活配置,既保证了开发的高效性,又兼顾了项目的灵活性和可扩展性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值