这个功能在功能上终于做完了
回想这个功能感慨万千
大致梳理下慢的原因，算是找借口，可以加班啊
（1）需求不明确，就知道做从此增删改，但增删改时，都不是对单一表进行处理，但具体细节却不清楚，需要看旧代码
（2）虽是增删改的功能，但需要使用其它集成接口，这些知识点需要与其它团队了解，也需要时间。
说到加班，纠结感又上来了
做这个功能感觉找不到节奏，
一个任务是不分上班下班一口气做完，如果其它团队的接口的不熟悉，应该怎么搞，不会因为要做当前的任务，就把对方相关逻辑代码都看一遍吧，一是没有时间，而是人的精力是有限的；
还是细分，每天完成指定的功能点
节奏是个什么东东呢
中间比较耗时间的地方：
做功能前没有充分预估与其它团队沟通所需要的时间，是否是沟通技巧不熟悉；
一个功能点的实际可能有多个途径，在实现功能时总是在不同的实现中摇摆，各有各的好处，是否是建模不熟练；
项目大了，肯定会有公司内部的接口，
实际建模与接口（譬如persist接口）需要结合起来，如果是使用Map之类的容器作为参数，何必要定义那么多对象呢
OO可提高代码的语义表达力，如果由于OO增加代码逻辑的复杂度，应该怎么取舍呢
单一处理和批量处理在不同场景，是写两套代码，还是复用处理逻辑，如果复用，如何建模，模型的复杂度应如何评估呢
一来一去，这一想，那一想，时间过去了
Just do it:
在没有完成功能前，
不要说简单，如果要使用第三方或其它团队提供的接口，谁也不知道会有多少坑
不要说不需要多少时间，没有调通之前，谁也不知道有多个技术方面的或业务逻辑方面的坑
累的时候可以停一下，但如果操作一定要保持头脑的清醒，不能因为乌龙操作产生的结果来影响判断，一来一回，时间就过去了
排查异常情况的一点经验：
（1）如果是突然出现的异常，一下子找不到原因，先分析正常时的与现在不正常时，两者不同的地方（在多数情况下可能因为对一些细节不了解，导致认为没有差别，实际是有的），参数，线程等方面
这次就发现一个情况，HashMap<String,String>中存放["2","value2"]的键值对，如果通过RMI在逻辑上传输，数据到达接收端["2","value2"]中key中的2就是Long型了，虽然转型为HashMap<String,String>也不会错，但在Entry.getKey时就会出现java.lang.Long不能转型为java.long.String
（2）不要简单全部相信其它团队提供API的描述，有时候虽然参数是Object，但可能只有传入HashMap<String,String>才正确，HashMap<Long,String>就不会生效
是不是有拖延症啊