The Clean Coder 心得、摘要與補充


前陣子把 《The Clean Coder》(中譯: 無瑕的程式碼 番外篇-專業程式設計師的生存之道) 看完,剛好可以回答一個網路上最常看到的問題之一:

菜鳥工程師與資深工程師的差別是甚麼?

很多人會覺得是技術上的差別,例如菜鳥只會懂得技術比較少,只會使用框架,會用的工具比較少等等。相反的資深工程師懂得比較多技術,能告訴你技術的差別,能針對不同情境下選用最佳的架構,然後因為踩過的地雷很多,通常都可以直接避開問題等等。

我一開始也以為是這樣,當然這的確也是兩者的差別之一,但不是最關鍵的部分—待人處事才是。《The Clean Coder》 這本書就是完全在針對一個專業有素養的工程師,講述如何與人溝通以及如何去把寫程式這件事做好。事實上,書中講述的概念不只適用工程師,而是適用所有行業,只不過用軟體開發舉例罷了。

說「Yes」與說「No」

我們都會被交付任務,對象包含主管、PM、同事或客戶,學會正確的說「Yes」和「No」。一個專業人士不該過度承諾,面對做不到的事要說「No」,並給予對方合理的承諾,在自己能力範圍內說 「Yes」。

能就是能,不能就是不能,不要說試試看

書中給了幾個例子,說明 Yes 和 No 使用情境,要親自去閱讀才能感受那個情境。我覺得要能正確的說好與不好,需要具備兩個能力,一個是對事情高度掌握,能清楚分析複雜度和執行期限,並且還能說服對方接受你的論述,過程中勢必會需要大量溝通。

精實程式開發

如同一般人認知,專業的程式設計師應該具有更好、更有效率的做事方法。有點老生常談,但值得自我檢視一下。

心情

程式設計師是一個需要創造力的工作,如同藝術家,我們會需要「靈感」和「專注力」。有些人寫程式需要有固定的儀式,有些人喜歡在半夜打 Code,有些人喜歡聽音樂邊寫,有些人需要保持自己的節奏。總之,保持好心情,調整成自己最舒服的樣子,然後開始激發創意。

幫助

大家是同一個團隊,互相幫助是彼此職責。不吝嗇幫助別人,自己也許獲得更多,此外也不要自負不肯找人協助,有時候我們會需要他人幫忙,像是有個很有趣的除錯方法—

在程式的偵錯、除錯或測試過程中,操作人耐心地向小黃鴨解釋每一行程式的作用,以此來激發靈感與發現矛盾。


你的同事就在扮演小鴨的腳色。此外藉由 Code Review 的過程,幫忙檢查同事的程式碼時,其實大家也是在互相切磋。

測試的重要性

書中一直強調測試的重要性,當然我們都理解,是吧?
既然書中已經給了一些例子,我想這邊我分享我自己的親身經歷。

以前我還在 Cloudmosa 實習,有一天我發現,為什麼 Puffin 在網頁中有連結的地方上面點右鍵選單,加入書籤的時候,會抓不到連結的標題。

這個標題其實就是 <a> 標籤匡著的文字內容,或是他有聲明 title 是什麼。總之,加入書籤的對話框跳出來,標題欄位會是空的,所以我就要解這個 bug。研究了很久,從堆疊一層層追蹤,發現是 Mango (Puffin 的瀏覽器引擎實體,參考 )傳過來的資料少了東西。所以解法也不難,在 Mango 與 Puffin 之間的 Protocol 新增傳送的資料就好。

然後我就很開心啦~Puffin 可以順利收到資料,加入書籤的對話框就有標題了。然後隔兩天,我收到 CTO Sam 的信,「Tiger 你的 patch 會讓我們的服務掛掉」理由是,Puffin 和 Mango 都有非常多版本,所以在改 protocol 的時候,要考慮向下相容性。不過 Sam 很好心,幫我直接修好,不過嚇得我一身冷汗。

這件事告訴我兩件事,一是寫測試真的很重要,如果有完善的測試,這種錯誤會即時發現,不過因為我開發的是開發分支,所以不會每個 commit 都跑完善測試。二是考慮向下相容性應該是 common sense,但因為我太菜了,所以忽略了這麼重要的事情。

書中很強調測試驅動開發(Test Driven Development, TDD),我也認為 TDD 是比較好的開發方式,既可以將規格、邏輯制定好,又不會陷入之後很難寫測試的困境。書中很張狂的聲明:

TDD 的各項優點表明了一件事情,不使用 TDD 就說明你可能還不夠專業 — The Clean Coder

不過你依然要視情況做出最佳選擇,沒有某個法則是鐵則。

通常測試就會被包在持續開發與持續整合(CI/CD)的流程,更廣泛來說他是維運(DevOps)的一環,其中包含單元測試、整合測試、交付測試、品質測試等等,這部分就留給大家自行探索。

練習

當我們越來越資深,可能就會越來越少去寫很簡單的東西,像是如何寫一個 Quick Sort,每個想要面試的人都會去刷 LeetCode 然後刷完有工作之後就忘了—如同我們應付大學考試一樣。

這種牛刀小試其實對維持手感和靈感很有幫助,老實說在寫這邊文章的同時,要我在 15 分鐘內寫出一個不會有 bug 的 Quick Sort 大概也是困難重重,概念還記得但就是生疏了。

As the saying goes: “Practice makes you better"

此外多寫一些小專案也挺不錯,資工系的學生即便修過 Compiler、OS、Compuer Architecture 都不見得自己寫過一個完整的系統,只懂得原理而沒有親手做過,其實可以等於不會,因為現實是殘酷的,實務總是比較難。

很多人覺得自己寫程式速度已經夠快,那是因為他們沒有想要更快

不知道大家有沒有看過 Jim Huang (jserv) 在演講的時候直接現場打 Code,我認為 Live Coding 真的很困難,畢竟寫程式就是在創作,需要靈感、需要醞釀。但別人做得到寫得快又寫得好,我們加強練習也做得到。

時間、評估與規劃

每個人時間都有限,如果工作效率不好,那就要看看自己時間分配和做事方法要不要改進。番茄工作法可能會是不錯的做法,也就是集中精神專心衝刺一段時間工作,然後休息一下,如此往復。人的精神和身體是有極限的,所以過度加班和睡眠不足都不是好策略。

開會本身是成本很高的事情,公司花了很多錢聘請每個人,如果開會本身的價值小於耗費大家的開發時間,那就完全不值得。有一些方法,例如 Agile 或 Scrum,可能都是可以參考的做法。此外自己也該只選擇自己有義務或有助益的會議參加即可。

預估就是承諾,當你跟別人說「Yes」的時候,你就有責任在期限內交付任務。當然你可以把時間抓寬一點,也許是兩個標準差,這樣可以確保你 99% 機率沒問題。

設計規劃

區分 Junior、Senior、Lead 的方式也包含對開發規劃與評估的能力

  • Junior 通常在開發時,不知道從何規劃,做事就是想到甚麼做甚麼
  • Senior 通常會有一個好的規劃,知道怎樣將任務拆解成步驟,甚至產生出設計文件,能區分事情重要性
  • Lead 包含 Senior 特質,讓專案有條有理的運作,並可以作換位思考,將整個團隊放在對整個公司都有利的立場

所以工程師的差異不僅僅只是技術懂得多不多而已。

團隊協作

除非你是獨立工作者,不然一定是一個團隊。團隊就會包含協作開發、權責分配、專案管理。如果沒機會接觸大型的協作開發,我建議可以去嘗試貢獻開源專案,例如 Mozilla 的 瀏覽器引擎就是很好的練手地方,裡面共有快一千名貢獻者,你將會看到完整的大型專案開發流程。一個團隊怎樣有凝聚力,沒什麼好說的就是溝通、溝通再溝通,而溝通是一門藝術,任何專業人士都該具備。

輔導

最後,任何資深的工程師都應該照顧和輔導比較資淺的工程師,程式設計師就像工藝中的學徒,透過不斷學習來成長。好的導師(mentor)可以協助你快速成長、少走很多冤枉路和在你心中立下榜樣。大家都受過別人幫助,我們也應該熱心地去幫助後輩。長江後浪撲前浪,青山還比青山綠。

總結

本文整理了《The Clean Coder》一書中的重點,並且我根據自身經驗加了不少詮釋。成長過程中我在不少公司待過,看過不少工程師,見過各種文化,即便我在業界的時間不多,但看這本書也是頗有感觸,希望我的一些見解可以幫助到其他人。

那麼?我是 Junior 工程師嗎?縱橫本文的觀點,是的,我依舊還只是個菜鳥,精進自己的路還很遙遠。