时间很快，离开SQM团队已接近10个月，对于参与了5年的项目，很早就想写些什么来纪念；现在终于找到了时间，用自己半生不熟的语言，站在自己的视角来回顾这个项目的历程。
10年，项目伊始
在先前的移动数据业务SQM项目努力坚持了两年之后，领导为我们找到了新的归宿，与IPTV产品联合开发新的SQM产品，名字为IPTV SQM。
IPTV SQM并不是新名词，在与我们项目组联合之前，IPTV已投入人力试水了一年多，但效果不佳，公司内外均无法得到认可；而我们项目组彼时陷入困境，产品辛苦研发两年仍然无法上市，虽说积累了很多经验，但无法变现，从领导到项目组充满了悲观的情绪；因此双方的合作可谓是一拍即合，IPTV可以利用我们的人力和经验来扩展思路，而我们则需要他们的经费来解决团队的生存问题。
双方的领导对这个项目寄予厚望，研发投入有了保证，在联合开发团队组建之后，团队规模膨胀到40人左右，我们项目组重新恢复了生气。
当然现实是骨感的，出于各种原因，第一个版本从5月份启动，10月份才完成发布验收，中间磕绊无数，项目组顶住上层领导的压力，终于坚持了下来，迈出了切换产品之后的第一步。
第二个版本也在年底前发布，并在一线某局点成功上线，项目组上、下充满了乐观的情绪。
本年度发布了C20、C21版本。
11年，痛并快乐
随着我们研发的IPTV SQM版本开始在国内、海外成功试点，来自一线的需求像雪片一样纷至沓来。项目组的压力陡然猛增，但好在双方领导对项目的关注不减，投入不变，因此压力还在可控范围内。
但前期研发节奏过快导致的问题逐步暴露出来，UI界面设计不良、实现不合理作为其中的代表，被一线和各级领导诟病，联合开发团队的上层领导达成共识，投入专门的资源来优化UI，而我作为主力成员参与其中。
比较自豪的是，本年度我完成了如下几件大事：
界面UI规范的整理。UI规范包括很多内容，比如配色，控件的样式，线条的样式，界面布局等；对于BS项目来说，整理界面的UI规范并不困难，因为公司的BS界面规范是现成的，项目组只需要遵循即可。但公司缺少CS的界面规范，而我们项目组恰巧基于Java Swing技术来构建C端界面，因此在整理界面规范时，美工其实没有多少现成经验可以借鉴，而我在应用Swing来构建界面方面其实是一知半解，因此在整理规范工作的前期，我们双方合作其实并不愉快，进度也很缓慢。好在美工MM非常有耐心，而我也在美工不断的鼓励之下，终于摸清楚了Java Look&Feel定制的门路，规范整理工作很多步上了正轨。
这里引用下那位美工MM的名讳，周翠兰，在写本文的时候她已经从公司离职了，希望MM天天快乐。
界面基础组件和使用样例的开发。规范输出了，但没有样例的话，是无法落地实施的，所以在规范制订的后期，我把主要精力放在了基础控件和使用样例的开发上。主要工作包括色彩、字体、UI属性、边框对象的加载和配置，主要应用了js和jython脚本来实现前述资源的配置。
UI界面整改。事后计算，我独立一人完成了70%的界面的整改，其余30%的界面指导项目组其他成员完成修改；老实说，虽然很有成就感，但也把我累的够呛。
C端代码整改。整改的原因很简单，C端代码在UI线程里执行了过多的复杂或者耗时的操作，导致C端在一线使用时，被很多客户投诉。解决的方法很简单，界面代码中使用SwingWorker来调整界面上的实现，把耗时的操作全部转移到后台线程中，避免占用UI线程；整改的工作量很大，但合作团队很配合，所以这个问题很快得到了解决，而年轻的合作团队从中得到了快速的成长。
告警模块的设计和开发。这个模块功能比较独立，我自己认领了服务端的全部设计和开发任务。当时考虑到要支持动态查询，为降低C端实现的复杂度，同时降低对后端DB的查询压力，因此应用了内存数据库H2来缓存数据，既避免了对后端DB的查询压力，又提供了动态查询的特性。当然应用新技术是有代价的，为了定位一个概率重现的问题，我在办公室里守了通宵，终于在天快亮的时候找到了问题所在，赶版本转SIT前消除了Bug。
本年度发布了C22、C23、C25、C26版本。
12年，危机初起
经过两年的辛苦开发，SQM项目进入了平稳运转的阶段，需求数目变少，试点项目变少，外部对SQM开发团队的关注度下降，双方的领导各自有了想法，对联合开发项目的投入逐渐下降。一来二去，导致合作团队的人力大量流失，我们的合作方团队损失了很多优秀的开发人员，到年中，项目经理干脆只保留了测试人员，释放掉了全部的合作开发人员。而我们自有人力中，也在不停的流失开发人员，郭靖为了媳妇去了苏州，姜山寻求更大的发展去合资公司做交付项目管理，唐丹丹离职去了新公司。比较自豪的是，本年度我完成了如下几件大事：
客户端拓扑组件优化，一举解决了客户端加载拓扑数据之后，内存占用过高、CPU占用过高的问题，同时消除了历史代码中的Bug，极大的改善了用户体验。
服务端拓扑数据同步方案的优化，解决数据传递过程冗余、代码实现复杂、可靠性低的问题。
本年度发布了C27、C28、C29、C30版本。
13年，危机爆发
转眼间IPTV SQM的联合研发进入了第四个年头，联合开发团队的矛盾终于爆发。双方的领导在人力投入、合作模式、费用结算上出现了更大的分歧，而IPTV SQM在一线应用这时也出了问题，新开发的部件无法在一线上线使用，多个发布版本无法在局点上线，SQM的应用效果大打折扣。领导对SQM的关注在下降，资源投入随之下降，而作为项目组却毫无办法。
本年度发布了C40、C50、C60、C70版本。
施健离职，参与创业团队，项目组损失了一员大将。
14年，回光返照
项目组接到了新部件的开发任务，分别基于Silverlight、安卓、HTTP、Flash、iOS提供客户端监控部件和对应的数据接收部件。当然，限于项目组的实际交付能力，我们最后其实只发布了Silverlight、安卓两个平台的监控部件和数据接收部件。
由于安卓平台在国内的快速应用，安卓平台的监控部件在公司内外获得了很多关注，项目组熬过了夏天。时间到了秋天，基于SQM在安卓平台的成功，项目组申请到了iOS的人力资源来发展iOS平台的监控能力，但可惜的是，最终只发展出了雏形就不得不把人力和监控部件整体返回给公司的iOS团队。
比较自豪的是，本年度我完成了如下几件大事：
· 作为主力，主导设计并完成大部分Silverlight平台监控部件的开发工作。
· 作为主力，主导设计并独立完成安卓平台监控部件的开发工作。
· 借鉴安卓应用的编译框架的思路，对项目组已有部件的编译脚本进行整理，将公共特性及定制部分分离，极大的降低了编译脚本开发及维护的成本。
本年度发布了C80、C90、C91、C92版本。在完成Silverlight和安卓平台的监控部件之后，项目组的骨干测试MM邵金亚离开了项目组。
15年，离开
时间太快，转眼5年过去了。1月份，部门成立了新的工具开发团队，我被项目经理调走，离开了SQM开发团队。而SQM团队随之很快被整体切换至IPTV部门，与我所在的部门彻底解除了关联，联合开发项目团队随之解散。
总结与回顾
技术上的收获
· JVM内存参数调优
· Java应用问题定位
· Java Swing开发
· Swing UI LookAndFeel定制
· JVM上运行脚本。JS、Jython的使用。
· Ant脚本开发
· 基于Wireshark的协议解析
· 安卓应用开发
· C#开发
· Oracle的使用，如执行计划的分析、表索引的分析、分区的使用及分区在数据备份方面的应用、表分析参数调整及表分析数据的应用、AWR报告的使用等。
· mina的使用。
教训
· 对团队的危机视而不见，姜山、唐丹丹、施健的离去都没有触动我，现在想来，自己真是麻木，完全看不出来项目组的危机。
· 加班太多，没有时间思考。
· 忽略了学习，自我提升有限。
· 在舒适区待的太久，没有及时改变。
· 忽视了身体。
· 我自己引以为豪的技术和改进在领导眼里其实价值不大，虽然我本人投入巨大，也很辛苦，但站在领导角度一想，结论确实明显。
