zoukankan      html  css  js  c++  java
  • 项目总结,从替补到主力再到核心

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

    一、从替补开始

      我进项目组时,系统的原型已经有了,系统架构和业务流程主干已经成型。我被安排了一个类似预研的任务,要去研究这种报表工具是否符合我们系统要求。这活可以说是项目组内最轻松的,其实类似于打杂,很快我的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多本书,也许对我自己来说也会是一个记录,谨此纪念。

  • 相关阅读:
    聊聊WS-Federation
    用双十一的故事串起碎片的网络协议(上)
    责任链模式的使用-Netty ChannelPipeline和Mina IoFilterChain分析
    最小化局部边际的合并聚类算法(中篇)
    最小化局部边际的合并聚类算法(上篇)
    UVaLive 7371 Triangle (水题,判矩形)
    UVaLive 7372 Excellence (水题,贪心)
    POJ 3312 Mahershalalhashbaz, Nebuchadnezzar, and Billy Bob Benjamin Go to the Regionals (水题,贪心)
    UVa 1252 Twenty Questions (状压DP+记忆化搜索)
    UVa 10817 Headmaster's Headache (状压DP+记忆化搜索)
  • 原文地址:https://www.cnblogs.com/todsong/p/2787169.html
Copyright © 2011-2022 走看看