经验备忘2014年01月

2013/12/30---2014/01/03

1.快捷键的使用
    快捷键的使用时一个非常重要的事情，尤其是eclipse中的查找快捷键。在查找java、xml等文件时，可以使用Shirt+Ctrl+R；全局文件内容搜索时，可以使用Ctrl+H；还有就是实在不行就点击“search”键，然后“File”，里面可以选择要搜索的文件后缀名。当然还有一些比较有用的快捷键，例如Shirt+Ctrl+O，可以帮你迅速导入依赖关系包，并清除不需要的关系包；还有通过搜索名字来得到java文件Shirt+Ctrl+T。

2.调试

    在调试时，主要用到F5，F6，F7和F8几个键。F5是跟踪到方法的内部，F6是单步执行，F7是执行完方法返回到调用此方法的下一步，F8是继续执行到下一个断点结束。在以debug模式打开jetty服务器后，点击前台按键进入后台的java程序，如下图：如果要关闭此次debug，可以点击下列图中这个键。
这个键是非常有用的，特别是在一次调试时前台不断有request请求过来时，点击这个键关闭非常有效。主要好处就是在下次调试时，排除上一次的干扰。在调试的时候，还需要查看程序运行中国的取值。可以依次打开折叠的目录：在很多情况下，需要调试的就是要找出在哪一步，哪个值被取为了null值，要更多的关注这种情况，因为往往是null值使程序fail了。

3.思路，思路纸质化
    2013年最后一天和王聊了半个小时，很感谢他让学到一点一个做需求的好程序员是什么样的，首先你要把思路理清楚。这一点很关键，为什么很关键就是因为你如果没有理清思路，你的脑子就是一团浆糊，即使你自己觉得懂了可以立即开始写代码了，很大一种可能性就是你会陷入重复的困境，写了一点代码，恩觉得应该调试一把，发现有点问题，然后开始改，继续调试，1遍2遍，，，后来发现程序被改的面目全非，好吧索性就还原（想想以前的先辈们没有svn代码管理工具的时候该怎么办），还原的时候发现有部分和第一次的时候是一样的，这时候印象比较深，改了改，调了调，。。。，然后终于成功了一步，发现是因为有一个细节没有考虑到。接下来，进入第二步的开发和调试。有没有发现一个很严重的问题，就是因为没有考虑到一个小小的边界和范围可能就浪费了几个小时，甚至一天的时候。为什么不一开始就理清一个思路用本子记下来，在本子上列好了以后，和你的baby谈论好了以后开始做呢。最起码有一个好处，你从大的方向不会出错，如果你考虑的足够仔细可能你的代码连一个bug都没有。用笔和纸把思路记下来，思路差不多时，在开始coding。在具体纸质化的时候，你要明白你的需求大概会涉及到哪些内容和层次结构。你的改动点在哪里，你的接口和参数是什么。你要设计而不是仅仅是实现。

4.调试代码加减法
    在做报表显示的时候，由于里面涉及到js，这个自己不熟悉也就是去年的时候用过一点点，但是这次又需要用，为了最小范围的改动代码，我选择了复用DO对象，这个对象是前端js可以自动拆装的。实际上证明是可行的，第一个表被我显示出来了。当我第二次在用这种方法时，一直显示不了。延辉后来帮了我，他给我详细演示了减法的原理，就是从外部程序向内部逐步深入。所有的代码在执行的时候，假如到了某一个断点，断点前面执行的是一个集合，断点后面还没有执行的是一个集合（不管程序有多么的复杂，数量是多么的庞大），如果问题出现了，肯定是在没有执行的部分，接下来就是做加法，将未执行的代码最复杂的部分（估计）先删除用最简单的部分代替（hello-word），看看能不能输出结果，就知道问题在哪一块。典型的区间套理论的应该。加法不用说了，就是知道问题了，先还原以前被减掉的代码。调试出了问题的代码。就这样第二个表做出来了。

2014/01/06---2014/01/10

1.webx的依赖注入
    由于在Scout项目中webx是比较老的版本，导致用@Autowired注入失败，必须用setter方法注入，最后查原因是代码复写了注入接口。

2.分页和搜索
    开始以为分页和搜索时很困难的工作，一开始就没有做，后来还是觉得做一下试试看。主要是要搞清楚分页的原理：就是每次根据pagesize和pageno的数目计算要取得的子结构（一个list对象子集，对应的就是标的行对象）。在做的时候要注意获得总的数据数目，bug前的做法是在ots tool类中设置变量，在每一次取得rows时随便计算总数，然后在上一层调用，后来发现这种方法是不行的。主要是有可能出现线层安全问题。最好不要在静态类中设置变的状态量。

3.测试手段
    在测试的时候由于数据少，如果指定某一个custid和dramndn_seqno就是因为获得不到值而无法显示结果的问题。为了不block我的测试，可以改代码，入口在正确的位置，代码经过的逻辑线路也是正确的，只是在条件查询时“篡改”代码让查询的条件变的更加宽松。这样的话就可以获得多条数据记录，测试分页的结果。

4.在使用工具上和大家保持一致
    为了以后少出错误，尽量使用和大家一致的工具。这样在遇到问题时有很多的人可以找，否则，自己一个人去解决花费的时间可能会很长。在和大家保持一致的基础上追求不一样。也不是一定不要标新立异，前提是你对某一个工具非常的熟悉倒是可以打破常规。

5,在写代码是先实现再重构
    一般有了思路后，第一步不是要写出多么漂亮的代码，而是尽量先实现。这样的好处是可以有一个原型可以参考，软件关键是思想。代码的完善可以放在后面来做。编码的指导是：思路--实现--完善。不是一开始就编代码，也不是一开始就要编很好的代码，而是这两者之间的一个折中。

6.代码中一定要保证是逻辑正常的
    意思是即使因为某些特殊的原因，代码中有些已经有变化，主要是在调试代码的时候，为了便于获得结果，修改了代码。这样做有助于调试代码，但是不利于代码版本的控制，如果不小心把代码传到svn上去了，自己有没有发现就会产生问题。一个好的做法是在每一次测试之后，将代码还原回正常的情况，以前的可以写成注解的形式，这样可以在下一次调试时直接取消注解就可以测试了。其实上面的方法只是缓冲之计，真正的做法是在测试环境放入足够有效的数据，这样才能更好的测试结果，也不会影响生产代码，便于维护。最后附上几张图：图一是调试放宽条件。

图二是分页效果图。