前言

貢獻開源專案 Fission 時，不僅會被他人審核也常需要審核來自世界各地開發者的 PR，從中體會到不少身為一個軟體工程師、一個專案維護者該有的行為與談吐。 近期 Google 公佈其內部關於「如何進行程式審核」的指導原則， 快速瀏覽相關內容後真的是心有戚戚焉，要是能更早知道這些技巧就不會摸索這麼長的時間。

認為這麼棒的文章沒有讓更多人看到實在非常可惜，因此嘗試自己翻譯來分享給中文的開發者。 若有文句不通暢、翻譯錯誤、typo，還煩請多包涵與指教。(部分找不到適當中文翻譯之專業名詞會以原文呈現)

原文

• https://google.github.io/eng-practices/review/reviewer/standard.html

The Standard of Code Review (程式審核準則)

Code review 主要目的在於確保 Google 的程式庫 (code base) 整體健康度隨著時間推移能有所改善。 而所有的審核工具與流程皆是因應這個目的而生。為達到前述目的，勢必需要做出一連串的權衡與取捨 (trade-offs)。

首先，開發者必須能夠在任務上取得進展，若不對程式庫進行任何提交的話，那程式庫永遠不會有任何改善。 此外若審核者 (reviewer) 讓任何提交變得難以進入程式庫的話，則開發者會把「做出改善」這件事本身視為沒有益處，並且未來不再做出任何改善 [1]。

另一方面，審核者必須確保每個 CL (changelist) 的品質，且不會讓程式庫健康狀況隨著時間推移而下降。 儘管每個小改動只會造成品質微幅下降，但隨著時間拉長逐漸累積後，最後終將變成壓垮整體品質的那根稻草。 而這通常是非常棘手的事情，尤其是當團隊面臨時間壓力時，會讓他們認為必須抄小徑才能夠達成原訂目標。

再者，審核者對他們正在審核的程式有所有權與責任 (ownership and responsibility)，確保程式庫能夠維持一致、易於維護，以及其他寫於 What to look for in a code review 的準則。

從中我們得到一個作為我們預期在程式審核過程中出現的原則 (標準):

一般而言，只要更動 (CL) 有助於提昇程式庫整體品質的話，審核者就應該批准它

儘管它並非完美

這點也是位於其他程式審核原則之上最高級的原則。

當然在某些狀況下這個原則也是會受到限制。比方說，某個 CL 涵括審核者不希望出現在系統的功能時，此時儘管 CL 的改動設計非常良好，審核者依然可以拒絕批准它。

主要重點在於「並沒有所謂完美的程式，只有更佳的程式」

審核者不該要求開發者在批准程式前仔細清理、擦拭 CL 每個角落 [2]。 相反的，審核者應該在 CL 的完善與其所帶來更動的重要性間做出權衡。與其追求「完美」，身為審核者更應該追尋「持續性的進步(continuous improvement)」。 只要 CL 對整體系統能改善 「維護性 (maintainability)」、「可讀性 (readability)」、「理解性 (understandability)」的話，就不應該因為它不完美而延遲批准數天甚至數週。

審核者也要習慣於針對 CL 可以改善的地方留下審核評論 (review comment)。如果指出的改正不是非常重要的話，可以在前面加上 Nit: 讓開發者知道該改正是可以選擇性被忽略的 [3]。

Note: 這份文件並非嘗試去證明合併 CL 絕對會造成程式庫品質下降的問題。唯一會發生這種事的應該是在緊急情況 [4]。

• [1] 原文使用 disincentivized，找到最接近的解釋是 「移除做某些事的益處，導致其他人不想再做」。
• [2] 將程式碼清理到完全符合審核者標準
• [3] Nit 全稱為 Nitpick，意指吹毛求疵、雞蛋裏挑骨頭。自己本身會使用 nitpick，比如以下範例。

利用 nitpick 告知不在風格指南上的小問題

• [4] 因緊急狀況而合併不完全符合品質要求的 CL

前言

自己還蠻喜歡看書，尤其入手電子閱讀器後更是欲罷不能，不必再受限於書本重量且可以隨時隨地看書。 目前 kobo 的中文書籍相對全面以及時常有特價，因此蠻推薦購買他們家的電子閱讀器。

以下會提到自己是如何選出適合的書籍以及個人推薦書單，歡迎參考與交流 :)

選書技巧

由於書中的知識經過一定程度的梳理，在吸收與內化上速度比起自己悶著頭摸索來的快速。但是

沒有方向的船，任何方向都是逆風

因此個人選書時有個習慣是從自身較為薄弱的領域出發，思考當下或未來遭遇到的難題。 等確定好議題後找出能補強該弱項的書籍。比方未來有創業打算，便會針對公司營運、商業模式設計、團隊成長下手。

另外還有幾個小技巧:

1. 台灣有出版「中文翻譯」的作品，除去譯者本身翻譯功力不到位的問題，內容相較來說較為紮實
2. amazon 英文評論可以幫助你快速篩選書籍，4 星以上且多人評論較佳
3. 中國作者的書籍會建議現場翻閱內容，有些形式較接近於短篇文章卻寫成書。導致內容冗長、精闢要點卻很少
4. 跑誠品。沒錯，跑一趟誠品快速翻閱正在推廣的書籍。看作者文筆與內容是否符合自己，再考慮要去哪個平台買 XD

書籍分類

以下是根據上述選書技巧所列書單，建議於網站試閱後決定是否購買。

金融、理財

• 大債危機：橋水基金應對債務危機的原則
• 金錢心理學：打破你對金錢的迷思，學會聰明花費
• 綠角推薦
  • 投資金律：建立獲利投資組合的四大關鍵和十四個關卡
  • 定期定值投資策略
  • 智慧型資產配置

個人內在

• 關係黑洞：面對侵蝕關係的不安全感，我們該如何救贖自己？
  • 探討關係內的安全感及依戀型態
• 高敏感是種天賦
• 高敏感卻不受傷的七日練習

Introduction

在近兩個月的時間裡，針對來自不同用戶的反饋及問題回報 (包含前陣子的通靈故事 Localhost 迷航記)， 我們在 1.4.0 與 1.4.1 做出許多值得一提的改變，讓 Fission 能更加適應跑在不同生產環境上。就讓我們來看看多了什麼改變吧!

Highlight

• 英文版: https://docs.fission.io/releases/1.4.1/
• 由於更新包含眾多 PR ，以下擷取重點

新的實驗環境: Tensorflow Serving

Tensorflow 作為被廣泛接納的機器學習框架，許多公司會利用它來訓練自家模型。但常會發生:

1. 工程師懂得寫跟訓練模型，卻沒有相關部署知識
2. 需要花額外時間撰寫 RESTful API server 來服務請求

因此「如何將機器學習模型快速部署到生產環境上」，一直是許多人心中的痛。

有鑑於此 Tensorflow 官方推出 (Tensorflow) Serving 試圖降低模型產出到部署之間的難度。 只要將模型放到對應資料夾內，Serving 偵測到模型後便會啟動對應 API server 服務，甚至版本異動時亦會將請求流量逐步轉移至新的模型。

然而，實際營運上考慮的因素絕不單單只有「將模型利用 API server 來服務預測請求」這麼簡單。

更多數情況我們會問的是:

如何大規模部署機器學習模型? (How to deploy ML models at scale?)

這個問題就牽涉到「底層架構」與「服務水平伸縮」等等議題。

介紹

前陣子 Cloudflare global outage 導致許多服務突發性異常，7/12 號時 Cloudflare 針對此次意外釋出了一篇文章， 其中清楚的解釋整件事的來龍去脈。內容部分就不多提，有興趣的人建議一定要看。

針對文章個人覺得幾點特別值得注意:

完整解釋 Cloudflare 整套測試、部署流程

一般比較少見大型公司完整說明內部的 CI/CD 流程，透過這篇文章能一窺出其內部針對產品上線、測試、驗證的流程，以及發生回滾 (rollback) 除錯的概略圖。

Introduction

故事背景稍微介紹一下，使用者反映 Fission基於 Kubernetes 之上的 FaaS (Function-as-a-Service) 框架 在週末突發性的無法正常運作。作為一個興趣使然的工程師，遇到使用者反應問題當然要 (義不容辭) 協助排解。 經過各種遠端通靈一種在不知曉確切運作環境或對於問題毫無頭緒下，仍然嘗試除錯的技術 ，發現問題發生在當要初始化使用者的 function 時出現。

Fig. 1 Fission function pod specialization process

整個初始化流程如 Fig. 1，首先 executor 會送出 specialize 請求給 fetcher，讓它取得 function code 後放至 share volume 內。 再由 fetcher 呼叫 env runtime，讓其載入 function code 後服務 HTTP 請求。

"logger":"fetcher"
"msg":"error connecting to function environment pod for specialization request, retrying"
"error":"dial tcp 10.58.152.224:8888: i/o timeout"

從日誌上來看錯誤是 i/o timeout。奇妙的地方在於本來是呼叫 localhost，卻顯示 10.58.152.224 超時 ?!

而用戶反應問題是在公司開始導入 proxy 後發生的，到這邊可能性有兩個:

1. Proxy 設定出現異常，導致 Pod 內部的本地端 HTTP call 被攔截送往其他地方
2. DNS 解析出現錯誤

原本想說會不會跟 docker 的 NO_PROXY 設定相關，但該設定主要跟 pull image 相關且測試後也驗證不是這個原因。

事已至此，剩下 DNS 解析出錯的可能性，也只能開始往最瞎的方向開始思考:

是不是在 namespace 底下有個名為 localhost 的服務存在？