我曾经也维护过别人的代码，也是什么文档都没有，连操作使用帮助都没有，更别提详细设计说明书和表结构，代码当然没有什么注释。我并没有去整理表结构说明。幸亏这个人喜欢数据库上倒弄，写了大量的视图和存储过程。视图中有各个表之间的关系连接，也有各个表中重要字段的中文名。这样我就不需要表结构说明了。因为表结构说明不仅需要需要描述每个表中字段的中文含义，也得描述表之间的关系，这和视图能表达的效果是一样的。所以，我现在也建议开发人员写代码，多写视图，多写存储过程。有的老代码，SQL语句都生写在代码中执行，没有视图。对于这样的老系统维护，就是把这些SQL COPY出来，做成视图，这样就好维护了。
对于详细功能设计书，其实对于程序员来说，其目的是想弄清楚业务流程的来龙去脉细节。光直接看代码是很难弄明白意思的，又没有什么其他文档可以参考，所以只能猜测代码的意思。尤其很多维护人员，很多功能细节都是为了处理某些特殊需求和异常业务的，都是以前的程序员写的，但是以前的程序员已经走了，现在的维护人员连软件中具体的这些细节功能都不知道。当新的实施人员或支持人员反馈回疑问，想问问程序员某个细节功能是怎么回事，程序员都发蒙，嗯，还有这个功能也不知道呀。
要解决这个问题，我曾经做过的事情就是组织实施人员写功能操作说明帮助。因为实施人员要给客户去培训讲解，没有帮助说明，只能一张嘴叭叭叭的干说，实施人员是最需要功能操作说明帮助的。但是实施人员认为这个帮助是软件的一部份，而且是开发部开发的软件，开发部最了解功能，所以帮助文档应该开发部写。而开发部认为开发部的职责就是编写代码，你自己培训你连个操作说明都没有，你怎么培训，所以帮助文档应该实施部门自己编写。于是帮助文档谁也没有人写。
归根到底，帮助说明是终究要写的，主要是谁写的问题。谁最有动力写呢施人员最有动力，因为这和他们的工作息息相关。而程序员明显没有动力理由。而且实施人员熟悉第一线客户的素质，理解客户的具体操作思路和理解思路，写出来的帮助客户都能理解，帮助文件才能真正为客户服务。很多帮助文档的写作都是从来没有见过客户没有实施培训过没有客户支持服务过，连软件测试都没有做过的纯粹文档人员编写的，可想而知帮助文档到底能对客户有多大的帮助性。
另外，我还给了他一些关于需求控制的建议。
需求，是很多方面的。有关于功能的（尤其是每家客户特殊的业务需求），有关于异常错误的、有关于性能的、有关于兼容性的、有关于易用性的、有关于特殊权限的、有关于美观性的。
而需求的优先级也不一样。有的客户态度强硬，你必须尽快满足他，否则他就给你老板打电话。
而正是这来自四面八方的各种层次各种看法的人的各个方面的需求电话，把程序员就烦的要命，还要去开发。而且很多都是一个电话就认为程序员能开发了。但往往程序员开发完后，客户一看不是自己最想要的，于是再修改。
所以，需求多，其实是一个幻觉。
第一、把需求分类，做个EXCEL表格，量化解决。这个需求管理表格会有下列这些项：客户名称、需求提出人、提出日期、需求关闭时间、功能模块名、客户现在版本 、需求描述、需求分类（需求、BUG）。我在最初没有需求管理系统的时候就使用过这种方法。过去没有使用的时候，我的手下老叫忙死了烦死了。我就让他把现在手头的事情都整理一下给我 个邮件。但一整理，肯定不超过10件事。有些事情是等待客户给资料，有些事情是调试跟踪不出来错误，有些事情是需求模棱两可。我给他一分析，他现在正在进行的事情就两件，而且都是他自己能独立做的，根本不需要别人配合参与的。他忙吗瞎忙，或者故意说忙。没有工作效果，就是这样。帐不算不清，话不说不明，就这个道理。
有了这个表格，要定期（可能是一周，可能是一月）给老板一份。这表明你的工作量，让他看看你确实一直很辛苦的在工作，而且干了这么多活。而且，这也能看出你工作的仔细负责态度。
有些程序员不做这个表格，也不给老板 告。很多时候是程序员并没有干那么多活，能推则推，能混则混，能拖就拖。怕自己有一天混不下去，所以心理压力很大，每天不干活却总觉得很累。这种累就是自找的。想必一些程序员看到此会想起自己。
对于这位 友的现状，我还建议他开始版本管理。
CVS、VSS之类就不必了。因为这是一个人的战斗。连版本都没有概念，一上来就是特正规的工具，大半感觉太麻烦，又退回到最初原始状态，还对版本管理产生了不好的印象，觉得繁琐还没什么用。所以我们有一句话：一管就死，一放就乱。其原因就是缺乏一个中间过渡解决方法。
所以，我建议先把版本意识提上来，按照版本管理的方法走，走顺了就自然接受了正规的版本管理工具。版本管理工具可以分支，也可以合并，可以针对Bug进行补丁发布，而不发布还未完成的新功能，可以发布为某个客户专门定制的版本，也可以回溯历史版本，对比历史差异，源代码安全性也高。
有几个过渡性建议特别实用：
一、有大的修改或没有把握的修改之前，先把代码备份到其他的机器上。备份目录要跟上日期。
二、在大的修改前，先定一个稳定的版本发布出去。很多程序员没有版本这一概念，每天都在持续修改。结果，给客户的，每个都是半成品，有半拉子没有修改完，还自己没有做屏蔽处理。客户不小心用了，产生了错误，再告知千万不能用这个功能，还没有完善。但晚了，错误数据进入了，以后 表平帐就是问题了，又得特殊数据特殊处理了。自己的孽障自己还得解决。
三、即使是琐碎的修改，也要每天或隔天备份一份源代码，别怕代码多，现在的硬盘大的很，而且备份复制一下也就是5分钟的事情。别怕每天备份太烦。我们经常会遇到这个客户让改了，另外客户不让改。一个功能改了又改回去，但过去的源代码没存备份，忘了怎么写了，这时候你就想起代码备份的好处了。尤其现在有不少免费的文件同步或文件自动备份的软件，都能定时做。功能还强大，有些还有些差异备份的功能
四、现在有不少文本对比软件，如WinMerge之类。可以对比两个文件的差异，这个功能和版本管理工具中的源代码差异对比一样的效果。
五、如果每次发布新版本，就把从上一版本发布之日之后的关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。这样即使没有人写更新说明文档，根据追溯也能明白这次版本解决了哪些问题和需求。很多程序员没有需求管理表格，版本发布要求写更新说明文档，这才从脑海记忆中想，想的就有些遗漏，甚至错误。好多程序员有过这些的情景：我记得改了呀。真正一翻代码，一点没动。大叫：我的代码怎么没了，我记得我改了呀。
我这些建议，从需求描述、工作量管理、遗留系统代码重构技巧、备份管理、版本管理、更新说明文档一整套说明了一个人如何维护老系统的工作方法，但希望能分享给大家，给大家以帮助。
有方法，你就不是一个人在战斗。
一切皆有可能。
相信自己。
文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树数据库组成表31415 人正在系统学习中 相关资源：功能强大的紫微斗数软件易排盘.紫微斗数V3.0_倪海厦紫微斗数排盘…
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！