受前任领导临行托孤，结果LOD项目，由于涉及干系故将全名隐去，且做LOD。然而，该项目本身带有不少研究性质，故而可能需要稍动脑筋进行解决，或方案取巧或结果可人，然而项目交付性质偏重，所以当时权当锻炼一番为目的因而选择不少新鲜技术，由此为课题结项埋下隐患。
项目已经两年，与相关参与方沟通过两次，由于直接利害关系不明朗，所以沟通过程场面话居多，不过交流的过程中也可以看出来他们是比较希望项目能继续开展下去，然单位目前尚无投资意愿，而我们也属于人少事多并且需要自活，有这样的发展模式注定此项目必将结项夭折，从这个角度看深做意义不大，如果有兴趣就另当别论。
在项目过程出现了很多啼笑皆非之事，生气时杀人的冲动亦有之。软件工程讲究过程循序渐进、渐进明细以及与计划相结合，然而似乎这一年的工作一直是混乱的状态，所以每每制定计划皆难以完成，同时负责事情多样，从需求、设计、测试、系统、运维、推广、营销、研究，以前曾自诩要成为全栈工程师，去年负责的工作似乎不少超出了工程师的范畴，变成了全能XXX，然而，全能亦意味着全不能，经过这一年虽然综合素质有所提升，然而关键技术似乎略显下降，故而借LOD之机锋利一下自己。
LOD的需求，一直是一个神秘的话题，似乎除了我之外每个人都是需求方，每个人对功能都有多多少少的看法，这里应该那样，那里应该那样。需求蔓延现象较为突出，没有一个合适的角色能进行收敛，或者说一个主要的人进行全程跟踪，做的是一个人、想的是一个人、最终结项是另外一个人往往会导致程序员死一般的纠结。然而LOD在需求之前显然还缺少定位，为谁而做，他们需要什么，这个似乎一直都很让人疑惑，这也是导致需求蔓延的一个重要原因，需求引导一个人完成界面及演示，当最终结果及开发过程无法掌控时，之前的工作显然是白做的，故而几经周转LOD项目之前被认为差不多做完的开发被完全舍弃，重新来过。
先需求、后设计，经过一番实验后发现新技术能从一定方式上满足我们的需求，先用着试试，由此开启了一套不归路，ElasticSearch+Neo4J，非主流的数据库合到一块了，图数据库对关联方式显然是有用的，然而比较简单的开发方式需要借助实体，这就导致在进行系统开发的过程就受了不少约束，应用实体后图的性能没有发挥出来，只好用JSON+Abstract Class进行跨类描述与关联，同时要求不同的类可以进行自描述，这样在前后端可以自由穿梭，同时前端的页面展示也可以通过配置实体实现自动化关联，然而设计很丰满显示很骨感，有其中一个本体没有符合标准的作用，从此以后就不断地带着这个修正的属性四处奔波，同时由于检索过程来自于ElasticSearch与Neo4J两个方向所以需要对不同业务的数据源进行判断从而增加了不少代码量，此外Neo4J与ElasticSearch选用了自动配置同步的方式，大概看了一下同步接口比较简单，就是写的时候直接触发，然而没有对逐渐的判断和优化，必须组成新的字符串进行统一扫描与选择，这样就导致ES中的倒排索引的结果难以预料，再加上古籍大体上都是单音节词，故而分词变得也不现实，同时Neo4J在处理繁体字的时候有时也会罢工，所以所有系统统一使用简体进行查找搜索，在必要条件下构建文档库进行ID关联繁体文档，然而在这之前项目已然结项故而按下不表。
随着项目进行，需求变过、定位变过、设计变得更多，由此导致代码量极度膨胀，由于采用动态方式组装代码，也就近似于所有代码都是手动进行写的，并且图数据库无法像关系型数据库读取那样简单粗暴（主要还是不熟），由此导致问题多多，在每次修改的过程中拆东墙补西墙，同时无法得知下一次需求是什么时候，故而一点点修复，一点点完善，代码也因此走上了无法重构的道路，当重构的代价高于重新开发的代价时，如果你还想着重构，那么要么你是天才，要么你是妖怪。
所以，该项目在开发流程上不断循环需求，在管理过程上时间和计划无法严格控制，从而项目管理的角度来说这应该是一个失败的项目，项目开发过程中的需求和技术的随意性太大，当然我也因此付出了惨痛代价，项目结题前一个月四个通宵，才把一个残次品交上去。如果当做一个失败项目的典型，这个项目实在是太成功了，它也许将会当未来项目的一面镜子。还是那句话，当发现一再蹉跎时，你发现增长了教训。
PS：看到丑陋的格式，觉得以后发博客有必要使用MarkDown了。。。
