上圖為本文的作者Sasha Goldshtein，他是SELA Group公司的首席技術(shù)官，他是Microsoft C# MVP（最有價(jià)值技術(shù)人員），是《Introducing Windows 7 for Developers》 (Microsoft Press出版, 2009) 和 《Pro .NET Performance》 (Apress出版, 2012)兩書(shū)的作者。他是一位多產(chǎn)的博客作家，是大量的培訓(xùn)教程的作者，內(nèi)容包括并行編程、Windows Internals, .NET Debugging, 和 .NET 性能等。他的顧問(wèn)工作主要圍繞分布式架構(gòu)和高性能系統(tǒng)。

我發(fā)現(xiàn)，對(duì)我來(lái)說(shuō)，使用一種新語(yǔ)言，新技術(shù)，新框架，最讓我有壓力的事情是，我在使用它們時(shí)不能完全明白它們的實(shí)現(xiàn)原理。我每周都要閱讀數(shù)百篇關(guān)于討論諸如各種JavaScript擴(kuò)展、新的iOS應(yīng)用框架，新的基于Windows Azure的SaaS等的博客文章。很顯然，如果只是使用一些技術(shù)或采用一種框架來(lái)滿足需求，這對(duì)于我通常不是很難的事情。問(wèn)題是，如果我并不理解一個(gè)東西的工作原理或?qū)崿F(xiàn)方法，我不能把它歸入我已經(jīng)掌握的知識(shí)。這也是“Not Invented Here(非我造不用)”毛病的一種表現(xiàn)吧，不同的是我并不是想真正的寫(xiě)出我自己的框架；我只是想做到我有能力寫(xiě)出它們。下面是我最近的一些例子。

2011 年末，我開(kāi)始學(xué)習(xí)Node.js，2012年間，我基于Node、Express以及其它很多Node模塊，實(shí)現(xiàn)了數(shù)個(gè)私人或商業(yè)產(chǎn)品。我開(kāi)始使用 Node時(shí)非常猶豫，直到我完全掌握了它的基本原理——事件循環(huán)，異步無(wú)處不在的屬性——這使我掌握了如何實(shí)現(xiàn)“類似Node”之類東西的知識(shí)。有一段時(shí)間我甚至想寫(xiě)利用新的C#提供的async/await實(shí)現(xiàn)一個(gè)Node類似的HTTP框架，但最后放棄了，因?yàn)榫W(wǎng)上像這樣的東西很多，比如 ASP.NET MVC控制器等，只是不通用。

還有一個(gè)事情就是，某種程度是，我仍然有點(diǎn)“恐懼”WPF(Windows用戶界面框架)。我談不上是特別喜歡客戶端開(kāi)發(fā)，但從感受層面上，從各種表現(xiàn)上，WPF是一種比XAML更有吸引力的框架。并不是說(shuō)WPF很復(fù)雜難用：我理解它的一些基本實(shí)現(xiàn)原理，比如數(shù)據(jù)綁定，風(fēng)格，資源，以及數(shù)據(jù)模板，這些足夠讓我實(shí)現(xiàn)簡(jiǎn)單的桌面應(yīng)用或簡(jiǎn)單的Windows8和Window Phone應(yīng)用。是WPF的深度和廣度讓我困惑：我現(xiàn)在的做法是否是最好的做法？這些XAML表達(dá)式究竟是如何在這樣的數(shù)據(jù)環(huán)境和屬性依賴條件下工作的？是否我應(yīng)該把這段代碼放到一個(gè)單獨(dú)的動(dòng)作或控制里？…我不是沒(méi)努力過(guò)：我至少讀了3本關(guān)于WPF的書(shū)，總頁(yè)數(shù)超過(guò)1500頁(yè)，但它們并沒(méi)有給我多大幫助。結(jié)果是，在潛意識(shí)里，我盡量避免基于XAML的框架，因?yàn)槲也恢廊绾螌?shí)現(xiàn)它。而可笑的是，我對(duì)一些“輕量級(jí)”的客戶端技術(shù)，包括MFC，Windows Forms，Android，以及iOS，都非常有信心，而對(duì)于XAML，對(duì)于它的那些相對(duì)高級(jí)的東西，已經(jīng)在我的心里留下了畏懼的條件反射。

說(shuō)一些我感到非常有自信的東西，我對(duì)那些利用反射技術(shù)的東西，從序列化校驗(yàn)到代碼生成，我都感覺(jué)很輕松。這些屬性，這些反射，10年前當(dāng)我做一個(gè)大.NET 項(xiàng)目時(shí)就根深于我的腦子里，從那時(shí)起它們對(duì)于我就是一個(gè)非常強(qiáng)大的工具。我想這歸功于我能理解它們這些對(duì)象如何存放在內(nèi)存里，知道.NET的原信息是如何組織的。事實(shí)上，我差不多同時(shí)也就對(duì)其他語(yǔ)言和框架里的反射機(jī)制很清楚了：例如，當(dāng)我在開(kāi)發(fā)非官方的Adnroid SDK時(shí)，第一直覺(jué)就是想寫(xiě)自己的JSON序列化工具，而不是利用第三方類庫(kù)。之后雖然證明這并不是最好的做法，但我能夠在2小時(shí)內(nèi)讓我的程序支持所有類型的WAMS要求。

最后一個(gè)例子，我對(duì)新語(yǔ)言有很大的心理壓力，尤其是當(dāng)這種語(yǔ)言不只是從一種語(yǔ)言編譯成另外一種語(yǔ)言。換言之，我對(duì)像 TypeScript或CoffeeScript這類語(yǔ)言沒(méi)壓力，我可以清楚了理解這種原代碼如何編譯成JavaScript，如何一種新語(yǔ)法變成同種功能語(yǔ)法的一種簡(jiǎn)寫(xiě)。但是，對(duì)于一些“新物種”語(yǔ)言，例如Objective C，引起我腦海里一大堆問(wèn)號(hào)。并不是它的括弧語(yǔ)義給我造成麻煩，而是這種語(yǔ)言的原理，“how”。Objective C語(yǔ)言的對(duì)象是如何分配內(nèi)存的？方法是如何調(diào)度的？如果方法可以被過(guò)載，還能通過(guò)名稱進(jìn)行動(dòng)態(tài)調(diào)度嗎？編譯器是如何動(dòng)態(tài)管理內(nèi)存的？(沒(méi)錯(cuò)，引用數(shù)計(jì)數(shù) ——但問(wèn)題遠(yuǎn)比這幾個(gè)字復(fù)雜)。同樣的事情也發(fā)生在Python這樣的語(yǔ)言上：我可以使用Python開(kāi)發(fā)腳本，編寫(xiě)模塊，甚至和C語(yǔ)法風(fēng)格的DLL交互，但我對(duì)這種動(dòng)態(tài)語(yǔ)言里如何存放一個(gè)屬性，如何類型化，沒(méi)有一個(gè)清晰的畫(huà)面。

作為總結(jié)，我希望所有的教材都提供一個(gè)“工作原理”的章節(jié)，來(lái)告訴我我如何能實(shí)現(xiàn)這種語(yǔ)言、技術(shù)和框架——我自己。至此，我希望這篇文章解釋清楚了我為什么喜歡對(duì)技術(shù)原理刨根問(wèn)底、喜歡自己去實(shí)現(xiàn)它們。歸根結(jié)底的原因是，我喜歡對(duì)系統(tǒng)、框架、語(yǔ)言做全面的理解；也許我只需要對(duì)某個(gè)系統(tǒng)修改一個(gè)bug或做性能調(diào)優(yōu)，但最終結(jié)果是，我要去知道它是如何運(yùn)行的，否則，它會(huì)變成我的一個(gè)心病，拖得越久我會(huì)越痛苦。

英文原文：Using Something You Can't Implement Yourself