如何優雅的寫出好代碼？
我們曾認為軟件具有天然的複雜性，而且不可能徹底地消除這種複雜性，但是應該有些辦法來降低複雜性。我們花了很多時間研究複雜性的根源，隨著對複雜性理解的不斷深入，我們發現造成軟件複雜性的主要因素如下。
軟件的本質複雜性。《人月神話》的作者Frederick P.Brooks.Jr曾說：“軟件的複雜性是一個基本特徵，而不是偶然如此”。問題域有其複雜性，而軟件在實現過程中又有很大的靈活性和抽象性，導致軟件具有天然的複雜性。
缺少技藝。“寫代碼”作為一種技能，入門並不是很難。但是要像高手那樣優雅地“寫好代碼”並不是一件容易的事，需要持續的學習和實踐。
糟糕的技術氛圍。在一個技術團隊中，如果技術Leader只在乎分配給員工的任務有沒有按時實現，從來不關心代碼的質量好壞，又怎能指望團隊寫出“乾淨的代碼”？
教條和妥協。我們可能不得已在不恰當的場景使用了不恰當的解決方案，造成了不必要的複雜性。我們向自己妥協、向產品經理妥協、向工期妥協、向技術債妥協，總有很多借口把設計糟糕、混亂醜陋的代碼發佈上線。
念念不忘，必有迴響；不忘初心，方得始終。經過不懈的努力，我們的堅持和努力終於在2018年有了一些階段性的成果，我們找到了一些切實可行的控制複雜度的辦法，並沉澱了整潔面向對象分層架構（Clean Object-oriented and Layered Architecture，COLA）。COLA的誕生給了我們很大的鼓舞和希望，就像是在茫茫大海上漂流，終於看到了彼岸的燈塔。
在COLA日趨成熟之際，我迫不及待地想要將這些發現和應用整理分享出來。在探索複雜度治理的相關工作和研究中，我不止一次地感嘆如果能更早地瞭解這些知識、掌握這些方法該有多好，這樣就能避免很多不必要的焦慮，少做有缺陷的設計，少寫醜陋的代碼了。相信你在看完本書後也會有同樣的感受，因為我相信對代碼的極致追求是每個技術人員的基本動力和訴求。我們都知道“寫出好代碼”是比“寫出代碼”要難得多的要求，一個程序員的“美德”就在於他是否能為後人留下一段看得懂、可維護性好的代碼。
寫好代碼的技藝不是一蹴而就的，它是一個系統化的工程，不是看幾本書、寫幾年代碼就能輕鬆習得的，而需要我們對自己的思維習慣、學習方法和工程實踐進行徹底的反省和重構。本書記錄了一個普通碼農如何通過認知升級、知識重構、持續學習，繼而轉向工匠的過程。作為一個技術人，我有義務將這個過程分享出來，以期給同樣在路上的你帶來一些啟發，縮短你“從碼農到工匠”的探索路徑。
１、命名
名為萬物之始，萬物始於無名，道生一，一生二，二生三，三生萬物。——《易經》
命名常常被認為是編程中的細節問題，其重要性往往被低估。而所謂的工匠精神，往往就是體現在細節之處，就日本的“煮飯仙人”50年專注於做好1碗米飯。一個名字雖然並不影響程序的執行，但是卻對代碼的表達力和可讀性有著重要的影響。
在程序員的工作中，大部分的時間都在閱讀和理解代碼，好的命名能夠讓代碼的概念清晰，增加代碼的表達力；詞不達意的命名會破壞我們思考的連貫性，分散有限的注意力。
2 、規範
離婁之明，公輸子之巧，不以規矩，不能成方圓。——孟子《離婁上》
複雜系統的前沿科學家Mitchell Waldrop在《複雜》一書中，提出一種用信息熵來進行復雜性度量的方法。所謂信息熵，就是一條信息的信息量大小和它的不確定性之間的關係。舉個例子，假設消息由符號A、C、G和T組成，如果序列高度有序，例如“A A A A A A A … A”，則熵為零。完全隨機的序列，熵可能最大。
由此可見，事物的複雜程度在很大程度上取決於其有序程度，減少無序能在一定程度上降低複雜度，這正是規範的價值所在。通過規範，把無序的混沌控制在一個能夠理解的範圍內，從而幫助我們減少認知成本，降低對事物認知的複雜度。
3 函數
把簡單的事情做到極致，功到自然成，最終“止於至善”。——秋山利輝《匠人精神》
函數作為程序中最小的、最重要的邏輯單元，其在軟件開發中的重要性不言而喻。如果將數據比作一道菜，那麼函數就是菜譜，程序員就是廚師。相同的菜，有不同的做法，由不同的廚師做出來，味道會截然不同。
自從面向對象技術出來以後，很多工程師們把精力更多放在了對象技術上，反而忽視了函數。實際上，面向對象和寫好函數並不衝突，函數也是對象的重要組成部分。相比於面向對象技術體系的深奧，寫好函數要容易得多。
4、設計原則
每個人都有義務捍衛、遵守或完善原則。原則可以修正，但是不能肆意妄為。——瑞•達利歐《原則》
所謂原則，就是一套前人通過經驗總結出來的，可以有效解決問題的指導思想和方法論。遵從原則，可以事半功倍；反之，則有可能帶來麻煩。
在軟件設計領域中，有很多這樣的原則，遵從這些設計原則可以有效地指導我們設計出更靈活、易於擴展和維護的軟件系統。需要注意的是，和其他道理一樣，原則並非是形而上學的靜態客觀真理，不是說每一個設計都要教條地遵守每一個原則，而是要根據具體情況進行權衡和取捨。
5、設計模式
利用模式，我們可以讓一個解決方案重複使用，而不是重複造輪子。
（With patterns, you can use the solution a million times over, without ever doing it the same way twice.）
——克里斯托佛•亞歷山大
設計模式（Design Pattern）是一套代碼設計經驗的總結，並且該經驗必須能被反覆使用，被多數人認可和知曉。設計模式描述了在軟件設計過程中的一些不斷重複發生的問題，以及該問題的解決方案，具有一定的普遍性，可以反覆使用。其目的是提高代碼的可重用性、可讀性和可靠性。
設計模式的本質是面向對象設計原則的實際運用，是對類的封裝性、繼承性和多態性，以及類的關聯關係和組合關係的充分理解。正確使用設計模式，可以提高程序員的思維能力、編程能力和設計能力，使程序設計更加標準化、代碼編制更加工程化，從而大大提高軟件開發效率。
6、模型
建模的藝術就是去除實在中與問題無關的部分。
——利普•沃倫•安德森（1977年諾貝爾物理學獎得主）
在軟件工程中，有兩個高階工作分別是架構和建模。如果把寫代碼比喻成“施工”，那麼架構和建模就是“設計圖紙”。相比於編碼，建模的確是對設計經驗和抽象能力要求更高的一種技能。例如，在當前熱門的人工智能和機器學習領域，建模是難度很大但非常重要的工作。
7、DDD的精髓
你可以，不代表你應該。
（Just because you can, doesn’t mean you should.）——施莉琳•凱尼恩
在第6章中，我們簡要紹了什麼是模型、模型在軟件開發中的重要性，以及一些常用的建模方式在軟件工程中的應用。本章將重點講解領域驅動設計（Domain Driven Design，DDD），包括DDD的重要概念，以及如何進行領域建模。
8、抽象
若想捉大魚，就得潛入深淵。深淵裡的魚更有力，也更純淨。碩大而抽象，且非常美麗。——大衛•林奇
軟件行業有一個概念，對其瞭解越深入，我就越會感嘆之前的理解是多麼膚淺。在很長一段時間裡，對這個概念的一知半解阻礙了我對面向對象技術，甚至是軟件架構的深層次理解。
實際上，對這個概念的認知偏差，我並非個例，我接觸的工程師中能深入理解這個概念的並不多。能把這個概念和建模、面向對象和軟件架構進行融會貫通，並進行問題分析、化繁為簡的人就更是鳳毛麟角了。
９、分治
要把大象裝冰箱，攏共分幾步？——小品《鐘點工》
分治和抽象一樣，都是人類進化過程中形成的偉大智慧，也是我們解決複雜問題的不二選擇。人的思維要從一個字節大幅跨越到幾百兆字節，也就是9個數量級（現階段，後面還要再加N個零）。如此複雜的問題域，如果不進行分治，是遠遠超出人類智力範圍的。
分治的價值在於，我們不應該試著在同一時間把整個問題域都塞進自己的大腦，而應該試著以某種方式去組織問題，以便在一個時刻專注於一個特定的部分。這樣做的目的是儘量降低在任意時間所要思考問題的複雜度。
１０、技術人的素養
未經審視的人生不值得過。——蘇格拉底
在我的工作經歷中，會發現有一些技術人員成長很快，能夠迅速成為團隊的骨幹，也有一些技術人員總是在原地踏步，工作十年和工作一年的區別並不大。漸漸地，我發現這些優秀的技術人員都有一些共同的特質和素養，從而幫助他們不斷進步，脫穎而出。
１１、技術Leader的修養
Leader，就是走在隊伍的最前面，帶領者，領路人。——金一南《勝者思維》
從我開始帶團隊的第一天起，有幾個問題就一直在等我回答。
1）什麼是Leader？
2）Leader和Manager之間的區別是什麼？
3）什麼是技術Leader？
4）技術Leader和其他Leader有什麼不同？
本章內容主要是圍繞我作為技術Leader對這幾個問題的思考，以及對技術Leader的理解和定義。希望你看完本章以後，也能有一個自己的答案。
12、COLA架構
軟件的首要技術使命：管理複雜度。——史蒂夫•邁克康奈爾《代碼大全（第2版）》
工程師的首要技術使命就是控制複雜度。整潔面向對象分層架構（Clean Object-oriented and Layered Architecture，COLA）是我所在團隊自主研發的應用架構，是我們過去兩年在複雜治理之路上的一個里程碑。
COLA不僅是一個架構思想，還提供了一整套可以落地實施的框架和工具。我們可以使用COLA Archetype快速搭建一個符合COLA架構規範的業務應用，並在此基礎上快速實現業務功能。
目前，COLA已經開源。自發布以來，COLA得到了社區的普遍關注和認可，並已經在阿里巴巴內外部多個團隊落地。從實踐情況來看，COLA在應用複雜度治理上的效果顯著。在本章中，我將會詳細介紹應用架構以及COLA的主要架構思想。
13、工匠平臺
工匠平臺，技術人自己的舞臺！——“工匠平臺”的宣傳語
本章將通過工匠平臺的項目實戰介紹如何使用COLA框架開發一個業務項目，從而更好地理解COLA，並使用COLA進行企業級應用開發。
我尤其喜歡的是第11章“技術Leader的修養”。技術高手在任何公司都很重要，但是以我所觀察到的情況，很多高手都是“救火隊長”，哪裡有火就撲向哪裡，成為大家頂禮膜拜的“救火英雄”；或者有些所謂的高手只在紙上做架構，指點江山。我認為，真正的技術Leader是能夠創建並且演進架構，在架構層面上幫助大家比較容易地寫出好代碼的人；是能夠創建良好的技術氛圍，以寫好代碼為榮，以寫壞代碼為恥，促使大家不停學習的人。張建飛分享了他的團隊中一些很有意義的做法，使我深受啟發。
好代碼才是真正的銀彈！COLA架構能夠在架構層面上幫助程序員寫出好代碼、研讀源代碼，它是作者及其團隊多年來孜孜不倦地踐行工匠精神打磨出的系統產物。對於讀者，我的建議是一邊研讀源代碼，一邊反覆閱讀本書，並進一步閱讀書中推薦的其他書籍。我相信，不管你是剛入行的新人，還是工作多年、經驗豐富的人，抑或是技術管理人員，都能從本書中收穫良多。
本文摘自《代碼精進之路：從碼農到工匠》，如果你對這本書的內容感興趣，可以移步京東購買。小編摘錄的是每一章的篇首，你可以把它當做詳細的大綱來看。這本書從上架一直暢銷在京東榜單上，
這是一本為專業程序員而寫的書，寫好代碼、追求卓越和工匠精神是每個程序員都應該具備的優秀品質。
本書共有13章內容，主要分為技藝部分、思想部分和實踐部分。技藝部分詳細介紹了編程技巧和方法論，並配以詳盡的代碼案例，有助於讀者提高編寫代碼的能力，優化代碼質量。思想部分主要包括抽象能力、分治思想，以及程序員應該具備的素養等內容。實踐部分主要介紹了常見的應用架構模式，以及COLA架構的設計原理。
閱讀更多 程序員書屋 的文章
