已經有好一陣子沒有更新這裡的文章了，主要是前陣子下班之餘大多時間都在忙 side project，也就沒什麼時間更新文章。之前本來想趁著公司實聯制新功能上線，寫一下整個開發過程，順便當個徵才廣告，但寫一寫覺得沒甚麼好寫的，於是就棄坑了。
後來政府推出簡訊實聯制，引起不小的討論，但會隔了這麼久才寫這篇，主要是想避開熱潮 (另一原因見後記)，冷靜後大家再來討論會好一點，避免不必要的口水 (飛沫)，我覺得設計沒有絕對的好壞，在不同的 context 底下，設計自然會不一樣，首先先來說明一下公司的設計與開發過程 (之前的稿棄坑歸棄坑，但沒刪除就回收再利用) 吧！
公司的產品很早就能協助餐廳進行聯絡方式的登記，當初衛疾管署的《防疫新生活餐廳用餐篇》的宣傳影片出來時，雖然只有短短的 3 秒 (第 24 到第 26 秒) 出現產品的畫面，CEO 很開心在 slack 分享影片給大家。
很多餐廳也用這方式登記聯絡方式，只是還是有不少餐廳選擇紙本或是讓消費者掃描 QR Code 填寫 Google 表單，來登記其他同行人的聯絡方式。後來疫情加溫，某天晚上 CEO 在 Slack 上發起討論，是否有更好的實聯制解決方案來幫助餐廳，討論很踴躍，有很完整但開發上較複雜的方案，也有開發上較簡單但只滿足部分需求的方案。
隔天早上，CEO、設計師、PM 和 Dev Manager 先開了一個小會，把昨晚的幾個方案融合在一起，確定了大方向後，下午請整個開發團隊進行細部的設計，事實上下午也優化了一些上午沒想到的東西，像是實聯制的資料，如何在不修改既有資料結構的情況下可以實現與既有的產品整合，然後，短短兩天，完成開發與測試，晚上 10 點上線。
事實上，前一天就能上線了，只是在測試的過程中，覺得還要再考慮一個使用情境，於是請紐約的同事在台北時間的晚上在加開發一個新功能 (這應該算是跨時區的好處)，把整個使用情境弄得更完整。
所以影響我們設計的 context 有那些呢？
- 由於是 B to B to C 的系統服務商，不能只考慮消費者，或只考慮餐廳，理想的情況是兩者都能在這設計中獲益。
- 礙於法律，很難直接從電信商 (別懷疑，電信商擁多數人的個資，至少肯定知道電話的擁有者姓名) 或其他來源 (例如政府) 取得個資。
- 政府是間接的服務對象，只有當政府想要找確診者足跡的時候，才會需要提供資料給政府。
- 個資是麻煩的東西，過去的經驗是，能不儲存就不儲存，若要儲存也要想辦法定期清除。
基於上面的情境，設計必須能夠快速地讓消費者輸入姓名與電話，且能讓餐廳能夠在平常使用的平板上看到同桌的客人是否都完成登記。因此仍採用掃描 QR code 開啟餐廳專屬的網頁 (toLocation(qrCode))，網頁提供表單 (renderForm())，可輸入自己的姓名與電話，還能輸入其他同行人的資料，特別的是能輸入訂位登記人的電話 (fillForm(contacts, owner))。
送出後 (submit(contacts, owner))，server 首先將聯絡資訊儲存到資料庫 (saveContacts(contacts))。最後，用訂位登記人的電話找前後兩小時的訂位 (queryReservation(owner))，若果有相符的訂位，將已登記的姓名及人數更新到訂位的備註上 (updateNote(id, names))，接著通知平板的 app。
這時餐廳的人員就可以在平板上看到的完成登記的人數與姓名，如果有客人忘記或是沒有輸入成功，餐廳也可以從平板上得知，餐廳服務生不用在餐期繁忙的時候一一檢查客人的手機畫面。像下圖，服務生即可知道有一個人沒有填 (四人的訂位有三人完成)，其餘 Spirit、Maggie 和 Jack 已完成登記。
後來紐約同事追加的部分，則是利用本來就既有的事件通知 (reservation created event)，多一個背景的比對服務，在繁忙時，餐廳服務人員可能還來不及建立用餐人資訊，可以讓先到現場的消費者先填寫聯絡資訊，等到之後訂位建立後，由背景服務收到事件後比對並更新備註。
最後加上每日執行的 cron job，將 28 天前輸入的個資從資料庫清除，就完成了整個實聯制的服務設計了。
由於無法自動取得姓名，因此為了滿足第一個 context，我們還是決定提供網頁讓消費者輸入個資 (電話與姓名)，但是在餐廳端我們則是只顯示姓名與人數，避免讓餐廳取得訂位人以外的所有個資，卻仍可以提供足夠的資訊讓餐廳的服務人員知道是否都已完成登記。
但是，假如姓名不是必需的 (在開發時，幾乎所有地方的紙本登記都要求姓名與電話)，那設計就可能完全不同了，我覺得這也是政府的簡訊實聯制設計與多數民間的設計不同的原因。
我沒有參與到簡訊實聯制的開發，所以無法清楚地知道設計的實際 context 是什麼？但從設計可以得知幾個與我們的 context 完全不同的幾點：
- 姓名其實不是重點，只要能用電話或簡訊連絡到接觸者即可，即使通知時，不知道對方怎麼稱呼都沒有關係。
- 可以將資料的儲存交由第三方 (電信商)，並將程式佈署在第三方 (不確定是電信商自己的機房或是電信商使用的雲端服務)。
- 信任民眾都會如實送出簡訊 (這裡要肯定所有的民眾，這段時間真的都很配合)。
第一點會是設計不同的最大原因，如果政府一開始的需求：
給定電話、時間與地點，能協助政府通知到所有的接觸者，或是提供所有接觸者的電話
而不是
進入場所的使用者要登記電話與姓名
那民間的設計也會採取不同的做法，有人可能會說，要看問題背後的問題，這樣才能做出更好的設計？這句話本身沒有錯，問題在於沒有對象可以確認需求，一般軟體開發，在探討設計時都會去思考為什麼需要某個功能，在知道背後的原因後，可以提出更好的設計，但最終還是要跟需求的提出者做確認，而在這個案例中，大多都是看到政府的方案後才知道真正的需求。
另外，這個設計對場所的服務人員來說，其實沒有那麼友善，服務人員需要一一檢查民眾的手機畫面，但如果稍加觀察就會發現，一開始很多場所的服務人員都會做確認，但過了一陣子後，很多服務人員只是問：有掃 QR Code 了嗎？畫面連看都沒看，再過一陣子後，連問都沒問了。只能說多數民眾都很配合使用簡訊實聯制。
即使如此，簡訊實聯制仍是一個很好的設計，但如果政府能換個思維，別把自己當成是一個服務提供者，而是當成一個平台，那簡訊實聯制可以多加一個 webhook，將簡訊內容傳送給第三方，如此一來，民間可以串接這個平台，做其他深度的整合，而且不用儲存民眾的個資。
例如，我們就可以請消費者，在簡訊中多填入姓名與訂位登記人的電話 (得承認這相對較難，而且會讓流程變複雜)，送出後，我們能從 webhook 取得姓名與訂位登記人的電話 (但不知道從誰的手機號碼發出)，後續我們可以繼續尋找訂位，並將姓名與人數更新到訂位備註中，消費者可以快速完成登記，餐廳也可以在我們的服務中快速確認所有人都完成登記，而政府也可以在有確診者時快速通知接觸者，這不只是雙贏而是三贏的結果。
結論：這篇文章不是要討論哪個設計好或哪個設計不好，在我看來，兩個設計都滿足各自的 context，都是好的設計，重點在於，當 context 不同，設計就會不同，context 可以是功能性需求，也可能是非功能性需求，若不看 context (這通常也是比較難得知的，這篇我也只能看設計反推 context，也不見得周全)，直接討論設計是很難有建設性的討論。
補充：實際上，我們的服務大量使用簡訊，不管是送簡訊或處理回覆的簡訊，因此要簡訊來完成登記其實也蠻容易的，首先向簡訊商申請一組專用的號碼，接著註冊 inbound webhook，然後實作 endpoint 串接 webhook，解析簡訊內容來完成登記與配對，QR Code 內容其實很簡單，就這樣而已：
sms:[phone number]&body=[location information]我不確定是因為我們沒想過要讓消費者付簡訊費，或是因為要求消費者在簡訊輸入介面輸入我們想要的資訊是不太容易的，總之，這確實不在我們一開始討論的諸多方案中。
後記：最近會有空寫寫文章，主要是前陣子健康檢查報告出來後，發現要好好注意身體健康了，所以跟 side project 的夥伴告假，也開始讓自己每天都運動 30 分鐘以上，而多出來的時間，就選比較可以想做就做、想停就停的事情來做了，口袋裡還有不少主題，就慢慢來囉。最近的體悟是：當位工程師，身體健康是很重要的。
系列索引
上一篇：《閒談軟體架構：Singleton》
下一篇：《閒談軟體架構：再聊 UUID》
