# 開發手冊（草稿）

## 解決問題
1. 新進人員無法通過可重複翻閱的文件來了解專案。只能通過已參與人員的口頭講解，資訊依舊無法達到無痛轉移，甚至需要多次來回。
1. 開發人員對開發中的需求，無法進行自檢，導致測試上的工作量增加。
1. 審查人員無法對所有的需求都有一定的了解，導致審查工作只能針對基礎進行審查，無法對業務邏輯進行審查。

## 原則
1. 任一角色能通過閱讀維護中的文檔，對系統或功能有概念上的了解。不再需要特別重頭解釋一遍。
1. 不同角色間的內容要是同步的。不同角色間的內容應要互相起到自檢的作用。
1. 審查人員應要起到維護文檔的作用。審查人員的通過與否直接影響到文檔內容的正確性。

## 角色描述
### PM
整理原始需求，並撰寫系統和功能的通用描述。以幫助該專案的其他人員根據通用描述擴展其他內容。注意：
1. 擴展內容需以 PM 給出的通用描述為對齊標準。
1. PM 有權利和義務要求其他人員將擴展內容同步回通用描述檔。

## 開發人員
理解 PM 給出的通用描述，細化描述，在實務上設計和實現功能，並根據測試人員編寫的測試用例進行自檢。注意：

1. 細化描述與程式開發應該是同步進行的。
1. 需要與測試人員協調編寫的測試用例，並在完成開發後進行自檢。
1. 功能交付給審查人員時，以 Merge Request 的形式進行交付，並附上需細化描述。
1. 審核人員通過 Merge Request 後，需要將細化描述同步回對應的通用描述檔。

## 測試人員
理解 PM 給出的通用描述，編寫盡量完整的測試用例。注意：

未來相關的模塊被其他需求影響時，可直接通過已編寫好的測試用例來快速確認舊有功能是否有被影響。
1. 供開發人員進行 E2E (End to End) 的編寫。
1. 供開發人員功能開發的自檢。

## 審查人員
根據功能描述和對應的 Merge Request ，針對基礎代碼和業務邏輯進行審核。注意：

1. 審核的面向應有兩個方面：從程式的角度；從功能描述的角度。這兩個方面應該達到自洽。
1. 針對程式的審核應考慮：全局模塊或次相關模塊的修改是否合理；直接相關模塊的修改是否有需要調整的部分；業務邏輯是否有缺漏的地方；

## 相關文檔
## - 系統結構設計
> 參與角色：PM、開發人員、測試人員

## PM
考慮閱讀的對象是參與專案的所有成員。

需要在這份文檔中撰寫系統或是功能的通用描述。

PM 有權利和義務維護這一份文檔，系統或功能設計上的變動需要反應在這份文檔上。也需要追蹤包括開發人員的細化描述和測試人員的測試用例是否隨著功能的新增和變動同步回到這份文檔上。

## 開發人員
考慮閱讀的對象是參與專案的其他開發人員。

針對 PM 的通用描述部分，和 PM 進行協調，並補充上具體的技術細節（細化描述）。

需要評估的部分有：

1. 不了解技術細節的新進或其他等開發人員，能否通過這份文檔了解必要的實現細節。
1. 對於有特殊需求或架構而調整的設計，是否有足夠的技術細節補充。

## 測試人員
考慮閱讀的對象是參與專案開發的所有人員。

針對 PM 的通用描述部分，和開發人員協調，編寫測試用例。

需要評估的部分有：

1. 測試的流程是否能覆蓋該功能所支援的部分。因為這個測試用例會關係到開發人員和測試人員的自檢。
1. 測試用例的描述是否能讓除了開發人員和測試人員的，其他部分的人員也能依照文檔完成測試。

## - 資料庫結構設計
> 參與角色: 開發人員

考慮閱讀的對象是參與專案的其他開發人員。

針對設計並投入使用的資料庫結構，至少留有 ER (Entity Relationship)模型。並對具有價值的部分，或保留有疑問和空間的部分，進行補充性的文字描述。

由於大部分的資料表沒有太多有價值的描述內容，在留有 ER 模型的前提下，增加補充性的文字描述主要是保留下最初設計的想法，方便後續在調整資料庫時，避免衝突到當初的設計。即使衝突到，也能提早知道，並處理兼容性的做法。

## - 開發流程
> 參與角色: 開發人員

*考慮閱讀的對象是參與專案的其他開發人員。*

開發人員在開發需求時，應該遵循的流程。包括 git 的操作，對應文檔的更新。

## - 開發引導(README)
> 參與角色: 開發人員

考慮閱讀的對象是參與專案的其他開發人員。

## - 部署引導(README)
> 參與角色: 開發人員

考慮閱讀的對象是參與專案的其他開發人員。