U21 根本的建立(7)──知識庫的使用功能

反應快的人主要是因為接觸到的知識被“記憶”、被“分類”、且有“適當的關聯”，但是這對於公司而言這只有少數人能具有，況且每個人的記憶都分散而難以同步、使用。對一個開發團隊來說，知識庫就像是將大家腦中的知識聯集起來作組織化的存放，同時又要讓每一位成員快速地找到自己想要的資訊。由此可知知識庫若應用到極致將會是多麼有生產力。

“將所有的資訊作組織化的存放”是第一個功能需求。談需求時我們總希望客戶直接提供百分之百的詳細規格，但設計知識庫卻不可能有這種東西。依建立的日期時間依序存放是比較理想的方式，而且所有的資訊只放在一個表格裡；雖然建立一些分類分開存放也是不錯的點子但是那都可以藉由關聯作出分類，同時“唯一存在”的儲存位置也較易於管理。有存放就會有CRUD連帶需要的子功能。

“儲存的資訊有最適切的關聯”是第二個功能需求，這也沒法列出詳細規格。如同關聯式資料庫的表格定義，每一種關聯都應該為之建立一個專屬的欄位，在分類搜尋時才能找出符合條件的集合。知識庫要具有哪些特性、各要怎麼定義才會使所有資訊之間有最適切的關聯？這是相當值得研究的課題。

“能迅速找出符合條件的所有資訊”是第三個功能需求。存放與關聯都作過良好定義的話，這個需求看來只需要在UI的使用便利性下功夫就會有良好的成效。“全文檢索”是另一個好用的功能，但考量到技術層面倒也不是非做到不可。

“每一則資訊的變更歷史”是第四個功能需求。可追溯的變更是重要的潛在需求，在查到資訊的同時應能另外顯示該則資訊歷來的編修記錄；感覺起來很像是程式碼的儲存庫功能。這對使用者來說並非必要，但是對於維護功能卻需要藉此追溯記錄。

註：同事說部落格裡的內容實在太多，應該安排更容易上手的分類。若把部落格視為知識庫，每篇文章依照日期時間逐一放入到這唯一的儲存區；目前欠缺的就是依照學習需求分類的關聯索引，這也表示所以文章的標籤必須加以重新編排。