学习、纪律与交流——《Clean Coder》读后感
生活随笔
收集整理的這篇文章主要介紹了
学习、纪律与交流——《Clean Coder》读后感
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
? 看Bob大叔的書,還要追溯到《敏捷軟件開發——原則、模式與實踐》(http://book.douban.com/subject/1140457/)。這是一本改變我對軟件看法的書,也使得我徹底擺脫了一個純編碼者的思維,繼而轉向以研究設計架構、分析用戶需求為中心的軟件開發方式,可謂一部有重要影響力的書。這個以后會有專文描述,在此不贅述啦。
其后看了《Clean Code》(干凈代碼)(http://book.douban.com/subject/3892588/),此書可以認為是敏捷軟件開發一書的具體化。那本以思想為主,這本以代碼細節為主。看完之后對自己編碼質量的要求又更進了一步。可以說是打開了激發了我精進代碼質量的動力。 這次看到這本雖然正文加附錄僅僅二百零四頁的《Clean Coder》(干凈編碼者——專業級程序員編碼法典)(http://book.douban.com/subject/6114900/), 心里異常激動,前兩本如果說側重點還偏于原理和技術的話,這一本從名字上看,就是偏重人的。本來想翻譯一下給朋友看,后來發現國內的出版社有出版計劃,我 就決定先看完英文版,等中文版出來再和朋友們一起討論、學習。讀書的時候做了很長的筆記,如果全寫出來,恐怕抓不住重點。這里就根據幾條主要的線索把一些 重要的問題整理出來,以輔助大家閱讀和理解此書。 全書僅僅十四章。我自己是在順序閱讀中,是沿著三大主線進行思考的:學習、紀律、交流。 前三章可以作為一組,從“職業精神、學會拒絕、學會承諾”三個切入點,講述了作為一個職業程序員,要學會從工作經驗中學習為人處世之道。具體說來,要 會依據一些周圍的情勢、同事的語氣、自己的能力與時間安排等因素,決定是應該拒絕一個新功能的加入還是應該承諾在一個給定的時間內按時交付它。我在學會拒 絕和承諾新需求的方面,一直做的很不到位。看了此書我才發現,要根據整個工程所處的狀態,向隊友陳述工程的實際情況。只有大家瞭解了實際情況,才能作出一 個建設性的答案,以決定一個新功能是應該在下一版在做,還是應該加班做好,抑或采用一些臨時方案先使它上線。關于工程進度,表面的和諧和不夠深入的交流, 都是導致工程延期的重要因素。 中間六章可以作為一組,從“編碼、測試驅動開發、例行代碼功力訓練、驗收測試、測試策略、時間管理”等六個方面講述了一個專業程序員(即本書標題所謂的“干凈編碼者”)所應具有的工作行為準則。 在編碼這章中,作者講述了專注編碼的重要性。同時也強調了過于專注,而不時時用代碼審查或測試用例來輔助督促代碼質量的話,也會導致代碼細節美麗但是大方向走偏。編碼應當是短時間,高效率的作業,如果思維受到阻滯,應當及時放松,不能強求。 第五章講述了測試驅動開發(TDD)的好處,這可以認為是一個介紹性的文字。TDD新手要入門的話,推薦Kent Beck的《測試驅動開發》(http://book.douban.com/subject/1230036/) 一書。關于TDD,一些網友以及我都曾表示過,它不宜被無條件的套用。其實TDD的核心意圖,還是為了以測試用例保證代碼質量,同時以測試用例作為需求文 檔規格書(這一點我原來未能認識到,本書第七章明確提及)。只要把握住這一點,在具體的實踐中,可以對測試策略進行靈活調整。(參看拙作:測試驅動開發到 底好不好?http://blog.sina.com.cn/s/blog_593e2a770100y93d.html) 第六章講到了一些例行的代碼功力訓練。的確,作為一個技術行業,長時間脫離編碼實踐是不行的。即便有朋友進入了管理層,我也還是堅持建議大家應該做例 行的代碼訓練。書中推薦設定一個“代碼道場”做練習環境,通過“形”(單人代碼練習,推薦Bob大叔在《敏捷軟件開發》中所舉保齡球的例子)、“技”(雙 人結對編碼練習)、“自由格斗”(多人輪流代碼訓練)來進行例行練功。我認為具體形式上可以不必拘泥,但是每隔固定時間,如一周左右,應該針對一些小問 題,比如排序、搜索、小應用、小游戲等,進行代碼訓練,其實也是一個將軟件設計思路通過代碼練習凝固的過程。 第七章講了驗收測試的重要性。業務和技術人員通常會對一個需求的描述與實現進度產生理解分歧,以致交付的產品未能滿足客戶需求。這就需要雙方用驗收測 試來消除對于需求描述和進度所產生的歧義。由于GUI測試的易變性,針對GUI的測試應當盡可能的少。首先應將GUI下面的業務規則測試和GUI測試本身 分離,這一點很多同學都沒能做到。其次,針對GUI自身的繪制邏輯與客戶響應進行測試,底層業務邏輯可以用空實現代碼填充。 第八章說,專業級程序員應該及時發現產品問題,而不是一味推給QA(質保人員)。程序、QA、商務應當合作。在驗收測試中,QA測試極端路徑,商務測 試(或通過程序員測試)正常路徑,兩者互補。在作者構想的“測試金字塔”中,單元測試覆蓋率應接近100%,針對API的組件測試應占50%,同樣針對 API的集成測試應占20%,主要針對GUI的系統測試應占10%,為了探究系統運行特性所寫的探索測試應占5%。 第九章講時間管理。不能快速解決的爭議,一定是雙方論點均有立足點的議題,此時不應浪費過多時間爭論,而應拿出數據,用理性說話。其后講到用番茄法進 行時間管理的一些竅門。最后提及一個重要問題:如果發現當前工程的發展方向已經無法靈活滿足需求,則應及時重構甚至重新設計,否則將來等缺陷積累到一定時 點,必將花費更多時間去返工。此一點可謂切中要害,希望大家牢記在心,不要因為對工程缺陷一時的放縱而導致大方向走偏。 最后五章可作為第三部分,主要講述了“工程估算”,“應對壓力”,“協同工作”,“團隊與工程”,“督導、學徒制與代碼技藝”等五大涉及交流的問題。 PERT估算法是應重點掌握的知識。在估算中,針對某一任務在“一般情境”(相對于最壞情境和最好情境)下所需時間的估量,可以通過寬頻預測法及其變體(Flying Fingers, Planning Poker, Affinity Estimation等)來討論出共識。大數法則對于估量大型任務很有幫助。 應對壓力一章得出的結論是,在重重壓力下,保持工程干凈,不走樣的唯一辦法,就是堅持自己知道的且真正管用的工作守則,還應注意保持冷靜,溝通,及時尋求幫助。 協同工作一章講述了代碼評審:系統絕不應含有未被評審的代碼。代碼評審有很多種方式,它們大多極端低效。最優效率的、最有用的方式就是一起寫代碼(即 結對編程,一人寫代碼,另一人當場評審,過一定的時間二人交換)。還講了專業程序員互相交流的方式:他們能互相感知對方的恐懼;能不經意地聽到某人沮喪的 牢騷;時而不時的交流一下子,要有通過說話進行的交流,也要有通過肢體語言進行的;要做為團隊的一份子去交流。 團隊與工程一章,作者提出了自己構想的一個優化配置過的團隊模型(我稱之為“勝利十二人”):七個程序員,兩個測試,兩個系統分析員,一個項目經理。 更重要的是,明確論證了一個結論:要先建立有凝聚力的團隊,此后才能將工程根據團隊成員的特性分配給他們。針對團隊的培養才是使得工作能夠高效、可持續進 行的一條正道。 最后一章中,作者通過與醫療行業的類比,建議公司都應設立針對軟件開發者所進行的合理培訓期與督導實習制度。這個我想很多國內工作環境未必能保證。接 下來作者構想了一個用“大師——熟練工——學徒工”三階段來指示軟件開發者職業生涯的路線圖。軟件高手(大師)應當擁有至少10年工作經驗,能夠堅守自己 的技術角色而不醉心于管理職位;熟練工應具備五年工作經驗(原來我同事小利和小愛本人都可算熟練工,小小的自滿一把,嘿嘿),他們專精于一門語言,一個系 統和一個平臺,但是愿意學習更多知識。他們中的高水平者可不需大師監督自行做軟件,初級水平者尚需高手監督與代碼審查。熟練工之間應互相審查代碼;學徒工 /實習生則必須在熟練工的帶領下做事,且至少一年。作者說現實中的公司和這個設想制度的主要差別即是缺乏老手教導新手的責任觀。 文末作者總結了代碼工匠和代碼技藝的定義:代碼工匠掌握了技巧和質量。其工作快速而不忙亂。提供合理的工期估量,按時交付。知道何時該拒絕,但也會努 力去完成力所能及的任務。一個代碼工匠必是一個專業人員。代碼技藝是代碼工匠所具有的意識。是一種包含價值觀、原則、技術、態度與問題解決辦法的文化基 因。同時作者作出了呼吁:要勸說他人接受代碼技藝的思維模式,首先自己要作為一個行為榜樣,成為一個代碼工匠,將代碼技藝展示出來,這樣文化基因自然就會 發生作用。在軟件行業的我們應當面對現實,教導下一批軟件開發者直至其成熟。這個責任落在我們的身上,而不是大學的身上。 很少有書的附錄能像本書這么有內容。除了一些頗為有用的工具介紹之外,還告訴我們,一個工程的待做任務與Bug不能積累太多,否則“事務追蹤”便失去其“追蹤”的意義了。還強調了測試用例之間不能有依賴性。這是個大問題,可以參考《xUnit Test Patterns》(http://book.douban.com/subject/3419784/) 一書。作者還提及,編程要解決的問題不在代碼,而在細節,UML等模型驅動架構(MDA)無法將細節徹底從代碼中剝離,因而無法成功。實際上也不可能剝 離。將來即便有成功的MDA,也是來自程序員而非架構師,他們將會把UML轉變成一種新的能夠描述細節的編程序語言。這一點我本人不太理解和贊同,希望與 大方之家討論。 縱觀全書,很少有一本著作能夠教給我們這么多有關軟件設計行業的心得體會。這些心得還需隨著實踐去加深和調整。一個專家級程序員,必然是不停地從工作經驗中學習,在工作中堅守行業質量準則,并且愿意與工作夥伴密切交流的人。 本文為原創,如需轉載請聯系作者(Email eastarstormlee@gmail.com 微博?http://weibo.com/eastarlee)轉載于:https://blog.51cto.com/eastarlee/728498
總結
以上是生活随笔為你收集整理的学习、纪律与交流——《Clean Coder》读后感的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Power Designer的使用
- 下一篇: 党内监督专责机关其职责是检查(什么是党内