相信大家在開發網站平台時，多少都會碰到要串接第三方服務的狀況吧。比如說串接金流，畢竟我們不可能自己去做一個金流支付平台，或是自行去串接各家銀行，對吧。以台灣來說就像「綠O科技」，或是「歐O寶」之類的第三方支付平台就顯得非常重要。
甚至現在有聽到有些的案件，都是想要透過虛擬貨幣來進行消費，畢竟因為元宇宙的概念在2021年大爆發後，區塊鏈、NFT等題材，變成大家爭相討論的話題，那我們要怎麼去串接虛擬貨幣？
如果遇到像這種，第一次碰到的案件，我們應該怎麼去思考這件事？
這邊分享一個好用的工具，叫做「UML」。
和「UML」結緣的那一年，大約30歲。那時候會知道「UML」，是因為當時的營運長，希望對我們進行教育訓練，讓我們可以學習一些「工程師開發的思維」。後來我就自己去書店找「UML」相關的書，也上網找了關於「UML」的文章和分享。
那什麼是「UML」？
統一塑模語言（英語：Unified Modeling Language，縮寫UML）是非專利的第三代塑模和規約語言。UML是一種開放的方法，用於說明、視覺化、構建和編寫一個正在開發的、物件導向的、軟體密集系統的製品的開放方法。UML展現了一系列最佳工程實踐，這些最佳實踐在對大規模，複雜系統進行塑模方面，特別是在軟體架構層次已經被驗證有效。 —《wiki 維基百科》
我想，這樣寫應該是搞不清楚什麼是「UML」吧？
簡單來說，「UML」的目的在於創造一個大家都認同的統一語言，透過圖像化的方式，讓團隊成員與機器都能理解。於是，「UML」就包含了各種視覺化的圖表，把「看不見的流程」變成「看得見的流程」。
由於整個「UML」的範疇過於龐大，今天就分享一個相當常用的工具，叫做「循序圖」，又叫做「時序圖」。
那什麼是循序圖？基本「循序圖」的元素如下圖的形式：
看起來好像很簡單，但是似乎又不容易了解。舉個例，應該就明白了。
讓我們以「便利超商取件」為例吧!!
當我們去便利超商取件的時候，通常都是從「你好，我要領包裹」開始。
接著店員就會問我們「手機末三碼」，我們就會回答「手機末三碼是多少」。
然後店員就會去確認有沒有「符合手機末三碼的包裹」。
如果有的話，就會請我們出示「身分證件」和請我們「簽名取件」。
最後，我們就可以成功領取包裹回家。
像這樣把整個操作流程，一步一步的拆解，並依時間序畫出，就是所謂的「循序圖」。
過程中會接觸的有「便利商店店員」、「包裹收納櫃」及「簽單檔案櫃」，這些就是所謂的「實體(Entity)」。也會很清楚看到「我們」和「便利商店店員」、「包裹收納櫃」及「簽單檔案櫃」的交互關係及互動流程。
其實，「循序圖」就是「將使用者操作過程中的交互流程，拆解至最小單元，直到操作完成。」
哪要怎麼應用到系統開發上？
想像一下，如果今天要開發的項目是「自動取貨機」呢？
馬上就從「店員取件」轉換成「機器取件」。當然，上面的「循序圖」簡化了一些內容，例如如果沒取件的話該怎麼辦？如果取錯包裹的話該怎麼辦？領取包裹是否有時間限制？今天主要是想要讓大家了解，「循序圖」這個好用的工具，太細節的部份就請忽略吧。
其實，像這種「自動取貨機」的流程拆解，和「店員取件」的概念相同，透過「循序圖」，可以較有系統的幫助我們去思考每一個步驟，而且重點是可以讓參與開發的人，清楚知道要完成這個項目，需要多少的「實體」配合，像是需要一台「自動取貨機」，需要紀錄包裹狀態的資料庫，還有收納包裹的地方。
如果是一般的平台網站的開發的話，就可以很清楚知道，前端網頁要做的事情、後端服務要開發的項目，以及資料庫要處理的資料。也就是說，團隊開發成員的分工也就很清楚知道了，而且透過這樣的思考，也可以知道哪些項目要給交給前端工程師負責，哪些是後端工程師該處理的，哪些是資料庫管理師可以協助的。有爭議的話，也很容易地發現並進行討論。
回到一開始提到的案例，今天的需求是要串接「綠O科技」的金流服務，那我們該怎麼思考？
首先我們需要想想會有幾個「實體」？
1. 前端網頁：讓使用者輸入基本資料的地方，如信用卡卡號
2. 後端服務：用來處理刷卡消費記錄訂單的服務
3. 資料庫：用來儲存刷卡消費記錄訂單的地方
4. 綠O科技資料輸入網頁：用來輸入身分驗證資訊的頁面，如OTP驗證或簡訊碼
5. 綠O科技資料驗證服務：用來驗證身分資料的後端服務
接著就是回想一下，過往使用網路購物平台，進行信用卡消費的流程。可能就會是像下圖這樣的「循序圖」。當有第一版的「循序圖」出來後，就可以和工程師直接討論，也會很清楚「前端網頁、後端服務、資料庫」分別要做哪些事，而和「綠O科技」進行交互處理的部分，也就是所謂的「串接」。當然，實際的串接會比這張圖更加的複雜，比如說是否要驗證發送請求的來源地區或是IP，是否要先取得Token，是否有白名單的驗證…等等，實際上的開發會比這張圖來的更複雜。
但是有了這一版後，基本的流程與需要執行的開發項，也就相當具體了。也可以很清楚的和客戶或需求方，說明整個功能的流程，是不是相當便利？
透過「循序圖」，可以幫助我們下列三件事：
1. 有系統地思考功能的流程。
2. 讓專案參與成員，對於系統流程有一致性的認知。
3. 清楚地定義前端、後端與資料庫的功能項目。
搞懂循序圖，幫你拆解各種系統流程，讓工程師更加信任你。
大家好，我是廣三(HeroMi)，從事多年的遊戲及軟體專案開發，親身經歷大大小小專案開發的戰場，希望透過經驗分享，讓我們一起學習成長。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。
留言