从2015年5月到2016年5月，已经维护整一年。对于维护这件小事，是怎么都爱不起来。2014年12月到2015年3月，短短几个月的开发经验，不足以面对浩瀚的代码世界，想要展翅高飞，除了多锻炼让翅膀丰盈，别无他法。
日常维护，对于数据库的增删改查，平均每天面对来自各个方向的30~40条记录修改。常用SQL语句放着，日日ctrl c+ ctrl v 。这是个，有你没啥用，没你又不行的位置。对，充其量就是个人手，连人力都算不上，更别说算人才了。
总结维护一年的个人感悟。维护三步走：
一、熟悉业务熟悉系统。免不了先看各种文件，看系统，把各种流程亲自过一遍。熟悉业务流程、熟悉系统。熟悉到什么程度，没人 给你标准，大家都不知道60分在哪里，所以，还是得靠自己。关于熟悉系统这个问题，个人认为，系统既然已经做出来了，最熟悉它的是架构师其次是开发核心人员，当然，他们一般都没空教你。开发核心人员，简单指对系统有个整体了解，知道系统的整体框架，以及各个表结构以及功能点。一般开发人员，这个基本可以不用问，一般开发人员，是在核心建好框框之后，在自己的一亩三分地辛勤耕耘的孩子们，对整体框架没有完整了解，但是解决小问题还是很靠谱。我是经常问过，到底什么是熟悉系统啊，标准是什么，然而并没有人回答我，因为这个没有唯一标准。举个具体的例子，熟悉系统，就是熟悉每个功能点具体是做什么的，哪些可以操作，哪些是不可以操作的，每个页面都有什么内容。这是第一步。当别人问你，系统是用来做什么，系统有什么主要功能的时候，起码能回答得上来。
二、解决具体问题，熟练掌握SQL，熟悉每个页面字段所属表以及表结构。维护中总是会遇到很多稀奇古怪的问题，首先得在自己手上有个预判断，哪些是用户操作错误出现的问题，哪些是数据错误的问题，哪些是属于系统问题需要告知开发人员进行修改的，学会辨别。不要每次遇到些问题就跳跳跳找开发人员改，他们铁定会烦死你，当然，能够自己解决的就不要麻烦别人，前提是，不会的一定要问啊。不会要问，这个很重要，自作主张改改改，改完了才发现错了，系统数据恢复不回来，这个就大头了，万一跟新闻那小哥一样，把一公司删没了，就不是个简单的问题了。也出现过一个比较自信的小哥，自己改了东西不打招呼，害得系统瘫痪了，通完篓子最后还不是维护人员继续给补的，一堆人怨声载道，这样也不好。这个就是方法问题了，首先得先问过，确定了就放心大胆去做吧。具体说说熟练掌握SQL问题，首先，摆出E-R图熟悉表结构，这个就需要具体知道，哪个表包含哪个字段，哪个字段对应哪个页面的问题。反过来，在熟悉页面的情况下，要知道每个页面内容包含几张表，页面上的这些数据是存在哪个表哪个字段的。如果有代码更好找，F12可以查询页面代码，但是查不到表结构。目前根据页面还没有能连到对应字段对应表的查询方式，我也只能在积极想办法中。维护系统出现的基本都是数据问题，对应页面数据表与数据丢失，都能通过直接操作数据库得到恢复，正常情况下。维护遇到一些的的确确是系统问题，就要联系开发人员修改代码了，比如，不合规范的弹框、不合业务逻辑的操作方式、操作后没反应这些问题，都需要代码改。进一步，维护人员如果可以动代码，会给大家带来很多方便。
三、修改代码。维护人员在维护过程中，已经知道问题大致会出现在什么地方，哪些需要完善的，可以亲自去修改。基于已经熟悉了SQL以及系统数据的表结构基础上，可以把势力范围延伸到代码，熟悉代码可能需要一点时间，但是熟悉了基本系统框架后，找起问题来会变得特别迅速。可能会出现改错或者部署不上去的问题，没关系，还是要勇敢迈出这一步，这样才可以进步。维护人员向一般开发人员的迈进，第一步。
表示现在还在第二与第三步的过渡，过程是向上的，这样很好。