程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第八章讀書心得

續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得.

此為讀後重點筆記,好書值得大家購買閱讀.

本章是本書的最後一章,我終於 K 完這本書了,雖然頁數不多,但看原文速度真的慢很多啊!

注重效率的團隊 將之前章節強調的觀念,以套用在團隊的立場在強調一次. 成員間要多交流,大家互相學習及成長,把好的開發流程或概念帶進團隊來,整個團隊不斷往前邁進,公司對外才會更有競爭力.

無所不在的自動化 告訴我們電腦是處理重覆性工作的專家,懶惰則是好的工程師需要具備的特性之一,利用工具或自己開發程式,把需要浪費時間的工作交給電腦處理,省下來的時間再去學新的東西.

無情的測試 強調測試並不是用完即丟,或是寫完就不用去修改它的. 測試程式應該是不斷被執行,並且會隨著程式碼演化的.

代碼文檔不分家. 註解是程式設計師最好的朋友,多花一點時間到離職都可以受用無窮,大腦就應該拿去裝一些需要思考運轉的東西,而不是用來挖掘當初為何自己要這樣寫的理由. 另外,每一份印出的文件都只是當時專案的快照,並不代表其永久有效,透過使用開放編輯的方式,讓文件跟程式碼同步演化,文件才有其存在的價值.

巨大的期望 需要與客戶持續互動,才能確保專案是朝著客戶想要的方向邁進. 回饋的頻率拉得越長,其修改所需的代價也會越高.

傲慢與偏見 - 很日劇式熱血的一小章. 反正就是要激發讀者身為職人的自尊,我以我的程式碼為榮,別人看到作者是我就知道這是品質保證. 因為自尊所以更認真保證品質,品質提高別人對自己的 Credit 變高,如此便是一個良性的循環.

第七章 Pragmatic Projects

Pragmatic Teams

• 開發團隊必須重視程式碼的品質.
• 開發團隊必須察覺不論是專案內(ex:新需求)或專案外(新技術)的變化.
• 鼓勵團隊內的成員互相交流.
• 建立成員對開發團隊的認同感.
• 在一個專案中,給予每個人負責不同面向的責任,以免多個人都在做一樣的事情.
• 不要看完書就急著要求團隊開始實行,維持夠好的規範和風格即可,而不是將額外的負擔加諸在開發團隊上.

Ubiquitous Automation

• 當你發現自己不斷在重複某些步驟時,那就是該自動化的時候到了.
• 電腦本來就適合用來處理重複性的工作.

Ruthless Testing

• 透過測試能盡早發現問題.
• 發現問題後,將該問題建立成測試條件.
• 程式本身沒有問題,但給個不是使用者想要的東西,那還是有問題.
• 使用者不好上手的操作流程,也算是有問題.
• 越解耦的程式碼,若容易做模組測試.
• 測試覆蓋範圍的重點,不在於有測到所有程式碼,在於有測到所有的狀態.

It’s All Writing

• 再強的記憶力也抵不過一支筆.
• 註解說明為什麼要做這件事,動機和目的. 而程式碼本身會說明如果做這件事.
• 良好的變數/方法命名習慣,讓程式碼更容易被閱讀.
• 雖然這段程式碼你可能只會寫這麼一次,但它可能之後要被閱讀好幾百次.
• 比”沒有意義命名”還糟的是 – “讓人產生誤解的命名”.
• 利用工具或自寫程式,將文件的表現方式(ex: PDF, HTML …)從內容中獨立出來.

Great Exceptions

• 寫出來的東西不符合使用者的期待,那就是失敗.
• 藉由不斷與客戶互動(ex: 展示雛型),來確保成品是客戶所預期的.
• 試著超出使用者所預期,只要超出一些些,讓使用者覺得我們真的是想做一個很好的系統.

Pride and Prejudice

• 在自己的程式碼上署名以示負責.
• 尊重夥伴所寫的程式碼,你怎麼對他們,他們就怎麼對你.