受前任領導臨行託孤，結果LOD項目，由於涉及干係故將全名隱去，且做LOD。然而，該項目本身帶有不少研究性質，故而可能需要稍動腦筋進行解決，或方案取巧或結果可人，然而項目交付性質偏重，所以當時權當鍛鍊一番爲目的因而選擇不少新鮮技術，由此爲課題結項埋下隱患。
項目已經兩年，與相關參與方溝通過兩次，由於直接利害關係不明朗，所以溝通過程場面話居多，不過交流的過程中也可以看出來他們是比較希望項目能繼續開展下去，然單位目前尚無投資意願，而我們也屬於人少事多並且需要自活，有這樣的發展模式註定此項目必將結項夭折，從這個角度看深做意義不大，如果有興趣就另當別論。
在項目過程出現了很多啼笑皆非之事，生氣時殺人的衝動亦有之。軟件工程講究過程循序漸進、漸進明細以及與計劃相結合，然而似乎這一年的工作一直是混亂的狀態，所以每每制定計劃皆難以完成，同時負責事情多樣，從需求、設計、測試、系統、運維、推廣、營銷、研究，以前曾自詡要成爲全棧工程師，去年負責的工作似乎不少超出了工程師的範疇，變成了全能XXX，然而，全能亦意味着全不能，經過這一年雖然綜合素質有所提升，然而關鍵技術似乎略顯下降，故而借LOD之機鋒利一下自己。
LOD的需求，一直是一個神祕的話題，似乎除了我之外每個人都是需求方，每個人對功能都有多多少少的看法，這裏應該那樣，那裏應該那樣。需求蔓延現象較爲突出，沒有一個合適的角色能進行收斂，或者說一個主要的人進行全程跟蹤，做的是一個人、想的是一個人、最終結項是另外一個人往往會導致程序員死一般的糾結。然而LOD在需求之前顯然還缺少定位，爲誰而做，他們需要什麼，這個似乎一直都很讓人疑惑，這也是導致需求蔓延的一個重要原因，需求引導一個人完成界面及演示，當最終結果及開發過程無法掌控時，之前的工作顯然是白做的，故而幾經週轉LOD項目之前被認爲差不多做完的開發被完全捨棄，重新來過。
先需求、後設計，經過一番實驗後發現新技術能從一定方式上滿足我們的需求，先用着試試，由此開啓了一套不歸路，ElasticSearch+Neo4J，非主流的數據庫合到一塊了，圖數據庫對關聯方式顯然是有用的，然而比較簡單的開發方式需要藉助實體，這就導致在進行系統開發的過程就受了不少約束，應用實體後圖的性能沒有發揮出來，只好用JSON+Abstract Class進行跨類描述與關聯，同時要求不同的類可以進行自描述，這樣在前後端可以自由穿梭，同時前端的頁面展示也可以通過配置實體實現自動化關聯，然而設計很豐滿顯示很骨感，有其中一個本體沒有符合標準的作用，從此以後就不斷地帶着這個修正的屬性四處奔波，同時由於檢索過程來自於ElasticSearch與Neo4J兩個方向所以需要對不同業務的數據源進行判斷從而增加了不少代碼量，此外Neo4J與ElasticSearch選用了自動配置同步的方式，大概看了一下同步接口比較簡單，就是寫的時候直接觸發，然而沒有對逐漸的判斷和優化，必須組成新的字符串進行統一掃描與選擇，這樣就導致ES中的倒排索引的結果難以預料，再加上古籍大體上都是單音節詞，故而分詞變得也不現實，同時Neo4J在處理繁體字的時候有時也會罷工，所以所有系統統一使用簡體進行查找搜索，在必要條件下構建文檔庫進行ID關聯繁體文檔，然而在這之前項目已然結項故而按下不表。
隨着項目進行，需求變過、定位變過、設計變得更多，由此導致代碼量極度膨脹，由於採用動態方式組裝代碼，也就近似於所有代碼都是手動進行寫的，並且圖數據庫無法像關係型數據庫讀取那樣簡單粗暴（主要還是不熟），由此導致問題多多，在每次修改的過程中拆東牆補西牆，同時無法得知下一次需求是什麼時候，故而一點點修復，一點點完善，代碼也因此走上了無法重構的道路，當重構的代價高於重新開發的代價時，如果你還想着重構，那麼要麼你是天才，要麼你是妖怪。
所以，該項目在開發流程上不斷循環需求，在管理過程上時間和計劃無法嚴格控制，從而項目管理的角度來說這應該是一個失敗的項目，項目開發過程中的需求和技術的隨意性太大，當然我也因此付出了慘痛代價，項目結題前一個月四個通宵，才把一個殘次品交上去。如果當做一個失敗項目的典型，這個項目實在是太成功了，它也許將會當未來項目的一面鏡子。還是那句話，當發現一再蹉跎時，你發現增長了教訓。
PS：看到醜陋的格式，覺得以後發博客有必要使用MarkDown了。。。
