前言

       最近一直在做修改bug工作，修改bug花费时间最多的不是如何解决问题而是怎样快速读懂代码。如果代码写的好的，不用debug就可以一眼看出来哪里出了问题。实际上，我都要debug好多遍才能差不多理解这个业务逻辑，进而分析原因以及修改修复的代价。这项工作花费了我绝大部分的时间，而且并没有什么意义，因为fix bug之后就再也不会处理这些代码了。

       因此，易读性应该放在代码的首要位置，如果长期维护的话。

1.好的命名规范和良好的注释

       不应该鄙视if，因为这是业务发展过程中代码的补充。突然换了需求，又不能丢掉原来的代码，只能if。随着时间推移，问题也就出来了。应该想着去换个设计模式去重构这段代码，而不是赶时间加一个if，这个在后期维护中是代价极大。

2.讨厌的if

       if用的真不要太多，debug的时候发现一个if又一个if，if里面嵌套if。也许这是为了逻辑的完整性，但是千万要在每个if分支里都给出一个结束的定义，即这个if结束了，主要做了什么。经常debug if之后还没有理解这个分支是干嘛的，然后去看下一个分支。
3.太多的try catch

       exception的处理基本都是try catch, 然后基于当时的想法决定是否抛出去。当我重新debug的时候，我不知道这个位置抛出去了对上一级是否有影响，不抛出去又会怎么样。

4.肆无忌惮的重构

       遇到大块的代码就提取出来，这是最简单的重构。然而，当你debug从一个方法进入另一个方法再进入另一个方法，回头又跳回来，绝对懵逼。
       重构的时候一定要在该方法领域内完整的阐述功能，而不要为了重构而重构，结果语义不完整，代码很分散。

5.处理json数据    

       项目大了之后，服务分拆成各种微服务。于是，各种调用webservice. webservice返回xml或者json。返回xml的烧了，暂且不提。返回json的，我们明明有jackson/gson等各种json序列化工具，只要建立好model，直接映射过来就好。甚至还有JsonInclude,JsonPropertyIgnore等条件配置。而偏偏很多接口使用一个JsonObject来接收response。然后来一个map方法，调用JsonObject的各个属性的来获取各个值，再手动丢进一个model里。

       到这里，项目中使用org.codehaus.jettison.json来处理json数据，这个框架有个问题，JsonObject.get(key)的时候，如果key不存在，则不是返回null，而是抛出一个exception。我最近修改了两个bug都是因为response中没有这个key而抛出的异常。而response之所以没有这个key是因为webservice那边处理返回结果model不一定。正确的则返回这样，失败了则返回其他字段。而client的这端，没有预料到失败的结果映射，或者说以不变应万变，用exception来反映失败。
       因此，webservice一定要定义好返回的model，失败了，不要一下是warning，一下是message。这样也可以，但要有文档说明你们返回的结果是什么model，client好做映射。client这边最好还是不要手动映射了，妈的出错了debug也很烦。client可以封装多个model，比如正常的model，失败的model。先序列化为正常的，序列化失败则序列化为失败的model。