1、第一次总让人难忘
人生第一次，总会让人很难忘，第一次学会走路，第一次离开父母在异乡过年，第一次恋爱，第一次牵起女孩的手，第一次......总之每个第一次都让人难忘。
我的第一次项目经历也让我很难忘，这是转行后进入的第一家公司，是一家民营集团，公司很有钱，老板财大气粗而且很有魄力，自己建了个信息化部门，养了上百口人，集团所有信息化系统全部自主开发。
老板说了，上ERP是死，不上ERP更是死，那我们就上，大手一挥就开干了。
我刚进这家公司应聘的开发工程师岗，入职后进入了一个项目组，负责维护XX系统，这个系统据说集团的各大分公司都在使用，是非常重要的生产系统，不容有任何闪失。
因为我是刚转行过来，自己也就自学了点三脚猫的JAVA编程功夫,，很多项目上的专业术语根本就听不懂。
比如第一次听项目经理说，今天晚上上线，大家都辛苦点，晚点走，真不怕大家笑话，当时真得不懂什么叫上线。
也不敢问，后来就明白了，上线就是把测试通过的程序包部署到生产系统上。
这就是我的第一次，第一次真正接触企业级软件开发项目，第一次进入一个项目团队，一切都是生机勃勃的，未来的路不知会怎么样，总感觉是充满希望的。
2、我们的项目团队
公司的信息化部，分为几个处：需求和实施处、开发处、质量管理处。
需求和实施处养着一群项目经理和实施人员，他们负责调研需求和现场的实施工作。
开发处负责软件的开发过程，分为架构人员、项目开发负责人、开发工程师，我刚入职就是这个处的一名初级开发工程师。
质量管理处负责测试和部署，还养着几个比较牛的DBA。
每个项目就是这些处的不同岗位协作完成，实际我们当时的项目协作模式，是一种弱矩阵的模式。
我所在的项目组，项目经理是个安徽人，个子不高，非常聪明，性格非常好，没什么脾气，这对我这个刚入IT职场的人来说是个好运气。
他最喜欢和我们谈论的就是挣多少钱，仿佛他很缺钱，如果某个月的奖金发少了都会唠叨半天。
项目经理下有个需求和实施人员J先生，他成为了我的第一个师傅，我刚进来就是做老系统维护开发的，而这个老系统基本就是J先生一手开发的，只不过后来他转去做需求和实施了。
但是一个老系统，没有详细的设计文档，没有规范的注释，代码真心看不懂，只能靠师傅给多讲讲了，J先生人也非常好，特别喜欢教我，而且很有耐心，要不是他，真不知道自己能不能把这个老系统搞明白。
当时我的直属领导是Ben，一个台湾人，开发管理非常规范、非常严谨，也非常严格，经常带我们做代码Review，慢慢的我就养成了规范写代码的好习惯。
虽然通过IDE工具可以帮助我们Check代码格式，但那毕竟是机器，还要靠自己自觉的养成好的习惯，特别是要写代码注释。
看太多前人写的代码，一行注释都没有，代码写的像神仙写的一样根本看不懂。所以一定要写好注释，算是给后来人留点福利吧。
负责测试的是一个湖北人，北航计算机系毕业的，我一直觉得以他的聪明才智，做测试真有点屈才了（没有贬低测试的意思），后来我们成了很好的朋友，现在他已卖掉北京的房子回老家湖北了，过上了优哉游哉的生活。
就是这么一群人组成了这个项目团队，大家很有爱，很开心，我的第一次项目之旅从老系统开发工程师开始，认识了这么多优秀的好人，感觉自己很幸运。
3、一点心得
项目过程有几件事很难忘，让我学到很多，逐渐成长起来，今天主要从一个维护开发人员的视角看一看如何把一个老系统维护好。
（1）读懂的代码的，赶紧把代码注释写好
代码注释真的非常重要，你程序可以写的啰嗦点，甚至性能没那么高，但最起码要能看懂，只有看懂了才可能去优化。
就算是有设计文档，没有代码注释，程序照样看不懂，所以一定要写注释，就像盖一个房子没设计图纸一样，漏水了，根本不知道去哪里找原因，弄不好要把整个地板都刨开才能找到哪段管子漏水，真到这个地步动静可就大了。
所以说收到一个老系统的代码维护任务，最重要的一步就是把读懂的代码写好注释，特别是写的晦涩难懂的代码，注释写明白了，这段代码基本就是你的了，想做些重构也没问题。
（2）把各类配置文件整理好
一个系统肯定会涉及到大量配置文件，属性文件或者是XML文件，这些文件自己先弄明白，然后用excel做个整理记录，这样就不会因为配置文件的问题导致环境起不来，荒废半天的时间找原因。
（3）适当部分重构
每个维护老系统的人都觉得以前的系统写得太烂了，恨不得自己重构一遍，千万不要这样想，风险太大，不知道哪里有个坑迈不过去。
可以进行适当的重构，找部分自己觉得把握比较大的模块重新进行设计，引入一些好的设计模式，比如在原来代码基础上封装一层，原来能用的代码尽量保留，这样代码的可读性更好了，而且也不会对原来的代码有太大改变。
（4）性能优化
有些执行效率比价低的程序重点进行性能优化，性能的问题可能有很多种，可能是架构组件层面的，可能是代码程序层面的，可能是数据库模型设计的不合理，也可能是SQL本身执行效率比较低。
对企业管理软件而言，比较常见的是SQL写的比较烂，执行效率低，如果实在找不到问题，还可以找比较牛逼的DBA帮忙分析一下。
记得当时有一个写的特别牛逼的查询统计用的SQL，大概有几百行，执行效率非常低，DBA加了几个索引，结果执行效率提升十几倍，立马从分钟级变成秒级。
天生的设计缺陷是很难更改的，这个时候可以考虑采用一些变相的方式提升性能。
比如一些实时性要求不高的查询功能，可以考虑改成延迟查询，引入一些检索服务器（比如Solr），更简单的可以封装成分析视图，效率能显著提升，对用户而言数据延迟并没有什么不适感，反而因为页面加载速度变快了，给用户带来不少惊喜。
（5）主动进行日志分析
刚进公司，我们处领导召集我们开的第一个会，就是作为维护开发工程师，如何实现系统主动维护？
答案就是写程序监控日志，每天把异常日志发到自己邮箱里，当出现问题时，主动修正，不要等用户发现，等到用户使用发现问题了再来找你，可能就是大事了。
特别是针对刚上线的接口程序，因为涉及到外部系统交互，就算是前期联调的再好，也可能在上线后出现问题，这个时候提前把监控日志写好，出了问题就能及时处理。
这些是我进入IT行业第一年，作为一个维护开发工程师的一些心得，因为时代比较久远了，很多细节的东西想不起来了，但一些做事的方法，大家如果觉得有用可以参考。
今天就写到这吧，改天继续......
