專案的技術組成

15th鐵人賽

310 瀏覽

專案分析

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

如果我們上一章提及的「公車 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 會將資料存到資料庫，並且通知對應的人員。
... 等等