1. 程式人生 > >讀《程式碼整潔之道》

讀《程式碼整潔之道》

程式碼整潔之道-程式設計師的職業素養.jpg

借部門的一次讀書會上,我挑選了 Bob大叔的《程式碼整潔之道》這本書。在讀了這本書的前面幾章節時就覺得感觸極大,今天剛好讀完,希望下面我的感受也能幫到想成為專業程式設計師的你。

什麼是專業程式設計師

專業程式設計師並不好當。
作為一個專業程式設計師,最重要的一條是堅守原則,為自己的承諾負責。如何堅守?在面對外界(專案經理,產品經理,客戶等)強制的要求時,應該用自己專業的知識去衡量問題的可行性,而不是輕易妥協。
“試試看” 這類的詞不應該從一個專業程式設計師口中說出,因為你說的“試試看”對你來說是代表著可能完成,可能完成不了,但是在外人聽來,他們認為你說的是可以完成,而最終當問題沒法在他們預期的時間完成時,受到影響的不單單是公司的利益,你的信譽也收到了損害。
所以,在面對一個自己覺得沒法在指定時間完成的任務,應該堅決的說不

,並且堅持這個底線。而在覺得問題可行的情況下,也應該準確的說是,併為自己的承諾負責。

專業的程式設計師並不代表什麼都懂,他們勇於接受他人的幫助,知道什麼時候該結對程式設計。同時,他們也樂於幫助其他人,輔導新人。他們會抽出時間去閱讀,編碼來提升自己。

專業的程式設計師對自己的每一行程式碼負責,沒經過測試的程式碼絕不提交。
我們應該把“QA應該找不到任何錯誤”作為努力目標,對QA找到的每一個問題,都應該高度重視、認真對待。應該反思為什麼會出現這種錯誤,並採取措施避免今後重犯。

測試驅動程式設計(TDD)

什麼是TDD?簡單來說就是:先寫測試,再寫功能。這聽起來好像很扯,但是瞭解其意義之後,你會為TDD喝彩。
因為自己這段時間也在負責部門 React-Native 專案單元測試的實踐(不過並沒有執行TDD,而是採用了相反的方式,即先功能後測試)。
過程中,深刻體會到單元測試其中的一個好處:強迫自己抽象,再抽象

。為了讓自己所寫的函式可測試,你需要做到儘量讓其內部邏輯簡潔,單一,耦合性低,否則你根本就測不了它,或者說你要寫更多的case才能完整覆蓋它。
其好處自然就很明顯了:
1. 通過測試的程式碼,我們可以很有信心的將他提交;
2. 簡潔的程式碼,既提高其可讀性,也提高其健壯性。

TDD相關的書籍我沒閱讀過,藉助作者的簡單描述,我在專案的一個模組重構上做了實踐,效果是真不錯。之後也打算更深層次的去理解它,並在以後的專案上加以實踐。

作者提到了TDD 的三項法則,這裡摘抄了下來:
1. 在編好失敗單元測試之前,不要編寫任何產品程式碼;
2. 只要有一個單元測試失敗了,就不要再寫測試程式碼:無法通過編譯也是一種失敗情況;
3. 產品程式碼恰好能夠讓當前失敗的單元測試成功通過即可,不要多寫。

時間管理

這部分應該說不單單是面向專業程式設計師,而是面向所有希望走向成功的人。
毫不誇張的說:能否對自己時間有個好的管理是決定你能走多遠的必要條件。但是我們大多都做的不夠好,甚至一塌糊塗。從專業程式設計師角度,作者也說了下面幾點:
- 如果發現參加某個會議是在浪費時間,就應當想個禮貌的辦法退出來,繼續參加對你沒有太多意義的會議,是不專業的行為。你有責任合理分配老闆給你的時間和金錢,所以,選個合適的機會離席,並非不專業的行為。
- 如果觀點無法在短時間(5-30分鐘)裡達成一致,就永遠無法達成一致。唯一的出路是,用資料說話。
- 注意力點數會隨時間流逝而減少,使用合理的方式進行恢復:充足的睡眠(不熬夜的情況下7-8個小時足夠了);也可以選擇小憩,看雜誌等方式;另外可以通過訓練肌肉注意力(騎車,吉他等方式)來提升自身的心智注意力。
- 番茄工作法
- 如果你掉進了坑裡,別挖
- 陷入泥潭,別繼續往前

在參加會議這塊,我經常表現的不夠專業,參加了一個會議或者講座,發現根本聽不下去或絕對對自己沒什麼用處,但是又不好意思中途離開,所以就乾脆玩起了手機。最後講座沒收穫,自己時間也浪費了。在看了作者說的話後,默默的給以後的自己提了個醒。

番茄工作法的書籍我也讀過,也因此在App Store上買了個便宜的軟體(窮哭),但是實踐起來是真的難,排除掉那些繁瑣的步驟,你需要做的就是:
1. 列出你當天要做的事情;
2. 啟動番茄鍾(一般設定25分鐘),開始執行任務;
3. 時間到就停止手中的事情,休息5分鐘。(3個番茄鍾結束後休息15分鐘)

難就難在,在番茄鐘的25分鐘裡,你需要專注,高效率的去執行。但是,自身的注意力以及外界的突然打擾總是會讓我分心。這一分心,回頭再看下時間,番茄鐘快結束了,我還什麼都沒做呢。
番茄鍾工作法其中一個重要原則是:嚴格按照番茄鍾去工作,該工作時認真工作,該休息時認真休息。這樣做的好處是:可以培養你在短時間內快速進入專注狀態,因為你必須在這25分鐘裡高效輸出。
番茄工作法我目前也在實踐著,不過每次受到外界因素影響時我都沒法說出:等我20分鐘之類的話。當我能很好的去遵循番茄工作法時我也會給大家分享下我更多的心得。(番茄鍾到了,我休息5分鐘)

程式碼總是會隨著業務功能的增刪改而變的混亂,之前設計很好的實現方式,也會逐漸不適用,這時是選擇繼續用這種設計方式去實現新功能,還是推翻重構呢?作為專業程式設計師,應該清楚的認識到,繼續以這種方式去迭代,只會導致後面開發效率越來越低,程式碼也變得很難維護。剛進入泥潭你可能可以繼續往前,但是你會發現,你會越走越慢,最後進退兩難。所以,重構是明智的選擇。

引用書的最後,觸動到我的一句話:

你還記得你寫的第一個程式跑起來的那個時刻嗎?它改變了你的生活並指引你大步踏上程式設計之路了嗎?