这个功能在功能上终于做完了

回想这个功能感慨万千大致梳理下慢的原因，算是找借口，可以加班啊

（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>就不会生效

 

是不是有拖延症啊