專案的技術組成

專案分析

在開啟一個專案前，我們需要釐清專案涉及到的領域，並精準分析每個領域的需求，這樣才能夠確保專案的成功。

如果我們上一章提及的「公車 APP」一樣。

但實際情況是，我們的 AP 往往都非常複雜，不會是那麼「單純」的，你可能需要和不同的「已存在」或「不存在」需要實作的系統做互動，這時候我們就需要釐清我們的專案涉及到的領域，從需求的切入點，來分析我們的專案。

領域的組成

這裡的領域分析和管理篇說的「領域」不一樣，我們這裡說的，都是業務相關的，就以一個「打卡」系統為例。

打卡系統，我們可以分析出以下的領域：

• 考勤系統：這個系統是用來記錄員工的打卡紀錄，並且計算員工的出勤狀況。
• 請假系統：我們需要知道員工的請假紀錄，也可以在線上申請請假。
• 薪資系統：根據員工的出勤狀況，計算員工的薪資。
• 員工系統：必須要有一個系統，來管理員工的資料，包含員工的基本資料、員工的薪資資料。
• 人事系統：需要知道員工的主管是誰，員工的部門是哪個，員工的職稱是什麼。
• 設備系統：是設備系統會連動打卡系統，如果設備出錯，就會通知對應的人員。
• 報表系統：需要有方式，來產生員工的出勤報表。
• 統計系統：讓管理者可以看到員工的出勤狀況，並且可以做統計。
• 通知系統：可以通知員工，員工的請假狀況，或是員工的出勤狀況。
• 訊息系統：可以讓員工在上面留言，或是管理者可以在上面發布訊息。
• 聊天系統：可以內部聊天，或是和管理者溝通。
  ... 等等

這些系統，都是我們的專案涉及到的領域，我們需要釐清每個領域的需求，並且釐清每個領域的邊界，這樣才能夠確保我們的專案能夠成功，還有一個可怕的事，這些領域都可能會在無聲息的情況下，不斷的增加。

領域的邊界

邊界的釐清，是非常重要的，因為這會影響到我們的專案的規模，如果我們的領域邊界沒有釐清好，那麼我們的專案就像是一個永遠吃不飽的怪獸，永遠都會有新的需求，而且這些需求都是無底洞，永遠都會有新的需求出現。

技術的組成

雖然第一步要搞清楚就很辛苦，但還是會有更辛苦的事情，那就是技術的組成，我們需要在這些領域中，找出我們需要的技術，這些技術，可能是我們已經有的，也可能是我們需要開發的，這些技術，都是我們專案的基礎，如果我們的基礎不穩固，那麼我們的專案就會像是一個脆弱的城堡，隨時都會被敵人攻陷。

如果分析出我們「沒有的」技術，那麼請他歸納在第一個階段的「領域」中，以上面的「打卡系統」為例，我們技術組成可能是：

• 載體分析：是需要 Web，還是 APP，還是其他的載體，針對每一個載體，我們都需要一個 SOP，消除不必要的疑慮。
  • WEB：通常是前端技術。
  • APP：一個完整的 APP，通常會有前端和後端。
  • 混合開發：通常用來開發 APP 的技術，會有 React Native、Flutter、Ionic 等等。
• 技術選型：我們需要一個前端的技術，來開發我們的前端。
  • UI 框架：常會有 React、Vue、Angular 等等。
  • 資料處理：Redux、Vuex 等等。
  • 資料庫：MySQL、MongoDB、Redis 等等。
  • 開發工具：Webpack、Babel、ESLint 等等。
  • 測試工具：Jest、Mocha、Chai 等等。
  • 部署工具：Docker、Kubernetes、Jenkins 等等。
  • ... 等等

前面兩個階段，我想大部分團隊都會做，但是第三個階段，就不一定了，因為我們知道需要做一個打卡系統，會涉及到那麼多個不同的系統，所以針對不同的系統，我們分別做了不同的模組，這些模組可以讓我們「快速」的上手和起步

• 考勤 API：只要註冊一個帳號，就可以使用打卡系統的 API，來記錄員工的打卡紀錄，並且計算員工的出勤狀況。
• 員工 API：用同一個帳號，我們也可以申請員工的 API，來管理員工的資料，包含員工的基本資料、員工的薪資資料。
• 組織 API：丟給他一個 ID，便可以拿到一個組織樹，這個組織樹，可以讓我們知道員工的主管是誰，員工的部門是哪個，員工的職稱是什麼。
• 推播 API：可以對這個 API 發送訊息，這個訊息可以是推播，也可以是簡訊，也可以是電子郵件，也可以是其他的通知。
• 資料收集 API：可以對這個 API 發送資料，這個資料可以是打卡紀錄，也可以是請假紀錄，也可以是其他的資料。
• IM 中間層：本質上這個 IM 可以坎入到任何 AP，它對平台來說事獨立且分離的，這個通話紀錄是在一個獨立的資料庫，而這個 AP 只是運用這個 IM 的 API，來達到聊天的功能。
• 報表系統：可以匯入任何資料，並且產生報表，這個報表可以是出勤報表，也可以是請假報表，也可以是其他的報表。
• Iot API：一個機台和設備的對接協議，這個協議以 Webhook 的方式，將機台和設備的資料，丟到我們的 API，這個 API 會將資料存到資料庫，並且通知對應的人員。
• ... 等等

組合技術

有了以上的資料之後，我們就可以換一個角度來敘述一個打開系統，它需要什麼東西。

• 考勤系統：就用考勤 API
• 請假系統：就用請假 API
• 聊天系統：在 IM 平台上申請一個聊天室，並坎入到我們的 AP
• 要顯示員工的組織樹：就用組織 API
• 要看報表：就用報表系統
  ... 等等

我們並沒有特別針對一個特定的功能去設計，而是針對一個特定的領域去設計，這樣我們就可以針對不同的專案，來組合不同的技術，來開發我們的專案。

變化一

我們可以強化員工 API，讓這個 API 擁有更多的功能，像是大頭照，或是員工的薪資資料，這樣我們就可以在其他的系統中，直接使用這個 API，來取得員工的大頭照，或是員工的薪資資料。

變化二

推播 API 是一個很大的領域，我們可以在這個領域中，再分出不同的領域，像是推播、簡訊、電子郵件等等，這樣我們就可以針對不同的領域，來開發不同的技術，來滿足不同的需求，之後有別的專案需要推播，我們就可以直接使用這個推播 API，來發送推播。

變化三

幾乎每一個系統都需要報表，不用每一個系統都去開發報表，我們可以將報表系統，做成一個獨立的系統，讓其他的系統，都可以使用這個報表系統，來產生報表，並透過推播 API，來發送報表。

總結

1. 先釐清專案的「組成」
2. 設計出技術的「組成」
3. 利用技術的組成來組裝專案
4. 針對不同的專案，來組合不同的技術
5. 不斷優化技術組成的模組