春節期間讀了兩本技術相關的書籍：編程大師Bob大叔的《代碼整潔之道》和《代碼整潔之道：程序員的職業素養》。
《代碼整潔之道》出版於2010年，其內容主要是偏向於技術的"技"。全書都在說一些如何讓代碼更加整潔的方法和規則。
《代碼整潔之道:程序員的職業素養》出版於2016年，其內容主要偏向於技術的"術"。全書內容和代碼整潔關係不大，更多的是闡述軟件開發者的專業精神。書中給出了很多務實性的意見。
代碼整潔之道
寫代碼猶如寫文章。這就是Bob大叔在書裡所提倡的論點。
關於本書
豆瓣網友有個評論寫的還是不錯的，可以引用過來：本書中Bob大叔提倡”寫代碼猶如寫文章“，又說到“大師級程序員把系統當故事來講，而不是當做程序來寫”，對此觀點我印象深刻！在此之前我從未聽說過可以把代碼當成故事、文章來寫，Bob大叔太有才了！
如何才能寫出整潔代碼呢？
總的原則無非是KISS（Keep It Simple Stupid）：讓代碼簡單直接，讓閱讀者可以很容易地看出設計者的意圖。
本書中給出了很多方法與規範，遵循這些規則可以幫你寫出更加的整潔代碼。
這是一本不錯的書。給本書打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技術 的文章
