你快乐一时，我痛苦一世

从业以来，除了刚开始参加了一个小项目的开发，其他时间都进行不同系统的维护工作。期间发现了一些问题，希望对大家有用，避免发生。

1、可能当时开发人员时间比较紧张，发现代码都是从相近功能的模块直接拷贝过来的，只修改了关键处，但变量名呀，注释呀都还是原先，在维护时要不停的查找每个变量的意思，相当费时，最严重的是有时竟然连没用的变量和一些用于临时存储信息的隐藏框都还在，维护时研究这些值的含义，可最终却发现这些根本就没有用，只是当时开发人员没有删掉而已。希望开发人员能够在实现功能后清理下代码，毕竟对于你来说分分秒秒的事，对于维护人员来说就是噩梦。

2、有的方法达到几千行，利用各种变量，各种参数来拼装查询语句，其中注释少的可怜，在各种逻辑中绕来绕去，一会头就大了。我觉得方法最好不要写那么大，虽然写人很过瘾，但最好分成各个小方法，这样也便于维护。

3、数据库中有的字段做标记用，前期开发时状态就几种，都有说明，可随着业务的变化，期间又有多次维护，又添加了多种状态，可当时的维护人员仅仅是完成它的功能，却没有花一点点时间在数据库表上对应字段上留下说明。等到后来人维护时，发现这些不明含义的状态，只能从程序中分析含义。这种现象很普遍，维护人员图一时轻松，却把灾难留给了后来人。

4、不要用怪异的方法写程序，如我见过的一个程序，明明可以这样写

if(){
}else if(){
}else if(){
}...//很多情况

非要写成

if(){
}esle  {
if(){
}else if(){
}else if(){
}else {
  if(){
}else if(){
}else{
	...//不停的套  我看的都疯了  最后一个屏幕都放不下后面的括号了  
}	
}
}

我知道很多这样写法对功能没有影响，但对于维护来说太乱了，明明一目了然的事，却变得复杂无比。


5、这是我刚开始工作时的故事，一个机密信息查询系统，根据用户级别不同，所拥有查看的字段权限也是不同的，所以当时有个字段权限控制模块，我开始的实现是前台写死字段的多选框，后台接收前台选中的字段，可客户对于可选字段总是变来变去的，每次都是改了前台，改后台，很烦。后来头（一般只提要求，不管实现）发现了这个问题，让我将前台显示的字段写到数据库中，然后用程序生成页面，后台写个通用的接收，写时费点劲，但后来维护时只要在数据库中添加、修改数据就行，方便的不得了。这个例子我想说的是写程序时要考虑到后期的维护问题。