wayLocation 本地方法测试工具开发日记3

细节细节！！！最近开发的过程有一些些难受，一个功能点开发的时候感觉很顺风，一直到测试感觉把自己能想到的细节全给补充了。 但是到测试的时候，豁...，从一个小细节，衍生到很多个很多个新场景需求。 还好在可控范围内，按部就班的慢慢的把一个个特殊场景给罗列好了。 于是乎，教训有了呀。 以后，以后在开发这种纯技术力的项目，一定一定先把各种特殊情况的规则画好蓝图。 测一下一个场景很痛苦的好不好。

收获

本章的主题主打一个收获。 经验： 也是第一次开发这种，没有数据库为结构的工具项目。和平时的某某某系统思路上完全不一样。 首先是以往的功能开发，我走的是：设计表->表关联->开发接口->联动页面的流程。 这样，当我确定一个功能时，表结构清晰，就只需要专注前后端的参数交接以及表的CRUD操作了。 按表开发的难点细节就是，在开发业务的过程中，需要不断注意与该表、该业务有关联的子表或子业务。 需要将开发任务控制在不需要挪动表结构的范围中。 所以数据库开发的项目主打一个业务清晰、业务蓝图。

而这次开发的工具类项目，在没有表结构蓝图的前提下。很多很多思路以及功能点都是抽象的，在动手前只能知道。这个功能大概用这个方法实现，这个参数大概能用，有一种很模糊但又没办法的感觉。 我把这种无力感的原因归咎于**：不熟练的纯代码**。 打个比方。 当我开发解析参数这个功能点时。 按照开发前的蓝图与计划，是这样：定位参数->实例化参数->判断是否是项目内对象->迭代解析其属性，循环第一步->属性赋值。

大概就是一个，迭代一个对象中[入参]的所有属性，如果属性是对象就循环迭代... 很简单，无非就是 啊 ，拿到参数的class，循环他的field，实例他newInstance，哟这个是项目内对象，那就继续迭代解析这个对象，这个对象解析完了，好，把他设置到入参[对象]的属性中field.set(obj,o)，转换一下json直接返回出去。

但是哦，但是哦

不多言，就直接说遇到的这些场景，这些是在蓝图期间没想到的：

1. 当入参对象是基本类型时
2. 当入参对象中抽象属性:接口或是抽象类时
3. 当入参对象的属性是抽象属性时
4. 当入参对象是集合元素时
5. 当入参对象是集合元素时，且他的泛型确定
6. 当入参对象是集合元素时，且他的泛型确定，但是泛型属于抽象属性时。
7. 当入参对象为包装元素或且属性时包装元素
8. ....

但接触到第一个场景，且很轻松解决时，他又来了第二个，慢慢的出现第三个。我不仅停下了进度，重新审视了这个“清晰”的蓝图功能。 所以在第二开发时，重新推翻了很多，因为不仅这个，在重开发的过程中发现其子功能或是涉及功能有更优化，或是特殊场景出现。 比如：原搜索库文档，Document存储的是className，methodName，param，returnParam，id。而且因为当时知识缺薄，所以把入参、出参类型全部都转换为String，以逗号分割。 到现在，Document存储的是一个完整对象MethodInfo的Json格式类型，并且出参和入参都直接以Class[] 形式存储。 这是再首次开发中完全没注意到的知识点，既然lucene文档只好存字符串，那么就存Json的对象就好。而且以Class形式存储出入参大大方便了很多功能点的简要开发。 并且在重新审视的过程中，仔细分析各模块调用时，可以明确的感觉到对于Service模块和下流模块[dao或是domain]等等模块的位置功能。 所以这次没有CRUD的工具开发经验，对我来说真的又是一种突破。 具体的说不上来，但是以前的自己是想不到现在的自己开发的，不涉及CRUD开发的项目来着。 所以，我变厉害了

总结

虽然是想到什么就写什么的自开发日记，但是感觉还是有总结来着。 为期两周的wayLocation 本地方法测试工具，我收获到了：

• 变大变强的抽象能力：指的是蓝图设计以及处理复杂逻辑的能力
• 冷门知识的补充：指的是反射冷门应用和抽象属性的冷门工具等等
• 耐心：指的是发现蓝图设计不对，直接推翻重写功能点的那一刻。
• ....