從菜鳥開始,工程師學 pitch

TGONext 導師計畫 - 技術創業組,心得分享

ta-ching chen

1 minute read

TGONext - 導師計畫

在接觸 Kubernetes 的幾年間,看著相關領域快速的發展,自己也因為興趣參與開發在其上的無伺服器框架 Fission。 去年因外力使得出國計畫有所改變,後來決定投入 Kubernetes 相關的領域創業,成立原格科技 Srcmesh

有句話說得很好: 「一個人可以走得很快,但一群人才能走得長遠」,當角色從工程師轉變身份成創業家這句話感受更為深刻,因為得強迫自己跳出舒適圈學習許多不同領域的東西, 才有辦法讓公司生存下來,而看到 TGONetworks 舉辦導師計畫的「技術創業組」時就知道正是自己所需要的。

組內每個人所在的創業階段各不相同,遭遇到的狀況也有所不同,從產品開發到團隊建立,再到公司遇到危機該如何處理以確保公司持續經營, 而這些正好作為未來公司成長的養份避免落入同樣陷阱中。

心得分享

自己剛好是在創業剛起步的階段,於是趁機和組內導師與組員的 pitch 產品內容,後續根據反饋整理幾個問題與感想分享給各位:

  • 使用情境切入,更容易讓參與者融入情境 (內容太過工程師化,亮點不夠明確)
  • 放大痛點,告知用與不用這套解決方案的差別
  • 不要只提到「能改善」,要更具體提出「改善多少」
  • 不要怕於利用過去獲得的 credit

收費課程 - Kubernetes 容器編排平台導入

讓機器管機器,你才能專注在最有價值的工作上

ta-ching chen

1 minute read

課程推廣

為應付更龐大的流量,許多企業開始將傳統架構轉型成微服務架構,而微服務架構往往牽涉到部署與管理大規模伺服器叢集, 而 Kubernetes 不僅使用到容器技術,更結合 Google 自身多年經驗,將微服務管理變得更為輕鬆。

近年來許多 DevOps、SRE 職缺開始將 Kubernetes 列為面試加分選項,相信未來技術越加普及後會逐漸成為職缺必要條件。用一堂實體課程時間,學習新技能讓自己職業生涯越走越順!

但對於剛接觸的人來說,常會被不同用途的 Controller、Volume、Service 概念搞得頭昏眼花。因此於 2020/10/17、10/24 我會開設 2020 北部實體線下課程 「Kubernetes 容器編排平台導入」, 讓更多人能真正瞭解 Kubernetes 的精髓,並能真正應用於他們日常工作上。

課程內容

內容會從 Kubernetes 基礎開始教起,接著學習進階內容最後上機練習。

你會學到在這個部落格內的 Kubernetes 內容的精華版,並且我會分享使用於生產環境的經驗,以及該如何避免採坑。

基礎概念

  • Container (Docker)
  • Kubernetes 核心架構介紹
  • Kubernetes Pod
  • Kubernetes Service
  • Kubernetes Volume
  • K8S Configuration
  • 實戰訓練
    • 指令使用與聲明式宣告
    • 物件組合與應用
    • 系統操作、除錯、分析

Google 如何進行 Code Review - 6

一窺 Google 內部程式審核的指導原則 - Handling Pushback in Code Reviews

ta-ching chen

1 minute read

原文

Handling Pushback in Code Reviews (如何面對被推遲處理的評論)

有時開發人員會推遲處理程式審查產生的評論。要麼他們不同意你的建議,要麼他們會抱怨你太嚴格了。

Who is right? (誰是對的)

當開發人員不同意你的建議時,請先花點時間考慮一下他們是否是正確的。因為通常他們比你更接近程式碼,所以他們可能真的比起你來說對程式的某些層面具有更好的洞察力。 他們的論點有意義嗎? 從程式品質的角度來看它是否合理? 如果是的話,讓他們知道他們是對的,然後讓問題沈下去。

但開發人員也並不總是對的。在這種情況下,審核者應該更進一步解釋為什麼認為自己的建議是正確的。 一個好的解釋通常展示了「對開發人員的回覆的理解」以及有關「為什麼被要求對出做出改動」等資訊。

尤其是當審核人員認為給出的建議會改善程式品質時,便應該繼續宣揚自己的論點。只要他們相信所需的額外的工作量最終會改善整體程式品質。

提高整體程式健康狀況這件事,往往是經由每個微小的改動來發生

有時往往需要幾番解釋一個建議才能讓對方真正理解你的用意。切記,始終保持禮貌, 讓開發人員知道你有聽到他們在說什麼,只是你不同意該論點而已。

Google 如何進行 Code Review - 5

一窺 Google 內部程式審核的指導原則 - How to write code review comments

ta-ching chen

1 minute read

原文

How to write code review comments (如何寫審核評論)

Summary (總結)

  • 和藹且有禮貌的
  • 解釋你的理由
  • 在「給出明確的方向 (explicit directions) 」與「只點出問題點,讓開發者做決定」之間作出權衡
  • 鼓勵開發者簡化程式或增加註釋,而非向你解釋這問題有多複雜

Courtesy (禮貌)

一般而言,對你正在審查其程式的開發人員來說,保持禮貌與尊重的同時,確保評論是非常清楚和有幫助。

一種方法是確保

永遠對程式碼發表評論,而永遠不要對開發人員發表評論

你可能並不總是必須遵循這種做法,但你絕對要在說出會使人不安或有爭議的事情時使用這種方法。例如:

  • 糟糕的例子:

Why did you use threads here when there’s obviously no benefit to be gained from concurrency?

為什麼**「你」**要在使用併發沒有明顯益處時使用 threads?

  • 好的例子

The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. Because there’s no performance benefit, it’s best for this code to be single-threaded instead of using multiple threads.

在我看來,這裡使用併發模型會增加整體系統的複雜性,卻沒有帶來任何實際性能效益。由於沒有性能上的效益,我們最好在這個程式裡使用 single-threaded 而非 multiple threads。[1]

Google 如何進行 Code Review - 4

一窺 Google 內部程式審核的指導原則 - Speed of Code Reviews

ta-ching chen

1 minute read

原文

Speed of Code Reviews (程式審核的速度)

Why Should Code Reviews Be Fast? (為什麼審核速度要快)

在 Google 我們優化開發團隊共同生產產品的速度,而不是優化個人開發程式的速度。

個人的開發速度很重要,但它不如整個團隊的開發速度 (velocity of the entire team) 那般重要。

當程式審核很慢時,會發生以下幾件事:

  • 團隊整體的速度下降

是的,沒有快速回應的個人 (individual) 的確完成自己所屬的工作。但同時也表示,對於團隊其他人來說重要的新功能與缺陷修復將會被延遲數天、數週甚至數月,只因為它們正在等待審核與再審核。

  • 開發人員開始抗議程式審查流程

若審核者每隔幾天才回應一次,但每次都要求對 CL 進行重大更改的話,那麼開發人員可能會感到非常沮喪與覺得困難,而這通常會演變成對評論者的「嚴格」程度的抱怨。 如果審核者請求相同的實質性更改 (且確實可以改善程式品質狀況),但在每次開發人員提交新的改動時都能快速反應的話,這些抱怨往往會消失。

大多數關於程式審查過程的抱怨,往往可以通過加快流程來解決。

  • 程式品質會受到影響

當審核評論很慢時,會造成開發者提交不完全盡如人意的 CL 的壓力越來越大 [1]。評論的越慢也會阻止他人進行程式清理 (cleanups)、重構 (refactorings)、甚至是對現有 CL 的進一步改進。

  • [1] 還記得前面所說的嗎? 沒有完美的程式只有最佳的程式!

How Fast Should Code Reviews Be? (那程式審核應該要多快)

如果你並沒有處於需要專注工作 (focused task) 中間時,那麼你應該在 CL 被提交後儘快進行審查。

回應程式審查最長的極限是一個工作日是 (意即隔天早上的第一件事)

若遵循以上指南,意味著一般的 CL 應該在一天內得到多輪審核 (如果必要的話)。