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

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

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

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

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

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

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

簡單大于一致性，這個很多例子了，大家從事務的強一致行轉為prefer 最重一致性就是在這點上trade off的最好例子

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

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

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

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

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

當然，很多時候為了測試而測試是不應該，但是有了測試用例，任何的改動只有沒有跑過用例的全都可以自動化檢測出來。

因為接觸新的概念而茅塞頓開的體驗，有時是因為新的知識與原有知識體系打通了。

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

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

突飛猛進的提升常常來自于靈感，而靈感是辛勤思考的果實。

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

同樣一種新的概念、技術，對不同的人意義完全不同。

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

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

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

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

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

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

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

可能對于大多數(shù)人來說，我們兩個人在 diff 工具上的知識盲點是可笑的。即使很強的人，也會在意料不到的地方有盲點。

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

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

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

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

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

要說推薦書的話

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

• 《實現(xiàn)領域驅(qū)動設計》

• 《flex 與 bison》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當以上步驟正確完成的時候，我們一定會得到以下的結果：

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

2. 每個接口都只能產(chǎn)生同一類型的、有最強保證的結果，因而它一定只有一個職責（對應單一職責原則）

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

4. 因為接口的最小約束，所以接口一定只使用了參數(shù)中最必要的信息，也就相當于依賴接口，也不用關心什么難懂的依賴倒置原則了

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

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

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

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

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

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

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

3. 增加全新的輸入：增加全新的路徑，在可能時復用舊接口

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

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