這是why技術的第32篇原創文章java
春節期間讀了兩本技術相關的書籍:編程大師Bob大叔的《代碼整潔之道》和《代碼整潔之道:程序員的職業素養》。程序員
《代碼整潔之道》出版於2010年,其內容主要是偏向於技術的"技"。全書都在說一些如何讓代碼更加整潔的方法和規則。編程
《代碼整潔之道:程序員的職業素養》出版於2016年,其內容主要偏向於技術的"術"。全書內容和代碼整潔關係不大,更多的是闡述軟件開發者的專業精神。書中給出了不少務實性的意見。數據結構
寫代碼猶如寫文章。這就是Bob大叔在書裏所提倡的論點。函數
關於本書豆瓣網友有個評論寫的仍是不錯的,能夠引用過來:工具
本書中Bob大叔提倡」寫代碼猶如寫文章「,又說到「大師級程序員把系統當故事來說,而不是當作程序來寫」,對此觀點我印象深入!在此以前我從未據說過能夠把代碼當成故事、文章來寫,Bob大叔太有才了!單元測試
如何才能寫出整潔代碼呢?學習
總的原則無非是KISS(Keep It Simple Stupid):讓代碼簡單直接,讓閱讀者能夠很容易地看出設計者的意圖。測試
本書中給出了不少方法與規範,遵循這些規則能夠幫你寫出更加的整潔代碼。spa
這是一本不錯的書。給本書打4星,是由於本書在講述代碼重構方面不如《重構--改善既有代碼的設計》、講述代碼編寫方面不如《代碼大全》、講述代碼設計方面不如《敏捷軟件開發》(Bob大叔本身的上一本經典著做)。另外中文版價格偏高,翻譯質量也很通常。
讀書筆記:
第一章 整潔代碼
1,整潔代碼力求集中,每一個函數、每一個類和每一個模塊都全神貫注於一件事。
2,整潔代碼簡單直接,從不隱藏設計者的意圖。
3,整潔代碼應當有單元測試和驗收測試。它使用有意義的命名,代碼經過其字面表達含義。
4,消除重複代碼,提升代碼表達力。
5,時時保持代碼整潔。
第二章 有意義的命名
1,使用體現本意的命名能讓人更容易理解和修改代碼。
2,編程原本就是一種社會活動。
3,盡力寫出易於理解的代碼
第三章 函數
1,一個函數應該只作一件事(高內聚),無反作用。
2,自頂向下閱讀代碼,如同是在閱讀報刊文章。
3,長而具備描述性的函數名稱,好過描述性的長註釋。
4,使用異常代替返回錯誤碼,錯誤處理代碼就能從主路徑代碼中分離出來獲得簡化。
5,寫代碼很像是寫文章。先想怎麼寫就怎麼寫,而後再打磨:分解函數、修更名稱、消除重複。
6,編程實際上是一門語言設計藝術,大師級程序員把程序系統當作故事來說。使用準確、清晰、富有表達力的代碼來幫助你講故事。
第四章 註釋
1,別給糟糕的代碼加註釋----重寫吧。
2,把力氣花在寫清楚明白的代碼上,直接保證無需編寫註釋。
第五章 格式
1,代碼格式很重要。代碼格式關乎溝通,而溝通是專業開發者的頭等大事。
2,向報紙格式學習代碼編寫。
第六章 對象和數據結構
1,對象把數據隱藏於抽象以後,只提供操做數據的函數。數據結構暴露其數據,沒有提供有意義的函數。
2,The Law of Demeter:模塊不該去了解它所操做的對象內部細節。
第七章 錯誤處理
1, 使用異常而非返回錯誤碼。
2, try-catch-finally, log出錯信息。
3, 不要返回null,不要傳遞null。NULL Object模式, 例:Collections.emptyList();
第十章 類
1,自頂向下原則:讓程序讀起來就像是一篇報紙文章。
2,method能夠是protected,以便於單元測試。
3,SRP:類或模塊應有且僅有一個加以修改的緣由。類名應準確描述其職責。高內聚。
4,開放閉合原則、依賴倒置原則。
5,變量名、方法名、類名都是給代碼添加註釋的一種手段。
第十二章 迭代前進
1,緊耦合的代碼難以編寫單元測試。
2,單元測試消除了對清理代碼會破壞代碼的恐懼。
3,寫出本身能理解的代碼很容易,軟件項目的主要成本在於長期維護。
4,代碼應當清晰表達其做者的意圖;測試代碼能夠經過實例起到文檔做用。
第十四章 逐步改進
1,編程是一種技藝。要編寫整潔代碼,必須先容忍髒代碼,而後清理!
2,寫出好文章就是一個逐步改進的過程。
在《代碼整潔之道:程序員的職業素養》一書中,Bob大叔主要試圖回答下面的問題:
1.什麼是軟件專業人員?
2.軟件專業人士如何行事?
3.軟件專業人士如何處理衝突,應對很緊的工期,如何和不講道理的管理人員打交道?
4.軟件專業人士什麼時候應該說「不」?怎麼說?
5.軟件專業人士如何應對壓力。
在讀這本書的時候,你能感覺到針對上面的問題,書中除了提出一些務實性的意見,你還能感覺到一種說不清道不明的積極態度。
這種態度提倡要誠信,要富有榮譽感、自尊心和自豪感,要敢於承擔做爲一名手藝人和工程師所肩負的重大責任。
這種責任包括要努力工做,出色完成任務;要擅於溝通,能就事論事;要管理好時間,可以坦然面對艱難的「風險回報」決策。
除了責任感外,還有一種神聖的使命感。身爲一名工程師,你比任何管理者可能都瞭解得更透徹。瞭解這些你也意味着你肩負着要勇於行動的重大責任。
針對上面的問題,我這篇文章中確定是說不全的。畢竟人家是一本書,若是我濃縮到了一篇文章中,那就有點泛泛而談了。
我主要想分享一下我讀完這本書體會比較大的其中的一個點,而且通過這幾年的開發,我也深覺得然的一個點。
在書的1.4 職業道德 小節中做者提起了下面這幾點:
其中諸如堅持學習、聯繫、合做之類的老生常談的話題我就很少說了。我主要想談談我標記了的瞭解你的領域和了解業務領域這兩個點。
瞭解你的領域了,個人領域就是程序員領域。不,這樣的格局過小。個人領域就是互聯網領域。
近50年來,各類觀點、實踐、技術、工具與術語在咱們這一領域層出不窮,若是想要成爲一名專業的開發者,就須要對其中的大部分有所瞭解,並且要不斷地擴展這一知識面。
做爲一個專業的程序員,對於本身所在領域的技術必須瞭解而且時刻進行迭代更新。
瞭解你的領域就是了解本身"吃飯"的範圍。
你們都知道,在這個行業中知識是層出不窮的。咱們學習的速度永遠趕不上知識更新的速度。正是由於這樣的,因此咱們在鞏固知識的同時也須要堅持學習。讓本身儘可能晚的被淘汰出局。
爲何說咱們這個行業是一個吃青春飯的行業呢?
我以爲是由於隨着年齡的增加和所承擔的社會角色愈來愈複雜,學習能力和精力會隨之降低。到某個時候,不用別人說,你就本身感覺到了,學習的勁頭愈來愈趕不上這波年輕人了。
這個時候,你就須要看本身有沒有核心競爭力了。
每一個人的核心競爭力大多不一樣,可是向上抽離的話你會發現,大多數都和業務領域相關。這個時候就體現出瞭解業務領域的重要性了。
每位專業軟件開發人員都有義務瞭解本身開發的解決方案所對應的業務領域。
每一個人的業務領域也不相同,就拿我本身來講,我作過支付、作過帳戶、作過貸款,自認爲我是屬於互聯網金融行業的。
相信也有不少朋友和我所處的行業是同樣的。
那你身處這個領域那你知道什麼銀聯嗎?
網聯爲何誕生嗎?
什麼是大小額通道?
什麼是聚合支付?
什麼是二清?
爲何要打擊二清?
知道支付牌照對於支付公司來講有多麼重要嗎?
知道央行的217號文件中的那句:全面檢查對於持證機構(銀行、銀聯、第三方支付機構、各地方清算中心)違規爲無證經營支付業務機構提供支付清算服務的行爲。這句話對於整個支付行業的震盪有多大嗎?
......
這些問題都是寫到這裏的時候一瞬間涌入到我腦海中的問題。這樣的和技術無關,可是和所屬領域有關的問題還有不少不少。
我想要表達的東西和書裏面表達的是同樣的。
若是編寫財務系統,你就應該對財務領域有所瞭解;若是編寫旅遊應用程序,那麼你須要去了解旅遊業。
你未必須要成爲該領域的專家,但你仍須要用功,付出至關的努力來認識業務領域。
而最糟糕、最不專業的作法就是,簡單的按照規則說明來編寫代碼,但卻對爲何那些業務須要那些的規格定義不求甚解。
而這也是剛剛入行的新人所經常面對的問題,只關心技術,不關心業務。
年前極術社區搞了一個活動:分享你所在的行業或者所學專業過去十年你以爲變化最大的技術是什麼,將來十年你以爲哪一個技術發展最值得期待。
這個活動其實就是對我上面說到的瞭解你的領域和了解業務領域這兩個點的結合。我認爲任何一個有幾年開發經驗的程序員都應該能寫上幾句,表達本身的觀點。觀點也許很淺顯,也許不必定正確,可是那也是有本身的思考在裏面。
我當時的回覆是這樣的:
其實在我看來我說的都不算是觀點,就是我在這個行業裏面待了幾年的時間,親眼看到,親耳聽到的事情。
一些了不起的、波瀾壯闊的事情,正在經過互聯網金融的這個業務領域,改變着人類生活的方方面面。
另外,書裏還說到一個點,我也以爲應該分享一下:做爲你的領導或者協做者在工做的過程當中,最不喜歡聽到的應該是諸如「我試試,我儘可能...」這樣的話。比較負責任的,好一點的回答是:我將在....以前....(例如:我將在下週二以前完成這個任務)。
最後,再分享一個我的工做的小技巧吧。和我作過同事的朋友應該能發現,我隨時耳朵上都掛着藍牙耳機。其實耳機裏面並無聽任何音樂。可是當我作一些比較複雜的編程工做的時候,我帶上沒有聲音、可是有降噪功能的耳機後的效率就是會高一些。可以讓我更加專一於眼前的事情。
可是這樣有個弊端就是有可能會給同事帶來一種你很差接近,比較高冷的感受。因此平時仍是須要多和同事交流交流哦。
好了。感謝您的閱讀,我堅持原創,十分歡迎並感謝您的關注。
以上。
歡迎關注公衆號【why技術】。在這裏我會分享一些技術相關的東西,主攻java方向,用匠心敲代碼,對每一行代碼負責。偶爾也會荒腔走板的聊一聊生活,寫一寫書評,影評。願你我共同進步。