iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 18
1
自我挑戰組

Let's Eat GO ! 實務開發雜談by Golang系列 第 18

Day18 .[心得與討論篇] 走向interface去設計架構(5)- 從思考資料的想法轉變成思考業務

回顧

筆者直到到半年前為止,開發的內容幾乎是圍繞在平台的部分,後來才踏入遊戲這塊。

平台與遊戲著重的業務處理,明顯有不同的重心,因為平台的業務處理重點在於資料,久而久之可能也不小心養成了定性思維,定性的抽象方式。

平台是這樣的,API request進來後,先驗參數,若參數格式,打回票。如果成功進來,大概就是開始一連串的資料加工,來舉筆者之前某個上傳excel名單處理的功能作範例好了。

處理邏輯大概是這樣:

  1. 檢查這份excel格式對不對,大小有沒有超過上限。
  2. 開始檢查這些名單上的id,發某某API X取得他們的詳細資料。
  3. 資料驗證這些id,是否有效或者有資格出現在這份名單。
  4. 從資料庫撈取關聯的資料,根據這些id作邏輯處理加工。
  5. 從某某API A撈取資料後,再加工。
  6. 從某某API B撈取資料後,再加工。
  7. 根據加工後的資料,製作需要格式,發某某API作處理。
  8. 根據加工後的資料,製作需要格式,寫入某某DB作處理。
  9. 以上每個步驟斟酌寫log,結束。

每次的工作都幾乎是在處理資料,如何把資料怎麼處理,資料結構怎麼設計,怎麼跑運算效能會比較好,怎麼檢查資料才不會錯誤,一直以來都是這樣很類似的工作,怎麼在這之上,能夠抽像出更好的程式設計,其實非常欠缺示範,大家每天被資料、資料、資料的念頭深深綁架著。

開始學golang之後,筆者一直在反思,為什麼物件導向學了那麼久,寫出來的程式卻總是外形有像,內在卻不行。interface 用了那麼久了,卻總好像只有理論而已。

況且golang已經是另外一種設計思考模式的程式語言,雖然它開宗明義,擁抱OO的概念,但不是OOP,自己又如何更成長一步呢?

改變

不斷的練習總結和歸納,筆者認為是很有幫助的,從小到大,從細部處理好,再到局部,再到全局。

以設計程式來說,可能一開始我做的只會抽出某一種行為,譬如說,發API拿到id代表的人名、詳細資料。

可能就寫個function,叫做『getUserData()』,然後可能有些更細部的處理拆分,譬如說『getUsersAPI()』『resAPIDataRebuild()』等等。

過去以來,筆者寫了這類堆積如山的function出來,都不敢叫它『method』,因為『method』是有個主體的function,才叫做『method』。

縱使這些東西前後有連貫的function,放到同一支檔案,或同一個資料夾,也難以視為一個主體,因為難以簡單輕鬆了解它的範圍。

那主體怎麼界定?以前php一直在寫的就是class,以golang來說,就是struct。

這可能是廢話,尤其當你只是把它當做某種類型資料的資料存放,裡面的method只是根據你的需求設計的運算。

但是,練習著用『業務』的概念來想,設計主體的想法就會跟以前不一樣。

以上一篇的例子來說,employee(員工)和Tool(工具)就要拆分出兩個清楚、而且沒有直接瓜葛的主體,互相不干涉對方應該要處理好的業務,甚至,連對方實際規格,實際長怎什麼樣子都可以不用了解,只要界接的input和output對,誰都可以界接。

想想各主體要負責的部分,每個主體想想要別人提供什麼結果,自己要提供什麼結果,以此思考方式建構出程式每個部件,會發現跟以前用『資料』的方式思考寫出來的程式,完全不一樣。


上一篇
Day17 .[心得與討論篇] 走向interface去設計架構(4)- 思考interface的應用III
下一篇
Day19 .[心得與討論篇] 走向interface去設計架構(6)- 進階變化
系列文
Let's Eat GO ! 實務開發雜談by Golang30

尚未有邦友留言

立即登入留言