我提交的代码准备好了么？其实这算是一个老生常谈了，对自己而言也绝不是第一次遇到了。之所以再说，可能是因为感觉这个现象非常的有意思！从中可以窥见很多作为一名程序员必须具备的细节素质。
再次把自己的失误拿来分析，我需要处理下面几件事：数据表修改 -> 调整存储过程 -> 调整数据访问层 -> 页面调用修改。类似这样的需求，我们应该经常遇到，按照顺序进行修改，最终通过调试页面来查看修改是否正确。将准备好的数据输入，执行，返回了预期的结果，OK，修改成功！再次按照顺序将所有的修改内容更新到代码服务器，签入前的版本对比是个必不可少的关键步骤，之所以关键，是因为如果因为偷懒没有对比代码的变动，而错误地覆盖掉别人上传的代码的话，相信过不了很久，就会有人找上门来“讨债”，相信每个人程序员都有过这样的经历，但是很少有人对此十分享受吧……
但这样就能保证我们提交代码的质量么？还有那些“陷阱”会导致我们的疏忽，从而造成上传“不健康”的代码呢？
（1）对自己的代码过于自信：这条很容易理解，同时也是最容易造成签入“问题”代码的元凶，之所以这么说，是因为其中不仅掺杂了自信，同时也夹杂着偷懒的成分，尤其当手头有很多内容需要处理的时候，很容易不按照套路出牌，其中也就隐含着一些潜在的问题。处于一般开发流程中可能还不会产生太大的影响，及时发现及时修改，但是如果再项目的后期遭遇这些潜在的问题，那弥补的成本可以难以衡量了。所以，必须从个人的态度层面来把好这一关。
（2）代码分支的正确性：越简单的功能函数越不容易出现问题，这可能就是无数大师所说的“简单才是王道”吧！就自己的过往而言，很容易陷入到复合型功能的陷阱中，自以为“简单的函数缺乏技术含量……”，很肤浅的理解哈。但相信还是有不少人会这么去想的，那么对于这些复合型的功能函数，要求我们的测试力度可不是简单的1+1=2那么简单，有的时候会搞的人焦头烂额，因为稍许的改动可能使其中的一条通路执行正确，但同时也可能已经将某个条件分支原本正确的通路堵塞，从而造成潜在的bug。那怎么办呢？一方面，我们需要尽量保持我们函数的功能专一性，如果有特殊需要，一定要保证将所有的条件通路都进行实际的调用测试，以保证整个函数的可用性。
（3）特殊应用情境的适应性：这一条有些类似于上面的第二条，但是略有不同，我相信在任何系统中都会有一些非常规的设计部分，其中也会涉及一些看似“怪异”的功能模块，里面可能有一些很难理解的处理函数，这样的情况，我们姑且称之为特殊应用情境，一旦修改这样的功能部分，我们除了谨慎、谨慎再谨慎之外，同时严格保证另外一件事：必要的修改注释。这里之所以强调注释的重要性，是因为对于很多常规函数来说，我们调整后，很容易被别人理解，能挂上注释固然好，但是如果没有也无伤大雅，但对于这样的特殊应用场景可就是另外一片天地了，回想自己也曾因为只读懂了局部代码就进行修改，然后造成系统瘫痪的经历，注释不仅可以帮助别人更快地理解你的代码，更可以提醒你某某时刻你到底做了什么。
（4）复合型函数的逻辑正确性：分支嵌套分支，于是有了更加复合型的功能函数，如果可以，请远离这样的实现方式，如果绕不开，那么我们需要硬着头皮做好几件事来保证进行高效正确的修改。首先，通过换行符或注释将最外层的分支进行划分，然后针对其中的每一个分支进行检查，这里之所以要强调逻辑正确性，是因为嵌套的逻辑往往会超出我们大脑的“快速通路”，啥叫“快速通路”？对于一些常规、步骤有限的功能，我们可以快速地通过大脑思考其正确性，但是如果步骤过多，或者逻辑复杂的部分，会明显增加我们思考的负担，你可以借助白纸黑字或图表的形式来进行压力分散，但貌似大多数人不会这么做，自己就很多次体会到这种勇敢带来的痛苦……这时，请一定要按住自己的耐心，逐层划分，尽量利用快速通路来判断逻辑的正确性，表面上看，可能浪费了一些时间，但从实际效果上看，你收获的是高效和高质量。
（5）被屏蔽的异常：我们都喜欢添加try-catch异常处理，有很多的项目组还特别强调一定要添加这样的异常处理，但大多数的时候，我们都只是添加的异常的获取（还是很少进行异常区分的一把抓模式），最多也就写个日志，然后就不了了之了。于是问题出现了，用户操作后，没有任何反应，程序肯定是没有正确执行，但是看上去好像又没有错误，后来发现，原来是有异常，但是被我们抓住后但没有处理，于是虽然该函数没有返回正确的结果，但返回的结果也没有造成系统的崩溃，于是就有了前面的一幕，这样的问题其实不太容易发现，但同时也提醒自己，如果要进行异常处理，就要做到细分、记录和处理三个环节，否则就会给bug留下可乘之机。
关于更新代码，自己一直想写点儿什么来提醒自己，如果有所遗漏，还请大家多多拍砖~