自从出差北京后，回来发现人人都忙的一塌糊涂，接手了公司三个特殊版本和一个标准版本的BUG维护工作，
同时也应老大的要求，给其它同事做一个维护经验介绍。花费一下午的时间总结如下，和园里的兄弟们一起分享下，
有不对或者好的经验，不妨一起交流下！
1 全局变量的管理和维系
其实写程序的都知道全局变量的重要性，一个人写的程序，能管理，但多个人写，就不一样了。
往往出现2中情况：1 使用前，没有初始化 2 使用的时候，发现已经过期了。特别是在跨DLL共享，有多个地方需要自我管理的时候，简单的方式是采用全局的管理方式，既在系统各个模块需要调用这个参数之前，先完成初始化工作，其它模块只有使用的权利，没有控制的权利。对于非常特殊的情况，一定要在其中的调用中实现管理的话，最好是采用SELF COPY的方式来独立使用。
2 异常中的异常
写程序经常要处理异常，经验教训让我明白，异常中的异常要特别小心。什么是异常中的异常：就是在try后，处理exception的代码中出现的异常，这样的错误往往带来致命的BUG和意想不到的打乱设计好的处理流程。
3 函数的简单COPY：95%
有时候为了兼容性，需要修改一个函数的功能，修改的地方很少，不到整个函数代码的5%，如果在项目中出现过多这样的情况，会严重影响到程序的可维护性。对于这点，我非常喜欢C#中的interface!
4 多线埕中临界区管理和调度
这个是最麻烦的事情，一般的人是很难说明白WINDOWS的调度机制的，因此要特别慎重的在程序中提高线程的优先级别，否则很有可能会出现你所想不到的意外情况，比如运行时，线程不定时的死掉。对于临界区的管理，最好采用TRY finally的方式来实现临界区的获取和释放操作，因为异常的出现会轻易的打破这种管理原则！借用DELPHI的帮助来说，后续的运行是不预料的。
5 算法的适用范围和限制
有个简单的算法是自动生成一个最大的ID，结果出现这样的情况：将这个算法运用到了生成工号的算法上，自然是错误连连！这就是没有考虑算法的适用范围和限制，ID是数字类型，工号的范围比这个要大的多。
6 修改基础限制定义
无论是在开发还是维护中，对于修改基础限制的行为要格外的慎重。它就象程序的支柱一样支撑着程序的运行。比如号码的复用，先前设计为不容许复用，结果中途做出了调整，这个时候往往只调整的数据的录入，没有调整好输出，比如报表、统计SQL等等。7 什么过程可以算是的原子操作？
在程序，我们经常会碰到一些操作是需要前因和后果联系在一起才成立，这样的过程，可以叫原子，意思就是不可分，比如前面所说的临界区管理！现实情况比这要复杂的多，有一段程序是来需要硬件配合才能完成的，程序员设计如下流程：
1 判断前提条件
2 硬件初始化
3 询问是否进行硬件操作
4 发出指令操作硬件
这断代码的漏洞在3，如果这个时候将硬件断电重启，初始化的工作就会丢失，后续的指令会引发错误的结果，比如操作了错误信息等！这个例子，比较的特殊，但还是很有意义的。它提醒我们，写程序的时候，要更多的考虑实际的应用场景。良好的逻辑有良好的性能，如果上面的流程按照功能封装的方式将2和4封装起来形成一个调用，就不会出现上面的问题！说到这里，感觉和代码封装又联系起来！
7 仅仅是来忽略更新1%
程序的漏洞是什么？概括来说，其实就是IF ELSE或者CASE的处理不充分导致的。最近维护的一个BUG就是典型的这种情况，仅仅忽略了一个错误，就造成用户使用上的错误。
循环：
读取当前数据信息
数据处理
如果成功,提示信息设置为SUCCESS
如果失败,case 1 设置提示,2 设置提示,3 设置提示,4
机器蜂鸣，提示用户操作完成
进入下一个循环
这个代码的错误在于没有为失败4设置提示信息，导致提示信息停留上一个正常的情况上，给用户造成了错觉！
8 判断标准的前后统一
这个问题一般来说是比较好控制的，特别是在代码规模比较小的情况下。在实际的情况中，这样简单的使用有可能会比想象的要复杂，引起这样的问题有两个：
1 CODER的逻辑混乱 2 团队沟通问题 3 标准的制定。这里强调第三点和第二点，在团队保持有效的沟通是非常必要的，否则会带来设计上不必要的开销，甚至严重影响开发进度，对于这点，提一下对INTERFACE的看法，我虽然很提倡在团队使用这样的方式来进行代码对接，但这样的情况只是从技术层次限制了沟通不便所带来的影响，但对于企业或者专业的开发团队，我还是比较推崇有效沟通。 对于第三点，我的看法是如果标准设计的不好或者不能达到要求的话，会引发相关的问题，出现的最终后果就是各个开发人员各自为政，全局标准失去了意义！
