U22 根本的建立(8)──知識庫的維護功能

使用，是根據現有物件的放置方式加以運用，但是有用的物件要存放到指定的位置需要將原本散落在各種文件裡的有用內容收集到指定的存放位置。在有用物件與儲存庫之間的關聯，就產生了各種維護功能的需求。

“從各種文件裡取得有用的資訊放入知識庫”是第一個維護需求。這個需求要成立的前提是必須能夠定義總共有哪些文件與每份文件的格式，CMMI或ISO導入的可以有效地在分析開發流程的同時固定所有產出文件的數量與格式。我們可以想像若是文件的數量與格式不停地變動，這個需求根本不可能完成。另外收集的資訊應註明作者與出處以便未來可以追溯來源，因此在收集資訊的同時也要額外收集這些欄位。

“資訊放入知識庫前需要被review”是第二個維護需求。如同程式碼在放入儲存庫前有同步比較差異的功能，收集的資訊也應該有類似的機制加以比較篩選來避免重覆或是無用資訊的問題；這也表示我們需要一個資訊暫存區與比較的設計。現在網路上有些討論區或留言版由於無法過濾內容且採不記名方式，因而存在了非常多的垃圾留言，這種現象一定要避免。

“每個版本的產生要追溯出有哪些變動”是第三個維護需求。就像標準的文件異動時要額外列出內容變動列表、系統更新版本時列出程式異動清單那樣，知識庫的維護也應該要有類似的記錄。維護記錄也必須具備不同的查詢方式以滿足針對版本、時間、作者、來源……等等不同面向的查詢。

“每個單位將有用資訊集合為中間檔提交review”是第四個維護需求。公司進行的專案可能四散在不同場所（全球化的公司也會如此），在資訊的同步必然會有衝突或是連線上的問題。讓每一個開發團隊都能事先抽取要進入知識庫的內容交給特定單位同步與review，會有集中處理的好處；而且具備中間檔的好處是在未來可以任意變動資料的來源卻只有很小的影響。

一切聽起來都很理想，不過從文件抽取內容很簡單，但是該如何從程式碼裡抽取有用資訊呢？或者說，因為程式碼的變動性過大，我們應該從程式碼裡抽取資訊嗎？