很多程序員都有這麼一個夢想——自己寫的代碼，可以像詩一樣優美；自己做的設計，能恰到好處，既不過度，也無不足。
這種帶有一點潔癖的完美主義就像一把達摩克利斯之劍，彷彿時刻在提醒著：不能將就、不能妥協。完美主義的代價是會在很長時間裡持續的迷茫和焦慮。
每每看到這些像麵條一樣纏繞在一起代碼，都會令人感到氣憤、懊惱和羞愧。
怎麼辦？一邊是無止盡的業務需求，一邊是補丁加補丁的業務代碼，開發人員被夾在中間像一隻困獸，向左走，還是向右走？方向在哪裡？不明白為什麼花了那麼多時間來學習技術，可還是寫不好代碼；為什麼花了這麼多時間加班，還是應對不了複雜度。
代碼精進之路
就像Robert C. Martin說的：“不管你們有多敬業，加多少班，在面對爛系統時，你任然會寸步難行，因為你大部分的精力不是在開發需求，而是在應對混亂。”
其實，造成軟件複雜性的罪魁禍首主要來自以下因素：
● 軟件的本質複雜性——《人月神話》的作者Fred Brooks曾說：“軟件的複雜性是一個基本特徵，而不是偶然如此”。因為問題域有其複雜性，而軟件在實現過程中又有很大的靈活性和抽象性，導致軟件具有天然的複雜屬性。
● 缺少技藝——“寫代碼”作為一種技能，入門並不是很難，北大青鳥三個月就可以做到。但是要想像大師那樣優雅的“寫好代碼”，則並不是一件容易的事。需要持續的學習和實踐，很多的軟件複雜性都是因為技藝缺乏而導致的隨心所欲的複雜性。
● 糟糕的技術氛圍——在一個技術團隊中，如果技術管理者們只在乎分配給你的任務有沒有實現，從來不關心代碼的好壞，又怎能指望團隊寫出“乾淨的代碼”。
● 教條——總認為有什麼靈丹妙藥，在不恰當的場景使用了不恰當的解決方案，造成了不必要的複雜。
● 妥協——開始向自己妥協，向產品經理妥協，向工期妥協，向技術債妥協，總能很多借口把設計糟糕、混亂醜陋的代碼發佈上線。
這些其實都是很多心有不甘的技術人員都有的問題，是很多技術人共同的痛。與其做一個困獸，不如主動出擊，通過大量的學習、研究和實踐去解決一系列麻煩。
中間變量
我們可以通過添加中間變量讓代碼變得更加自明，即將計算過程打散成多個步驟，並用有意義的變量名來命名中間變量，從而把隱藏的計算過程以顯性化的方式表達出來。
例如，我們要通過Regex來獲得字符串中的值，並放到map中。
用中間變量，可以寫成如下形式：
中間變量的這種簡單用法，顯性地表達了第一個匹配組是key，第二個匹配組是value。只要把計算過程打散成一系列良好命名的中間值，不透明的語義自然會變得透明。
領域驅動
領域驅動設計關心的是業務中的領域劃分（戰略設計）和領域建模（戰術設計），其開發過程不再以數據模型為起點，而是以領域模型為出發點，研發過程如下圖所示。領域模型對應的是業務實體，在程序中主要表現為類、聚合根和值對象，它更加關注業務語義的顯性化表達，而不是數據的存儲和數據之間的關係。這是“領域驅動設計”和“數據驅動設計”之間顯著的區別。
仍以上面的CRM為例。假如我們先不考慮數據模型，而是採用面向對象分析（Object Oriented Analysis，OOA）對這個場景進行領域建模，那麼可以得到下圖所示的領域模型。
可以看到，，領域模型的描述更加貼近業務，一些重要的業務術語和概念沒有丟失，更完整地表達了業務語義。即使是產品經理或者業務人員，也不難看懂這樣的領域模型，甚至他們可以和技術人員一起參與到梳理領域模型和創建活動中來。
通過DDD的戰略設計和戰術設計，我們可以為問題域劃分出合適的子域，並對域中的業務進行建模。下圖是我們在實際工作中為CRM進行的領域戰略設計。
資深大牛，良心創作
這是一本為專業程序員而寫的書，寫好代碼、追求卓越和工匠精神是每個程序員都應該具備的優秀品質。
《代碼精進之路：從碼農到工匠》作者：張建飛
作者是阿里巴巴高級技術專家，力求在提高讀者編寫代碼能力的同時，也追求卓越和工匠精神：
- 深度揭秘了阿里巴巴團隊在複雜度治理方面的探索與實踐；
- 著重培養技術人員的思想與素養，分享多年技術管理心得；
- 全面講解編程技藝與方法，並配以詳盡的代碼案例；
- 重點介紹開源框架COLA架構及其企業級應用“工匠平臺”。
閱讀更多 人民郵電出版社 的文章
