1. 工具箱廣度深度，或者說在技術(shù)選型上控制系統(tǒng)復(fù)雜度的能力，廣度：懂多少數(shù)據(jù)庫/數(shù)據(jù)處理框架/AWS幾個(gè)重要的Service了解多少/著名的開源軟件框架工具了解程度, （這個(gè)一年前的答案列了一些我們當(dāng)時(shí)經(jīng)常用的，業(yè)界也很流行的，您可以參考下。阿萊克西斯：后端所謂復(fù)雜的問題是什么？ ） 廣度決定了眼界； 深度：為什么數(shù)據(jù)庫要這么實(shí)現(xiàn)設(shè)計(jì)，為什么AWS這個(gè)地方有這個(gè)缺陷（比如SQS為什么是可亂序的queue），看似類似的幾個(gè)框架，在本質(zhì)上有什么不同，是在哪個(gè)本質(zhì)問題上做了哪些決定行的trade-off導(dǎo)致了它們?cè)谠O(shè)計(jì)實(shí)現(xiàn)和提供的功能上分道揚(yáng)鑣？ 深度決定了能否真的在合適的場(chǎng)景應(yīng)用合適的能力與工具。

2. 程序語言理解深度和表達(dá)抽象能力，這是在實(shí)現(xiàn)上控制復(fù)雜度的能力，懂不懂得最小表達(dá)力原則？懂得幾種編程范式？它們之間怎么根據(jù)具體情況作出取舍？是否知道怎樣才能把code寫成詩？怎么樣才能在重重困難中，堅(jiān)守高聚合，低耦合？怎樣組織程序，才能使得讓程序正向流動(dòng)產(chǎn)生期待效果之外，程序能否根據(jù)效果／結(jié)果，倒推并很容易的倒推出這樣的一種結(jié)果是由什么原因，那個(gè)組件造成的(這是系統(tǒng)怎么才能很容易進(jìn)化的關(guān)鍵，也是“做出來就是好的”程序員最難克服的一點(diǎn))？code寫出來邏輯線是否清晰可見？

3. 方法論，編程大道(programming in the big)，和構(gòu)架能力，這是在時(shí)間跨度的整體上控制復(fù)雜度的能力，辨別什么是對(duì)的，應(yīng)該做什么的能力；在時(shí)間跨度上，在信息不完整的情況下，現(xiàn)在怎么構(gòu)架，才能使得當(dāng)將來信息完整了，我們能很輕松的根據(jù)將來的正確信息，把系統(tǒng)調(diào)整成最好最正確的狀態(tài)，什么決定應(yīng)該現(xiàn)在做，什么決定可以和怎么樣才能留給將來做，并且在這個(gè)過程中，保證能夠支持業(yè)務(wù)正常運(yùn)轉(zhuǎn)。在整體上，怎么把需求獲取/設(shè)計(jì)/coding/測(cè)試/安全/部署/運(yùn)行監(jiān)測(cè)/報(bào)警/性能/系統(tǒng)回饋分析/數(shù)據(jù)統(tǒng)計(jì)/報(bào)表…等等在全局把握，安排的妥妥當(dāng)當(dāng)相互支持而不是相互抵觸，相互使絆子。這里包含的知識(shí)包括，到底是waterfall， TDD，BDD，還是type driven，怎么執(zhí)行Agile，什么是devOps，continuous delivery。 到底應(yīng)該是技術(shù)決定業(yè)務(wù)，還是業(yè)務(wù)決定技術(shù)？。給一個(gè)100人的團(tuán)隊(duì)和超復(fù)雜／抽象的需求（比如需求就是讓公司業(yè)務(wù)翻一倍，怎么翻一倍這個(gè)抽象問題要怎么分解成n個(gè)大問題，這n個(gè)大問題怎么分解成m個(gè)中問題），怎么把抽象問題落到實(shí)處，怎么能把大的問題分解成哪怕是比較弱的程序員也可以解決的小問題，然后還要證明這是根據(jù)現(xiàn)在的信息，可以做出的最好的決定

一個(gè)DDD 實(shí)踐者經(jīng)常使用的重要的practise，就是跟PM和客戶討價(jià)還價(jià), 學(xué)會(huì)拒絕和剪裁，合理的push back，也是我面試Sr. SDE時(shí)候會(huì)考察的軟技能之一

因?yàn)閺?fù)雜的技術(shù)實(shí)現(xiàn)是有代價(jià)的，要看換來的業(yè)務(wù)價(jià)值是什么，如果核心邏輯要求一個(gè)技術(shù)實(shí)現(xiàn)，關(guān)系到項(xiàng)目的成敗，那就要不惜代價(jià)的去選擇完備的實(shí)現(xiàn)方案。而當(dāng)一個(gè)超復(fù)雜的技術(shù)實(shí)現(xiàn)只是為了一個(gè)可有可無的業(yè)務(wù)功能，那就要強(qiáng)勢(shì)說服客戶PM砍掉這個(gè)功能。因?yàn)橹С诌@個(gè)功能造成系統(tǒng)的復(fù)雜度，可能會(huì)給拓展核心業(yè)務(wù)造成困難。

這里推薦一下Worse is better這篇文章，論述了為什么簡(jiǎn)單大于一切。

簡(jiǎn)單要大于正確性，因?yàn)楝F(xiàn)在的正確未必是未來的正確，砍掉意義不大的正確性，保持核心的簡(jiǎn)單性，是讓核心能夠輕裝上陣，更好演化的關(guān)鍵。

簡(jiǎn)單大于一致性，這個(gè)很多例子了，大家從事務(wù)的強(qiáng)一致行轉(zhuǎn)為prefer 最重一致性就是在這點(diǎn)上trade off的最好例子

簡(jiǎn)單大于功能完備性，這個(gè)上邊我也解釋過了。不需要非核心的功能完備性而犧牲核心或者系統(tǒng)的整體簡(jiǎn)單性。

那么怎么在簡(jiǎn)單，業(yè)務(wù)正確性，一致性，完備性里，做合理的trade-off（因?yàn)橥耆灰_性，一致性和完備性也不行呀）就需要對(duì)業(yè)務(wù)有深入的了解認(rèn)識(shí)。程序員的本質(zhì)還是解決問題的人，只是恰巧用計(jì)算機(jī)來解決問題而已，好的程序員是簡(jiǎn)化問題和解決問題的高手，他能夠在業(yè)務(wù)/技術(shù)/人員/文化/復(fù)雜度/等等多角度做剪裁，來衡量各種得失，而不是把自己逼死累死在復(fù)雜的技術(shù)實(shí)現(xiàn)上，用靈活的手段來讓自己的組和公司獲得成功。

跳出技術(shù)思維的束縛，從全局來思考問題，我想，這就是DDD的精神吧。

開始面向測(cè)試用例編碼之后。一個(gè)測(cè)試友好的代碼，其輸入、輸出都是清晰的，而且功能應(yīng)該是單一的，這樣才能方便測(cè)試。

我是N年前進(jìn)網(wǎng)易之后，跟著組里一個(gè)從Google來的leader，他要求所有寫的代碼都有對(duì)應(yīng)的gtest測(cè)試用例來覆蓋，有了這個(gè)概念和練習(xí)之后，開始要求自己在實(shí)現(xiàn)代碼方面要功能盡量的功能單一、有明確的輸入輸出，這時(shí)候開始個(gè)人覺得有了比較大的進(jìn)步。

當(dāng)然，很多時(shí)候?yàn)榱藴y(cè)試而測(cè)試是不應(yīng)該，但是有了測(cè)試用例，任何的改動(dòng)只有沒有跑過用例的全都可以自動(dòng)化檢測(cè)出來。

因?yàn)榻佑|新的概念而茅塞頓開的體驗(yàn)，有時(shí)是因?yàn)樾碌闹R(shí)與原有知識(shí)體系打通了。

比如在使用了多年C/C++后，一些不正確的固有觀念會(huì)阻礙對(duì)技術(shù)認(rèn)識(shí)的深入，但是自己卻察覺不到。這時(shí)如果你深入學(xué)習(xí)和使用Python等新的語言和技術(shù)，就會(huì)對(duì)已經(jīng)掌握的技術(shù)有顛覆性的認(rèn)識(shí)。肯定不僅僅是學(xué)到了一種新技能而已，而是新的知識(shí)會(huì)和老的知識(shí)發(fā)生化學(xué)反應(yīng)。之前認(rèn)為“必須如此”的做法，在吸收新的知識(shí)后，你可能會(huì)不那么確定了。

忘了哪位大牛說過，經(jīng)常用Vim和命令行的人應(yīng)該去試試IDE，經(jīng)常用IDE的人應(yīng)該試試Vim/Emacs加命令行，深表贊同。真知灼見往往藏在你完全不知道的地方。學(xué)習(xí)技術(shù)，故步自封是大忌。

突飛猛進(jìn)的提升常常來自于靈感，而靈感是辛勤思考的果實(shí)。

這個(gè)道理就不展開了，被蘋果砸、夢(mèng)見蛇能產(chǎn)生什么靈感，取決于你之前有過多少辛勤的思考和試驗(yàn)。靈感并不是什么玄的東西，依然是積累的結(jié)果。

同樣一種新的概念、技術(shù)，對(duì)不同的人意義完全不同。

比如，Milo Yip回答說TDD非常有用。我贊同，但是我自己和周圍的人并沒有用的太多。

測(cè)試驅(qū)動(dòng)開發(fā)確實(shí)對(duì)很多團(tuán)隊(duì)、很多開發(fā)者有過巨大影響，但是我之前的團(tuán)隊(duì)嘗試過，TDD在游戲邏輯開發(fā)中存在很難跨越的障礙，導(dǎo)致并沒有實(shí)際使用下去。所以說“突飛猛進(jìn)”的感觸因時(shí)而異、因人而異。

總之，在學(xué)習(xí)的過程中，你會(huì)不斷地改善方法、否定之前的方法，或者否定之前否定的方法，然后從中收獲到大量的樂趣。

在這個(gè)過程中，每一個(gè)時(shí)刻的你，都不能用“蠢”來形容。如果稱以前某個(gè)時(shí)候的自己很蠢，那么之后可能某個(gè)時(shí)刻你可能會(huì)更“蠢”，這涉及到了學(xué)習(xí)的本質(zhì)。

知識(shí)靠逐步積累，并沒有那么神奇的一大步。

不過倒是想起來職業(yè)生涯中對(duì)于一個(gè)不起眼的小工具的有趣經(jīng)歷。工作兩年后在 team 里也算是效率比較高的人，基本上算是 lead 了。有一次和一個(gè) new comer 確認(rèn)工作流程的時(shí)候他總是強(qiáng)調(diào)自己用 diff 的結(jié)果。我在這之前從來沒用過 diff。經(jīng)他說了幾天，diff 成為我日常使用最多的工具。（后續(xù)：這個(gè) new comer 不久就離職了。從我們共同的同事和下家公司的同事的反饋來看，他的 performance 并不好。但是從這件事情上，我一直把他認(rèn)為我的領(lǐng)路人。）

后來我到 Adobe，這里有一個(gè)做出版軟件十多年的人。我到現(xiàn)在心里也會(huì)叫一聲老前輩。他頭一年見到我就會(huì)說「我怎么看你老泡在 diff 上呢？」之后自然他也開始用 diff 了。

可能對(duì)于大多數(shù)人來說，我們兩個(gè)人在 diff 工具上的知識(shí)盲點(diǎn)是可笑的。即使很強(qiáng)的人，也會(huì)在意料不到的地方有盲點(diǎn)。

前端，針對(duì)前端開發(fā)吧，但其實(shí)有些經(jīng)驗(yàn)是有普適性的。

一、DSL (領(lǐng)域特定語言) 吧

對(duì)于DSL其實(shí)完全談不上掌握，但不斷的淺層次實(shí)踐，確實(shí)足足保證了我至少3年左右的穩(wěn)定技術(shù)類產(chǎn)出，在業(yè)務(wù)中也受益不少。

前兩年主要的關(guān)注點(diǎn)其實(shí)主要還是集中在偏向于L（Language）的部分，自己也確實(shí)掌握了不少內(nèi)部或外部DSL的設(shè)計(jì)技巧，也能結(jié)合自己熟悉的宿主語言做出一些黑科技的方案。但本質(zhì)上這部分內(nèi)容其實(shí)是已經(jīng)被解決的問題，所以越來越感覺是一種“工具”，針對(duì)不同的問題域，L部分的設(shè)計(jì)準(zhǔn)則往往具有一定相似性。

近兩年越來越發(fā)現(xiàn)DS(Domain Special)才是真正的關(guān)鍵，在很多想法無法落地，陷入死胡同的時(shí)候，重新理清思緒找到系統(tǒng)的限界上下文，往往整個(gè)問題就豁然開朗了。這個(gè)其實(shí)更偏向于方法論范疇，在各個(gè)業(yè)務(wù)領(lǐng)域，各個(gè)工種其實(shí)都有不同的實(shí)踐意義。業(yè)界常說的DDD不只是一個(gè)口號(hào)而已，后端的微服務(wù)領(lǐng)域邊界，前端的組件功能邊界，其實(shí)都可以從這種思維中受益。

要說推薦書的話

• 《編程語言實(shí)現(xiàn)模式》

• 《實(shí)現(xiàn)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》

• 《flex 與 bison》

二、明確理解了html在傳統(tǒng)前端開發(fā)中的重要性

很多年輕的前端會(huì)比較沾沾自喜使用一些css3實(shí)現(xiàn)一些酷炫的效果，使用一些復(fù)雜的JS框架完成業(yè)務(wù)開發(fā)(其實(shí)大部分都是拿錘子找釘子)，往往忽視了html的重要性。

就和復(fù)雜模塊的開發(fā)，我們可以明確的感受到，『數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)的是否優(yōu)良』幾乎可以奠定后面的邏輯開發(fā)是否順利，一個(gè)傻逼的數(shù)據(jù)模型定義，往往需要山路十八彎的去解決看似不復(fù)雜的需求。

在界面開發(fā)中，也是一樣，『一個(gè)設(shè)計(jì)精良的html結(jié)構(gòu)』完全可以決定后期我們維護(hù)js和css的容易度，面試中對(duì)于新人也逐步注重這方面的考察。這些問題其實(shí)比你問css3有哪些屬性這類問題要有意義的多

沒有什么捷徑可以走，任何一個(gè)概念和技術(shù)都是在大量實(shí)踐的基礎(chǔ)上、從內(nèi)心深處理解了才會(huì)有所領(lǐng)悟。而且，他人的觀點(diǎn)未必就是正確的，即使正確，也未必是你理解的那個(gè)意思。

比如說很多人動(dòng)不動(dòng)把設(shè)計(jì)模式六大原則、還有多少種設(shè)計(jì)模式掛在嘴上，我是從來都不對(duì)這些東西感冒的，我一直都覺得六大原則完全就是一種唯像的規(guī)律，如果你照著去做，你可能會(huì)發(fā)現(xiàn)反而遇到種種困難，甚至不同原則之間看上去像是互相矛盾的一樣。而我對(duì)設(shè)計(jì)原則的理解，直到最近才總結(jié)成一條原則，我稱之為最大最小原則。

我們說任意一個(gè)接口，或者說任意一段程序，它都包含了輸入和輸出：自己調(diào)用參數(shù)是輸入，返回值和傳遞給下層模塊的調(diào)用參數(shù)是輸出。一段程序要能正常工作，它肯定不是隨便什么輸入都能接受的，而是要求輸入的參數(shù)滿足一定的約束，比如說某個(gè)參數(shù)必須是整數(shù)類型，必須大于0，另一個(gè)參數(shù)必須是回調(diào)函數(shù)，回調(diào)函數(shù)調(diào)用的結(jié)果一定要符合某個(gè)特性，等等。輸出也肯定不能是亂七八糟什么都輸出，而是必須要符合適配方的需要，這些輸出結(jié)果所具有的特性稱作保證，比如說保證輸出為20個(gè)字符以內(nèi)的字符串，等等。

當(dāng)我們把程序級(jí)聯(lián)起來的時(shí)候，一段程序的輸出會(huì)成為下一段程序的輸入，比如說調(diào)用A模塊，A模塊內(nèi)部調(diào)用B模塊，則A模塊產(chǎn)生的數(shù)據(jù)會(huì)成為B模塊的調(diào)用參數(shù)。在這種條件下，前一級(jí)程序的輸出和下一級(jí)程序的輸入就產(chǎn)生了這樣的關(guān)系：前一級(jí)程序的輸出保證，必須完全覆蓋下一級(jí)程序的輸入約束。

那么我們要讓這個(gè)設(shè)計(jì)穩(wěn)定，盡量不隨著需求的變化而產(chǎn)生大的變動(dòng)，要做的事情就很簡(jiǎn)單了：

在投入資源一定的條件下，設(shè)計(jì)能滿足需求的模塊劃分和接口，使得每個(gè)接口的輸出保證最大化，而輸入約束最小化。

注意到輸出保證最大化、輸入約束最小化、還有投入資源一定，這三個(gè)要求往往是互相矛盾的，接受更多的可能的輸入意味著可能會(huì)增加實(shí)現(xiàn)的復(fù)雜度，降低輸出的一致性，所以這三個(gè)要求是有優(yōu)先級(jí)的：投入資源最優(yōu)先保證，第二是輸出保證最大化，第三是輸入約束最小化。具體來說大致是循環(huán)以下的步驟：

1. 當(dāng)前設(shè)計(jì)中，是否有修改前一級(jí)的輸出保證和后一級(jí)的輸入約束，使得總的實(shí)現(xiàn)能大幅度簡(jiǎn)化的情況？如果有，修改這個(gè)約束和保證，將它在前一級(jí)和后一級(jí)之間進(jìn)行轉(zhuǎn)移。如果這個(gè)接口在修改后輸出等于輸入，移除這個(gè)接口（例如，如果有段程序只是為了把前端傳過來的JSON里的字段名修改一下、調(diào)整一下格式，為什么不直接讓前端使用修改過之后的格式呢？）

2. 當(dāng)前設(shè)計(jì)中，是否有功能重復(fù)的部分，可以合并成同一個(gè)接口，從而顯著降低實(shí)現(xiàn)復(fù)雜度？如果有，將它們合并

3. 是否有接口輸出的一致性不好，比如有多種可能的情況，或者不同的輸入?yún)?shù)對(duì)應(yīng)了不同類型的輸出結(jié)果，而將不同的情況分解成不同的接口，并不顯著增加實(shí)現(xiàn)復(fù)雜度？如果有，將它拆分成多個(gè)相同輸入的不同的接口

4. 是否有接口有多余的輸入約束，例如有多余的輸入?yún)?shù)，或者有和同類型接口中不一致的輸入，或者不必要地假定了輸入?yún)?shù)符合某種關(guān)系（例如兩個(gè)參數(shù)不能同時(shí)為True），移除這個(gè)約束并不會(huì)顯著增加實(shí)現(xiàn)復(fù)雜度？如果有，移除這些多余的輸入約束，讓它接受更廣泛范圍的輸入。

某些情況下，程序自己也是一種輸入輸出，比如參數(shù)可以接受回調(diào)函數(shù)，以及面向?qū)ο蟮?，這種情況下程序自己是輸出，而程序滿足的接口是輸入，這個(gè)輸出的輸出保證和輸入約束是函數(shù)的輸入約束和輸出保證兩部分，在這個(gè)函數(shù)本身滿足輸出保證最大化、輸入約束最小化的情況下，使用這個(gè)函數(shù)作為輸出，也就滿足了輸出保證最大化、輸入約束最小化。

當(dāng)以上步驟正確完成的時(shí)候，我們一定會(huì)得到以下的結(jié)果：

1. 所有功能都只被實(shí)現(xiàn)了一次，所有的實(shí)現(xiàn)都是必要的

2. 每個(gè)接口都只能產(chǎn)生同一類型的、有最強(qiáng)保證的結(jié)果，因而它一定只有一個(gè)職責(zé)（對(duì)應(yīng)單一職責(zé)原則）

3. 每個(gè)接口都只對(duì)輸入?yún)?shù)做最小的約束，每個(gè)子類的實(shí)現(xiàn)都會(huì)自己的輸出做了最大的保證，因此子類一定可以替代父類（所謂里氏替換原則）

4. 因?yàn)榻涌诘淖钚〖s束，所以接口一定只使用了參數(shù)中最必要的信息，也就相當(dāng)于依賴接口，也不用關(guān)心什么難懂的依賴倒置原則了

5. 當(dāng)然，接口隔離原則也是最小約束的副產(chǎn)物

6. 當(dāng)然，迪米特法則（最小依賴）就更是了

7. 當(dāng)一個(gè)接口提供了最大的保證，而接受最小的約束，這意味著這個(gè)實(shí)現(xiàn)已經(jīng)無法再容納其他可能的輸入了，那么在輸入輸出關(guān)系不變的情況下，它的實(shí)現(xiàn)就已經(jīng)完全確定了，也就是對(duì)修改關(guān)閉了；其他業(yè)務(wù)邏輯則可以利用后一級(jí)輸入約束少于前一級(jí)輸出的特點(diǎn)，和前一級(jí)并列插入到后一級(jí)之前，從而實(shí)現(xiàn)擴(kuò)展，那么開閉原則也是不言自明了

也就是說我們只要遵從前面的一條原則，后面的這些所謂原則都是自然滿足的了，而且它不會(huì)讓你弄錯(cuò)原則的適用范圍，比如說修改了業(yè)務(wù)邏輯（意味著輸入相同的情況下，輸出做了修改）了情況下還強(qiáng)行適用開閉原則，或者想不清楚現(xiàn)在的設(shè)計(jì)究竟是不是單一原則。

設(shè)計(jì)中一個(gè)最常見的錯(cuò)誤就是把后一級(jí)的接口的輸入約束設(shè)計(jì)成和前一級(jí)接口的輸出保證一模一樣，從而將約束一路傳遞到后面所有的模塊中，導(dǎo)致以后業(yè)務(wù)調(diào)整時(shí)完全沒有辦法擴(kuò)展，動(dòng)不動(dòng)就“重構(gòu)”，這些都是設(shè)計(jì)出問題的表現(xiàn)。如果你的設(shè)計(jì)服從最大最小原則，那么所謂的需求變更無非就是以下這些情況：

1. 完全調(diào)整了某一類輸入時(shí)產(chǎn)生的輸出：直接修改處理這類輸入的程序

2. 讓某一類輸入的某些特例產(chǎn)生不同的輸出：為這個(gè)新類型的輸入獨(dú)立編寫一個(gè)并行的路徑，直到輸出落回到原來接口的約束范圍內(nèi)

3. 增加全新的輸入：增加全新的路徑，在可能時(shí)復(fù)用舊接口

在這其中沒有任何“重構(gòu)”的余地，如果做了“重構(gòu)”，那說明某些被修改的接口要么減少了輸入約束（意味著以前沒有做到約束最小化），要么拆分了接口（說明以前沒有做到保證最大化），那都是上一次的設(shè)計(jì)失誤。與加引號(hào)的偽“重構(gòu)”不同，真正的重構(gòu)只有在應(yīng)用了全新技術(shù)（比如換了語言，換了基礎(chǔ)框架）的情況下才是有可能的。

這個(gè)原則順便也可以說明我對(duì)類型系統(tǒng)的觀點(diǎn)。在我看來，類型其實(shí)只是約束（保證）的一部分，而并不是全部，而它的缺點(diǎn)可以一言以蔽之：可能導(dǎo)致提供了太多的約束。比如說我們的某個(gè)接口使用了一個(gè)int型的參數(shù)，但是實(shí)際上它可能需要的只是一個(gè)可以執(zhí)行+的對(duì)象，int, float, complex甚至是str其實(shí)都可以，但是設(shè)計(jì)參數(shù)的時(shí)候未必能意識(shí)到這件事；再比如說參數(shù)寫成了某個(gè)類，那就只有它的子類才能傳入，但是實(shí)際上你需要的可能只是某個(gè)interface，而可能因?yàn)楹笃谶壿嫷暮?jiǎn)化，即使是這個(gè)interface也只用到了其中的一部分，那就必須要重新定義interface了。而Duck Type的語言就能保證只有用到的部分才是約束，從而保證最小約束。所以動(dòng)態(tài)類型語言編程總有一種更“純粹”的感覺。