YMU2.0开发总结

java_veteran

墨衍会员 · AI 创作全网分发码龄19年

关注

最新推荐文章于 2026-05-08 18:22:45 发布 177 阅读 AI 写同款· GEO 优化 ›

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个，那就是本人；
前台组：1个team leader，前期3个开发人员，其中一个新来的，而且WEB开发不是很熟；9月初开除了一个低效率的开发人员，随后加入一个新人；实际上做最多工作的是两个老程序员，9月份新加入人员做的工作很少，还占用了指导人员(team leader)大量的指导时间，真是得不偿失；
后台组：开始有两个开发人员，其中一个老的，一个新加入的；由于工作安排问题，新加入的只是在练手，对Mars版本根本没有帮助，9月初因为效率问题不予转正；
QA组：一度达到4个人，其中一个team leader，到9月份时只剩下两个。

进度延迟原因

分析一下延迟的原因，主要有以下几点：

<o:p> </o:p>

前期规划时间不够：Mars版本的前期规划(需求、技术验证)只是进行了大概1～2周的时间，很多功能需求都是比较粗的、未经过全面讨论，也未与程序人员进行充分沟通。这样造成两方面的问题：一是工作量无法精确评估；二是后面开发过程中有较多的修改、细化和返工。如使用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, CMS和IFS等可分布部署的SERVER，后面还有很多架构方面的工作需要做。这些升级采用了Socket通信, Multi-Thread等在以前版本中未使用过的技术，这明显增加了coding, testing和integration的时间。