莊子弘

Error message:

If we used Browser (Ex: Chrome) to call the API. In DevTools, it will show CORS error but actually it’s not.

If we call this API by Postman, it will show “504 timeout”.
We need to update Route setting to fix it.

Solution:

By default setting, OpenShift Route will close the connection after 30 secs if no response. But sometimes back-end server will need more time to deal with that.
In my case, our web-service will retrieve a lot of files to get data then response. So we changed the default setting.

Command:
oc annotate route <route_name> \ — overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit>

Example:
oc annotate route wormhole-api — overwrite haproxy.router.openshift.io/timeout=30m

--

--

大師之間的不謀而合

相信從事軟體開發的從業人員應該都聽說過TDD (測試驅動開發),如果不知道什麼是TDD的話,基本可以簡單理解成:

在編寫函數之前,先寫好相關的測試案例

最近一個月我強迫自己用TDD的方式來寫程式,突然發現TDD這個方法與這兩年很紅的一本書 — 原子習慣 有不謀而合之處。

這邊簡單說明一下原子習慣的概念:

把習慣切成十分微小的要求,就會發現培養好習慣是相當容易的事。

作者提供了四個法則讓大家容易培養出原子習慣,而我發現似乎能把這四項原則跟TDD的開發概念互相呼應。

法則1:讓提示顯而易見

法則2:讓習慣有吸引力

法則3:讓行動輕而易舉

法則4:讓獎賞令人滿足

我相信許多人在開發新功能時,常會有一頭霧水的情況。面對要做的功能太多,會有無所適從的感覺。例如你可能只是單純打個API要做資料處理,但其實裏頭的功能遠比你表面看上去複雜。

你會有一個發送API請求的功能,要回來的資料可能是JSON或是XML等之類的格式,而你需要讀取這個response裡面的資料,再來你可能只需要其中的某些資料,所以你必須對資料進行過濾,當你拿完資料可能還要做個分類或是依照其內容作一些編排,最後輸出檔案可能還有不同格式。

那這樣可以大概細數一下有哪幾項功能:

  1. 對API發送request
  2. 解析回來的response (可能有不同格式)
  3. 過濾資料
  4. 分類或加工資料
  5. 轉換格式(可能是CSV、JSON或是任何特定格式)
  6. 輸出至檔案或報表

最糟糕的做法大概就是只用一兩個函數處理掉這所有的事,可能就把1–3放一個函數,4-6放一個函數,中間的介面可能是一個string 或 list。大概是大學生作業等級的東西…

但如果是有點經驗的工程師就會知道,這些程式碼可不是作業 — 交出去就再也見不到它了。你可能會面對需求的修改、新增,所以你需要將各項功能分開以便來日重複使用,對於修改程式碼你也省得一口氣看500 行程式碼,你只需要專注在你要修改的部分,可能也就20行而已。

如果你寫程式的時候,沒有設想到這些未來情況,隨便產了一坨糞code出來,那這坨屎很有可能是幾個月後甚至是幾年後的你來吃。

但要怎麼確保你的設計是足夠彈性 — 至少彈性到幾個月後的你還看得懂,而且也改的動。

你需要寫測試

嗯…

那好,既然我們都知道要寫測試了,那什麼時候寫?

你終究要寫測試的

那為什麼不一開始就寫?

好巧!回到了我們的主題TDD,藉由先編寫測試來驅動開發有那些優點呢?

  1. 讓你能夠從呼叫者的角度去考慮程式的設計。呼叫者可能是任何人 — 你或其他工程師。為了everybody著想,避免重工或無意義的修改,從呼叫者的角度考慮程式設計是相當好的。
    畢竟,早知如此何必當初呢
  2. 及早處理例外情況。如果你的參數是浮點數,但呼叫者傳了整數進來,你要怎麼辦?丟例外;幫忙處理型別轉換?
    AKA 超前部屬
  3. 讓函數變得足夠小。小巧的函數才能夠方便你測試,方便測試也就意味著更容易偵錯。
    時間就是金錢,同時也是你的生命
  4. 更容易重構。當你發現當初的作法不夠好時,你可以放心的進行優化,因為你有測試在保護你。
    Just do it.

但這跟原子習慣有啥關係呢?

回憶一下我們培養的原子習慣四條法則:

法則1:讓提示顯而易見

在有測試案例的情況下,你的腦袋不會漫無目的發散性思考。你要做的事情很單純也很簡單,寫出能夠通過測試案例的函數,這能夠幫助你專心。

法則2:讓習慣有吸引力

在你寫好測試案例之後,先執行一次。
沒錯!一定會失敗。所以我相信你會更有動力去編寫函數。畢竟整排的 test case failed可不是讓人心曠神怡的事情。

法則3:讓行動輕而易舉

為了設計出容易測試的函數,你會把函數功能設計的足夠簡單,這會讓你編寫一個函數可能只花兩分鐘,這麼簡單輕鬆的事情沒道理拖延吧?

法則4:讓獎賞令人滿足

看到一整排的測試案例從failed 變成 passed。相信我,這挺令人舒壓的;除此之外,看到自己正往著正確的軟體工程之路前進,你的心裡會十分的充實、安心。

--

--

--

--

莊子弘

莊子弘

文字工作者,不過周一到週五寫的都是程式碼。閒暇時間會分享一些心得,包含技術文章或影集書籍觀後感。