wayLocation日记2
wayLocation 本地方法测试工具开发日记2
本章记录了开发过程中，各种碰壁体验
关于需求分析
项目的前期是最煎熬的，没人帮想需求，这也代表了自己需要非常非常的注意到小细节，不在开发中走过多的弯路。 然后因为这次开发的属于工具类别，不是基于数据库结构开发业务。而是从代码底层出发，所以要先在脑中模拟出一个“类数据库”的概念。 好在开发前就已经写好了草略版的需求原型，发现很多很多功能都围绕不开一个东西展开：“搜索库”。 
搜索库概念
以Lucene这样的搜索框架为技术，在应用内构建出应用内容的一套类搜索引擎。 从搜索库出发， 第一步**：生成搜索文档** 任何一个搜索引擎都离不开几个关键字，搜索关键字、搜索内容、高亮、文档。 所以这一步比较简单，只需要设置好需要存储进搜索文档的内容、字段映射，分词就好。
第二步**：选择分词器** 选择分词器的过程是比较痛苦的，因为搜索库基于Lucene，而Lucene从所周知的是分词器垃圾。加之不活跃的社区，所以很难找到符合应用业务的自定义分词器。 所以难在了着，找不到有用的自定义分词器->需要自己自定义->Lucene是国外的，没有中文文档。 所以学习如何自定义分词器是一个很艰难的过程。不过好在通过网络上各类大牛的帮助，还是完成了符合本工具：一字符一字符模糊搜索的概念的分词器。
第三步**：使用** 使用的流程也比较简单，拿关键字->在搜索库中解析分词器的同时搜索关键字文档->返回文档内容。 这样下来搜索库也可以比较简单的拿下，剩下就是优化Io和数据内部处理的细节了。
关于开发痛苦
先不提上面Lucene给我带来的痛苦，我认为本项目的几个难点是：
以上，是印象比较深刻的。 先说关于参数解析这件事。
参数解析
万恶之源的反射
为什么说反射很恶心。 因为在实际的开发中我们是会很少使用他的，所以对于他的很多方法或者属性来说，只能说熟悉。所以在开发的过程中，会碰到这种情况： 嗯，这个我知道，是这样用的->测试，暴毙，出bug->嗯？是这样用的吧，修改毫不相干的地方，继续测试->报bug->.... 就比较遇到这样的场景。 应对方法也只有一种，就是不断的翻看jdk文档、百度、社区问答。
反射难吗 反射不难，难的是他很多拗口的属性名和众人对他方法、原理的一些误解。 比如在方案四的执行过程中，我拿到了一个属性，这个属性是一个List，但是对于程序来说，他应该是一个Collection，当时有一个需求：需要实例出这个属性，并且添加一个空对象进去。 那么就有二个条件了：
- 实例这个Collection出来
- 拿到这个Collection的泛型，new出来之后，迭代解析这个泛型对象。
第一点中，我去社区上问：CSDN 回答都很奇怪，没get到要点。但是自己最后也想通了一下，解决方案也在这个回答里。
第二点，就是不断的看jdk文档和百度的过程。 ParameterizedType这个类和泛型息息相关，这次我也是记死了。
本章完