以下是我最近跟朋友分享過去開發系統的一些注意事項。今天想想趕快寫下，以後有空再根據這些點多寫些東西。

1 文件議題

1.1 任何寫下、紀錄的過程都是文件，包括程式。
1.2 文件內容要有 style。
1.3 文件的變遷要有紀錄，越豐富越好。
1.4 所有文件如同安置於文件櫃中，放置方式要有style。
1.5 好的文件style可以讓讀者一通百通。
1.6 具備style讓日後的讀者(包括自己)不僅容易讀也容易去推論文件內容的意義。

2 程式結構的觀點

2.1 程式內可以reuse的地方不只要思考區隔出來變成副程式、macro expansion、global/local定義區、…，更要思考是否發展成library的形式。
2.2 在library裡的副程式都盡量各自包含獨立測試模組及預計答案。
2.3 在系統migration時可以經由self-test預先檢測及診斷問題。

3 Use cases 應被納入系統測試的當然條件

3.1 Ues cases 是系統開發重要參考。
3.2 系統設計好後，應將use cases列為必要測試項目。
3.3 測試不必等到系統完成，即可善用use cases檢測發展變遷。

4 系統的 message output

4.1 不僅是output message，也應考慮如何使得message具有reuse的機會。
4.2 傳統message output多以系統開發維運角度來看，常是一小段訊息。
4.3 應考慮message在log spooler裡是否可以任意取一份或幾份message即能分析系統狀況。
4.4 所以，訊息不是僅僅傳送一小段資料，更應考慮整體結構性或具語言結構以利日後再使用的彈性。
4.5 亦即message的表達是有順序、語意的。
4.6 Message reusability 應該也是系統發展時要被設計的重點。

5 Benchmark 議題

5.1 面對問題時，要找出重要核心元素、系統、子系統是甚麼。
5.2 Benchmark 要根據三點不動一點動的原則去偵測元素在系統或子系統裡action的performance。
5.3 收集測試數據、測試條件、測試目標並暫訂為標準值。
5.4 標準值可提供日後檢測系統/子系統表現及診斷問題的參考訊息。
5.5 累積benchmark資料有助於系統檢測及系統migration議題。

6 標準測試點議題

6.1 在每一個系統/子系統裡針對重要核心元素特別設計一個很小的dummy測試點，可做為日後特別需要時蒐集系統狀況用，並可與原先 benchamrk 的標準資料比對，分析系統運作狀況。