项目总结,从替补到主力再到核心

一个大型的平台软件项目接近完工,在此记录。

一、从替补开始

  我进项目组时,系统的原型已经有了,系统架构和业务流程主干已经成型。我被安排了一个类似预研的任务,要去研究这种报表工具是否符合我们系统要求。这活可以说是项目组内最轻松的,其实类似于打杂,很快我的Demo做完了,而领导似乎也忘记了我,于是就那么被晾着。由于不忙,老是被其他小组拉去做帮工,帮忙跑过单元测试用例、核对过数据库字段,当时也就抱着熟悉系统、熟悉业务的心态,什么都照做了。后来稀里糊涂地被领导拉去帮忙招聘,尽干些文员的活,几近绝望。

二、争取主力位置

  机会是要靠自己争取的,一方面干好领导安排的杂货,另一方面向开发小组长要活干,很快出彩的机会就来了。项目打算用XML Schema校验业务数据,有几百份Schema要写,这种脏活我就包下了,小组长给我估了一个月的工作量。这种机械活当然可以让程序来做,不就是字符串处理嘛,花了一天就完成了XML Schema生成工具,遗憾的是,后来由于需求变更,这些Schema文件都没用上。很快第二次机会来了,开发老大在抱怨组内没人精通shell,刚好被我听到,立马自荐,其实当时的shell水平还是很差的,自荐时还有点心虚。于是我成为了介于开发与运维之间的这么一个角色,先上手一个故障检测和恢复的脚本,代码的author终于写上了我的名字,也总算在svn上提交了代码。此时,总算成为项目组中的主力成员了,服务器脚本和配置的唯一人选就是我了。

  离奇的是,领导居然把我推荐了到设计组,大概是我打杂打的好,或者领导想给我换个打杂环境,也刚好因为一个设计组的同事去其他部门了,就这样我的角色从开发变成了设计。设计组的活很杂,有真正的架构师,也有管产品报价的,有专门写产品文档的,还有做业务数据整理的,唯独没有写代码的。我被分配到了一个子系统的设计工作,这个子系统是一个对外开放的小网站。我们是迭代开发,在这一迭代,我要设计里面的账户管理功能和业务数据展示功能。这功能看似简单,但牵扯到与主系统的数据交互,而且这两功能囊括了系统的所有层次,真干起来感觉还挺不容易的。当时我的知识仅限于业务层逻辑代码,数据库、界面设计完全不懂,被开发组的同事鄙视到体无完肤。这里需要感谢我的老大对我的支持,帮我解围多次,我也静下心仔细研究了这块的业务逻辑,用户管理则充分借鉴了其他网站的成功经验,此次小考有惊无险通过了。

三、成为项目核心

  此时开发已无人写shell脚本了,但系统自动配置、维护的需求又不断,开发老大居然想把我借回去,后来几经周折也就这么定了,第一次感觉到项目组离不开我。因为我写脚本的事做不长,又有两个同事和我一起干,欣喜的是,他们的shell脚本都在我的基础上做修改,或许这也算是代码框架。更幸运的是,由于测试人员不太懂shell,我写的这么多脚本只被提了一个bug。这期间,虽然不懂数据库,我还是引入了数据库备份恢复,这又为我后面的工作埋下了伏笔。

  很快我又回到设计组,新的任务就是和原来脚本关系很大的可靠性系统设计,照着公司的可靠性checklist过了一遍,做了很多组网、系统配置、日志系统、集群、备份的调整方案,还搞了故障模式库,算是边学边干,把系统可靠性的方方面面都做起来了。这边没完,安全性的活也来了,这其实更简单一些,应用安全全部由代码规范保证了,系统的其他安全基本打补丁就可解决。我算是有一定安全的理论基础,做代码走读时发现代码中加密算法使用很有问题,甚至连对称和非对称加密都搞混了,账号管理也存在业务逻辑的漏洞,在提出解决办法后,似乎第一次感觉到开发同事认同我的设计了。

  新的任务又来了,这次是性能调优。这是系统第一次做性能测试,也没有什么checklist可以去参考了,难度比之前的活大了不少。事情刚开始还算顺利,给了测试方案,只测试平台主接口,测试很快就照着搭环境、配数据开始测了。测试结果差的惊人,每秒只能处理20次请求,而且失败率奇高。对着数据,大家都傻了,因为不知道怎么去分析,这次可没人帮我了,全靠自给自足丰衣足食。先是检查应用服务器和数据库配置,把所有用到的工具都熟悉了遍,还引入了各种性能监控工具,后来又狂学JVM和数据库,看懂了JVM监控和数据库监控报表,总算性能的问题可以在掌控中,系统性能一步步提升,似乎超过了领导的预期,也达到了客户要求。由于对系统配置比较熟悉,整个系统的存储和网络设计也交给了我,这可不是个容易活,把数据库配置与存储强相关,把数据库认真配置了几遍才算是入门。这时系统的非功能特性我快全包了。

  当各种工作都在有条不紊进行的时候,却又酝酿了一次更大的机会给我。由于客户现场来了大量需求,需要往客户那增派人,我的老大只好赶赴客户那去,就这样把整个系统的设计交给了我一个人,我要面对50人的研发团队。当时客户需求多,催得紧,我们的迭代周期缩短到原来的四分之一,工作量却不减,对我来说是个极大挑战。因为我对主业务流程没有完全理解,导致设计漏洞百出,再次感谢我的老大支持,在远程指挥下,给出了合理的设计。当然,光有设计方案还不够,还有各种实现细节需要拍板,这么多人围着我都快疯了,在我一次次妥协下,大部分都按开发的意见做了,总算被我撑过了最艰难的时刻。这期间,又狂补系统业务、架构设计、前端发和数据库知识,这次真的狂补了,白天忙,晚上加班,完全挤时间出来,还好效果不错,在下迭代设计时,就显得游刃有余了。终于,我掌管了整个系统的设计,功能和非功能特性全包了,成为了项目组的万金油,哪里有问题就去哪里,各种新技术引入,各种小demo代码。后来又借着性能测试的机会,尝试了更多的系统改良,虽然架构不是我设计的,但还是感觉到系统植入了我的基因。

  唯一遗憾的是,我没有机会调整系统架构,因为没时间了,老大们也不想做激进的事。业务上,还想调整模块间功能划分,技术上想引人全文检索、读写分离、分布式缓存,可惜都没机会了。做设计就是这样,最好的方案不一定是最合适的方案,妥协各方利益才能做出合适的设计。

四、知识学习小结

  刚进项目组时,我的知识结构是C/C++、Linux、算法基础、网络基础,而我们的系统是需要Java、应用服务器、数据库、web、集群等知识,后来还需要架构设计,显然原来的知识完全不够的。当面对新的任务,各种不会给自己很大压力和动力去学习新知识。性能调优也是相当促进知识学习的,当要把东西做好时,就会发现自己知道的太少,这样就有足够动力去学习了。

  我觉得,学习知识还是要结合项目,边干边学效果好。网络上有很多资料可以免费获取,是很好的学习材料,也可以解决实际问题,但这些往往只是一些零碎的知识点,要形成知识面还要靠书,有些好书甚至直接影响到了我们的系统。一年多时间,啃了有20多本书,也许对我自己来说也会是一个记录,谨此纪念。

原文地址:https://www.cnblogs.com/todsong/p/2787169.html