The Pragmatic Programmer - 務實的哲學

June 07, 2020

千呼萬喚 終於等到Pragmatic Programmer 20週年紀念版 如果沒聽過這本書 你大概也聽過程序員修煉之道︰從小工到專家這本暢銷了20年的書 終於等到了再版

在再版裡面 刪掉了比較過時的內容和範例 收集了20年來收到的feedback 在讓這本書的內容也可以適用於2020年的程序員 但在我細細品嚐後發現 其實很多人生的哲學並不是只適用於程序員 各行各業看了都可以有所收穫

因為每個篇章的篇幅都不長 所以筆記也用條列式紀錄

第一章: 務實的哲學

這本書寫的是你的事業 你的生活 讓你成為一個更好的程序員

務實的工程師是有責任心的 他們不會因為疏忽而讓專案崩潰 而且樂於擁抱改變

這是你的人生

你擁有改變一切的力量

你的工作環境糟糕嗎 你的工作無聊嗎 試著去改變它吧 Martin Fowler說 你可以改變你的組織 或是改變你的組織

如果你擁有的技術已經開始落後 就從下班時間中擠出時間學新東西吧

貓吃了我的原始碼

所有弱點中 最大的弱點就是害怕顯得軟弱

The greatest of all weaknesses is the fear of appearing weak

務實思考的哲學就是為你自己的行動負責 讓你的團隊可以依賴你 當真的發生錯誤時 承擔責任 提供解決問題的方法

最重要的是 不要怪東怪西 不要把問題怪給供應商 管理層或是你的同事 雖然他們都參與其中 但主要的成敗當然還是取決於你的解決方案 就算真的是供應商出包 如果沒有備案那就是你的錯 你跟老闆說供應商出包不如直接跟老闆說你的貓把你的code吃掉算了

提供解決問題的選擇 停止製造爛藉口

在跟別人說某件事為什麼辦不到的時候 先想像如果是別人用同樣理由跟你說的話你會怎麼想

軟體亂度

破窗效應是指 如果有一棟美麗的建築物 那這建築物就會一直保持美麗 但如果今天這個建築物有一個破窗戶 那麼很快的 就會有第二扇破窗 開始有人塗鴉 丟垃圾 不久之後這棟建築物就變廢墟

不要讓破窗存在

因為消極會傳染 當你的程式碼有一個不優雅的地方 你擺在那邊不理他 那之後來的人也會覺得不用那麼認真維護 反正已經有一扇破窗在那了我擔心什麼呢

一樣的 一扇破窗 一段設計糟糕的程式碼 一個糟糕的管理決策 都是一樣 一發現就要馬上修好

石頭湯與煮青蛙

這篇很有意思 我們來看一個小故事

三個士兵從戰場返回家鄉，在路上餓了。他們看見前面有村莊，就來了精神——他們相信村民會給他們一頓飯吃。但當他們到達那裡，卻發現門鎖著，窗戶也關著。經歷了多年戰亂，村民們糧食匱乏，並把他們有的一點糧食藏了起來。

士兵們並未氣餒，他們煮開一鍋水，小心地把三塊石頭放進去。吃驚的村民們走出來望著他們。

“這是石頭湯。”士兵們解釋說。

“就放石頭嗎？”村民們問。”一點沒錯——但有人說加一些胡蘿蔔味道更好……”一個村民跑開了，又很快帶著他儲藏的一籃胡蘿蔔跑回來。

幾分鐘之後，村民們又問：”就是這些了嗎？” “哦，”士兵們說：”幾個土豆會讓湯更實在。”又一個村民跑開了。 接下來的一小時，士兵們列舉了更多讓湯更鮮美的配料：牛肉、韭菜、鹽，還有香菜。每次都會有一個不同的村民跑回去搜尋自己的私人儲藏品。 最後他們煮出了一大鍋熱氣騰騰的湯。士兵們拿掉石頭，和所有村民一起享用了一頓美餐，這是幾個月以來他們所有人第一次吃飽飯。

來源: 《石頭湯和煮青蛙》

這個寓言故事的寓意是什麼呢 村民很好騙所以被耍了嗎 不是 是士兵如何發揮催化劑的效果 利用村民的好奇心 來協作完成一個共同的目標

不夠具體嗎? 好我講的具體一點 今天你確切的知道該做什麼 以及如何去做 但你需要的資源在別人手上 你去跟別人要資源時 會看到別人呆滯茫然的眼神 因為每個人傾向保護自己的資源 所以你可能需要經過審預算等等複雜的事 這叫做啟動疲勞(start-up fatigue)

那該怎麼辦呢 拿出你的石頭 弄清楚你能合理要求什麼 讓團隊的人看一下未來的長相 然後好好的發展他 大家就比較不會保守的只想守著自己的資源 因為大家想要加入一個持續成功的行動

夠好的軟體

足夠好的軟體 就是最好的軟體

把品質視為一種需求 讓你的客戶參與功能取捨 許多用戶寧願今天就可以使用有些粗糙的軟件 也不願等待一年才能獲得閃亮的版本

繼續前進 讓您的代碼保持一段時間 這可能不太完美但不用擔心 因為它永遠不可能完美 知道何時該停手也是門藝術

你的知識資產

對知識的投資永遠都得到最好的回報

An investment in knowledge always pays the best interest.

知識和經驗是會過期的資產 當你的知識下降 你對公司以及對客戶的價值也下降 以下是增添知識資產的建議

1.每年學一個新語言

2.每個月一本技術書

3.偶爾要讀非技術書 習得soft skill

4.去上網路課程或是conference

5.體驗不同環境 linux vs windows

6.了解行業的發顫

當你有了學習的機會 比如說你有個疑問不知道答案 那你千萬不要就讓它這樣過去 把找答案當成是對你的挑戰

最後一點 是要批判性思考(Critical thinking) 要確定你建構的知識資產是正確的 不受到供應商或媒體的炒作 比如說不要因為熱門(搜尋引擎第一個結果)就覺得是對的或是最好的 書店推薦的書不一定是好書 不要小看商業主義

批判性的分析你讀到聽到的東西

Critically Analyze What You Read and Hear

批判性的分析本身就是一門完整的學科 對於每一個疑問 記得要:

1.問為什麼

2.問誰會得到好處

3.問時空背景

4.何時何地可用

5.之後會發生什麼

6.為什麼會有這個問題

溝通

如果不懂得溝通 不懂得包裝自己 即使你有著最好的程式碼 最實用的思想最終都是徒勞無功

身為開發人員 我們一天花了很多時間在溝通交流 既然如此就要把它做好

1.你必須了解你的聽眾 不同聽眾 表達的方式就不一樣

2.選擇合適的溝通時間 比如禮拜五的六點 那大概沒人有心請認真聽你說

3.讓文件看起來很棒 學習一些文書處理程式 拼字檢查等等 不要讓你的好主意被這些小瑕疵掩蓋過去

4.可以的話 讓你的聽眾參與文件的創作 提早理解他們的想法 並且建立良好的合作關係

5.當一個聆聽者也很重要 透過提問鼓勵人們交流 把會議對成對話

6.回覆別人 回覆別人的email 回覆別人的問題 讓別人感覺被重視

7.說明文件要寫好 何謂寫好呢 比如說並不是所有函示都需要寫javadoc 這樣只會增加維護的難度 你不用為了非API撰寫它為什麼這麼做 它的企圖和目標 你的程式碼本身就應該要做到這件事了 你要寫的註解是在其他地方無法紀錄的東西 比如工程上的trade-off 為什麼做這個決策 放棄了哪些其他選項等等