前言
去年一些巧合, 跟團隊幾個人接手一個案子, 這個案子原本算是服務客戶特定需求的 POC, 但由於客戶愈來愈依賴這個工具, 因此交到我們手上.
PS. 在我加入之前, 已經有人辛苦耕耘了好一陣子. 不過也因緣際會離開這個案子. 一個案子要成功, 從來不是誰可以獨立勝任. 享受合作的當下, 同時也要記得這是很多默默付出的人辛勞的結果, 而非甚麼簡單的水到渠成..
挑戰
- 技術背景不同
- 案子用到的技術是 NodeJS, Angular, MongoDB
- 成員技術背景是 Java, Cassandra
- 需求大: 要把 MongoDB 換成 PostgreSQL
- 技術債: 由於是個 POC 的案子, 所以程式結構沒有特別維護, 整組就是典型的 callback hell, 經常性的 callback 到第四第五層
- 沒有統一的 build flow: 原本交付的方式就是從某個工程師的電腦打包出一個 image 給客戶安裝, 在 POC 也還合理, 但要產品化就無法接受了
- 概括承受 bug, 當前客戶在用的系統如果遇到問題, 就需要與 technical support, customer support 一起討論與解決問題
接受挑戰
初期
- Study: 由於技術不熟悉, 所以大家還是花時間學一下 NodeJS, Angular, MongoDB.
- List features: 一起把功能使用一番, 列出來
規劃
Thread-1-1: 換資料庫
- 一開始我們把所有的 table 列出來, 想要"縱切"來分開發方式. 也就是一個 table 一個 table 的把程式從面對 MongoDB 改為面對 PostgreSQL
- 做一段時間後, 深感部分 Data Access layer 面對 MongoDB, 部分面對 PostgreSQL, 常常碰到一些因為資料不一致出現的錯誤.這種錯誤讓人無法確認現在的開發是好了沒有, 所以我就決定開始衝刺把所有的 Data Access Layer 通通轉成面對 PostgreSQL, 而不理會功能是否損毀.
- 同時間, 另一個成員深受 callback hell 的困擾, 因此在討論後, 開始大幅度的將 callback hell 改為 controller -> service -> dao 這樣的三層式架構
Thread-1-2: build script
團隊內的大神基於興趣, 接手了 build flow 的規劃. 將原本由工程師在自己電腦上 build image 的方式, 轉為
- 準備 docker 環境
- 在 docker 內準備好 CentOS, PostgreSQL, NodeJS, Angular 的環境
- 安裝好後 build 出客戶需要的 vmware image
- 準備 CLI 讓客戶裝好 image 後, console 上能跳出 setup 的 CLI.
- 支援 join 第二台 PostgreSQL
- 在 Jenkins 上執行 build script
Thread-1-3: nginx
- 專案原本用 openresty 在 nginx 寫程式 access MongoDB
- 我們認為這設計導致不容易管理資料庫由誰存取
- 因此規劃改寫 openresty 從直接存取資料庫, 改為存取 API 來存取資料.
Thread-2-1: data migration
在 Data Access Layer 改為面向 PostgreSQL 之後, 接下來需要處理怎麼從 MongoDB 轉移過來, 因此規劃了
- 把 MongoDB 資料轉出
- 建構 PostgreSQL 的 migration script, 包含建立 schema 的 DDL
- 提供 user import MongoDB data 的功能
Thread-2-2: licensing
原本的案子沒有 license 的功能, 因此也照公司其他產品的方式規劃了 license
Thread-3-1: documentation
慢慢功能都快補好了, 開始需要與 document team 溝通與準備需要的文件
Thread-3-2: unit test
過去缺乏 unit test, 因此大量地補上
成就與心得
- 像這樣分很多個 thread 做了非常多的事情, 一切只發生在大概五個月內, 而且我們成員就五個人, 且大多都還有其他在進行的專案.
- 通常一個案子在進行的時候, 很多人可能會想要把要做的事情都規範好, 希望能夠營造一個 "我都規畫好了, 你照做就沒問題"
- 但我們的作法則是: "目標就這些, 一起來看怎麼處理"
- 在執行過程中, 每個人都在貢獻自己能做的事情, 而且當遇到覺得有問題的地方, 提出來後大家就能一起討論做決定, 接著繼續分頭進行
- 由於能夠參與決定, 大家就更有 ownership, 就會提出非常多很好的意見
- 我自己就很開心能享受到架構與流程的改善, 而且完全是大家自發性的改變, 回想這一段時間, 很短, 但很充實愉快
後記
這個案子, 因為一些因素, 人員變動, 在我們做完之後暫時告一段落.
大家繼續各自去忙不同的案子.
後來公司找了外包團隊.
所以接下來我還會一次與公司突然開始加入的外包團隊, functional QA & performance QA 一起合作.
正在如火如荼, 再次經歷一段美好的團隊合作經驗.