最新在从事TOO基础选课系统的项目维护工作，除了调BUG外，偶尔还开发些新功能，在这段时间，自己总结了一些东西，相信对一些没有从事过项目维护的朋友会有一些帮助的。作为出初级程序员，有时候我们不能选择自己去从事项目开发或维护，但是如果你是刚开始IT生涯，那么项目维护是你必须经历的一个阶段，没有公司敢直接把你放到项目开发的第一线，你会从维护开始，从熟悉公司业务开始。所有这篇博客还是有些帮助的。
程序员和公司的矛盾：
程序员：想要重构，不想维护；
公 司：80%维护，20%开发；
每个优秀的程序员都是孤傲的，对于别人的代码总是不屑一顾，但是却看不到自己存在的问题。当让你去看别人的代码、维护别人的”孩子“的时候，你总是显得不耐烦，在你看来谁家的代码都不如自己的代码好。在这种心态，尤其是你还就职在非技术型产品公司，他们的文档有效率几乎停留在10%-30%，这时候的你该怎么办？多数表现的很敷衍，工作积极性很低，发挥不出自己的价值。每个公司总是以盈利为目的的。对于公司来说，能跑的代码最好不要重构，因为重构意味着同样的产出却需要加倍的投入，会减少利润。尤其是非技术性公司，他不懂得如何延长产品的生命周期，短、快，粗的开发模式对他们来说是最好的发展方式，也最有效。也许他们意识到了不利于长远发展，但是并没有选择。
这个矛盾在目前的中国是很普遍的，尤其是随着外包的流行，导致不合格开发人员拍拍屁股拿着钱潇洒走人，接手的维护人愁眉苦脸，喊爹骂娘。项目维护几乎是程序员的噩梦。不过办法总比困难多，这里有几个方法可以最大程度的医治维护项目程序员的死亡。
核心原则：
1.不要试图先搞懂整个项目；
2.注重“有效提交”；
参加过项目维护的程序员应该都知道，项目维护其实就是让你做做后期的维护工作，项目的框架、结构已经完成，甚至主要你功能已经实现，甚至已经上线了，你要做的就是处理下客户邮件、调调BUG、修改下小功能，只有很个别的时候会让你去开发新的功能。所以对自己的定位很重要，参加了项目维护，不要着急整个框架的设计和理解，应注重”有效提交“。它的意思是及时完成PM交给你的任务，以任务为第一。让自己的价值先绽放出来，而不是自己的研究学习能力。否则，会出现，你研究了整个项目的框架结构，熟知了所有的技术要点，却被无情的踢了出来，因为你的价值并没有表现出来。先站稳，再向上爬。
接手方法：不变应万变。
1.项目维护有三宝：沟通 、文档 、代码跑。
目标：了解业务逻辑流。
这三点很好理解，初步接手要请教前辈给你点一点业务重点、难点，让自己熟悉下；接着就是看系统的文档了，可以让自己迅速的了解整个项目的方方面面；最后就是走代码，因为前辈的指点可能有误，文档的书写可能有漏，作为一个优秀的程序员只相信自己走的代码，用自己的代码去验证文档，才是最正确的做法。文档只是给了你方向。走代码才能真实的了解具体的业务逻辑。
2.重点攻击：数据结构+ER模型。
目的：熟知项目的数据结构关系。
其实从事多年的老鸟可以发现，不管是C/S或者B/S，怎样的开发最后都是无非是底层数据库的数据排列筛选好后传递到前台。所以对待一个新的项目，去研究它的数据结构和库表是很有效的。这就要求我们对数据结构这块进行深入研究。
3.工具：Navicat Premium。
目的：提高接手的效率，节省时间。
所谓预先善其事，必先利其器，良好且功能强大的软件开发工具可以很好的给我们提供便利，可以让我们迅速的了解项目的基础结构。Navicat Premium是一款很强大的数据库可视化工具，可以让我们在对数据库操作中提供很多便利。具体到开发什么项目可以去搜搜看有什么好的工具，
项目出活四部曲，跟、改、理、测要一起。
1.跟：抓住一个功能点，深入的调试跟踪流程，分析代码直到弄明白为止。
2. 改：修改源代码，编译运行，看修改前后有什么变化，这是感知代码用途的最佳途径。
3. 理：尝试弄清整个项目的业务逻辑。
4. 测：熟悉业务逻辑后，清库测试，测验是否符合自己所想。
维护实用技巧：
1.任何举动要备份；
2.修改代码涉及到很多的依赖，所以新增代码相对而言风险较小。（时间充足：对方法进行包装或者重写，甚至是直接修改）。
3.多和原设计人员交流；
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
