原來可以這麼寫(11): 每個人的心中都要有DevOps

最近工作比較沒有什麼新鮮事,所以開始在將手上專案有比較完整的文件化之後,開始逐步導入TDD ,寫一些Unit Test 以確保程式碼的品質。

但老實說:我還是不是太懂Laravel Feature 和 Unit 這兩個資料夾的區別?我知道Unit 是要做單元測試,是測試那個類別的行為,但我目前大多都在寫Feature Test… 如果有大大知道Unit 該在何時寫、什麼情境下要寫,歡迎不吝賜教!

研究Socket/API Gateway

因為要導入官網購物車購買,討論一連串的流程與討論,最後希望我Laravel 要開一個socket server,但研究的結果其實發現 因為我們專案的版本比較低,所以沒辦法使用Laravel-Websocket 套件,也就是在Laravel 裡面自己開socket server 那種,變成我們要另外用Node 的套件去建立… 然後… 又衍伸第二種方案,在AWS Api-gateway 架起websocket api ,然後他可以指定動作去call API…

這個方案很好玩… 不過在研究初期卡關在怎麼用Laravel 取出 connectid , 因為AWS example 是用Node 的Lambda 去串的,很簡單就取出connectid… 。我Laravel 怎麼print request 的body 還是 header ,顯然就是找不太到那個connectid …

後來實在有點卡太久了(大概一天),被同事叫我去寫AWS Support XD

人生第一次寫AWS Support 耶,然後AWS 團隊真的很用心很貼心,告訴我很詳細的步驟及方法、解決方案,原來,如果要讓Laravel 的 後端讀得到 connectid ,是要透過CLI 去設定啊… (目前API gateway 控制台還沒有支援這個),不然就是需要把integration type 改成 HTTP ,去寫 request template 這樣。

總之,這次經驗讓我更認識 API gateway 和 socket 啦!預計之後想要開一系列深入研究Laravel 的系列,想要寫broadcast 的部分,希望今年可以完成這個寫作計畫 ^^

網站可靠性工程工作導讀

我們每個禮拜都會有小組的例會,小組的成員都需要報告一下我們各自的狀況與專案進度,然而在今年我們組長要求大家輪流每個禮拜都要分享一下技術議題,不管他是前端還是後端皆可。

我個人覺得這是很好的一個文化,但最近也常常聽到同事在講對他們有一點小小的loading…。有點不知道耶,明明是很棒的事情為什麼反而有點造成不太好的效果?我們的專案真的有點多而且每個人負責很多啊,不太平均……

話說回來,大概這樣輪流每個人平均一個月講一次,所以這個月就帶來我讀網站可靠性工作工程的心得與收穫~

之前,也曾經參加這本書的導讀會,大家可以參考:網站可靠性工程工作手冊導讀會一遊

然後值得一講的是後面補充文章有一則:技術債觀念及實務
因為在查一些SRE 和 DevOps 相關文章時就不小心逛到,在這篇文章讀到:

另一方面,著有《Domain-Driven Design》一書的 Eric Evans ,對於處理舊有程式碼(legacy code),也曾提出過一個叫做「戰略設計(Strategic Design)」的觀念。Eric Evans 認為,在一個系統中,根本不可能所有的程式碼都維持夠高的品質,而且,有些情況下,有些程式碼也沒有必要一定非得是高品質。這是個相當務實的觀念,如果我們很現實的來計較在開發過程中每一份生產力的 C/P 值,那麼,維持一些程式碼的完美,需要付出的代價太高,但這些程式碼即使完美對整個系統的效用卻不大時,是否應該讓它們也被一視同仁地被維持高品質?

By 技術債觀念及實務

這帶給我寫程式上面莫大省思與體悟,原來,寫程式也像DevOps 一樣「不應該」去要求百分百可靠度(完美)

以前我都覺得自己要每一行寫得很棒很好,這是一種工程師對自我的要求… 反而導致每一次我寫功能之後就會每次檢討自己、總是花很多時間在想下一次怎麼可以寫更好,但有時候下一次也不一定像這一次可以要求寫得很好…

而DevOps 和剛剛讀到的技術債觀念及實務帶給我在寫程式上面的一個心態轉變,應該要對於不同的程式碼有不同的權重分配,有些可以選擇粗略地寫,只要功能有夠、排版讓人覺得算ok,這樣就好;而有些需要好好每次的重構每次的改善,讓程式碼可以越來越易讀!

總之,這是我當天報告用的ppt ,希望能幫助到大家~

小君曰:每個工程師的心中都應該要有DevOps !