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

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

一、从替补开始

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