我的技術心病
本文的作者Sasha Goldshtein,他是SELA Group公司的技術長,他是Microsoft C# MVP(最有價值技術人員),是《Introducing Windows 7 for Developers》 (Microsoft Press出版, 2009) 和 《Pro .NET Performance》 (Apress出版, 2012)兩書的作者。他是一位多產的部落格作家,是大量的培訓教程的作者,內容包括並行程式設計、Windows Internals, .NET Debugging, 和 .NET 效能等。他的顧問工作主要圍繞分散式架構和高效能系統。
我發現,對我來說,使用一種新語言,新技術,新框架,最讓我有壓力的事情是,我在使用它們時不能完全明白它們的實現原理。我每週都要閱讀數百篇關於討論諸如各種JavaScript擴充套件、新的iOS應用框架,新的基於Windows Azure的SaaS等的部落格文章。很顯然,如果只是使用一些技術或採用一種框架來滿足需求,這對於我通常不是很難的事情。問題是,如果我並不理解一個東西的工作原理或實現方法,我不能把它歸入我已經掌握的知識。這也是“Not Invented Here(非我造不用)”毛病的一種表現吧,不同的是我並不是想真正的寫出我自己的框架;我只是想做到我有能力寫出它們。下面是我最近的一些例子。
2011年末,我開始學習Node.js,2012年間,我基於Node、Express以及其它很多Node模組,實現了數個私人或商業產品。我開始使用Node時非常猶豫,直到我完全掌握了它的基本原理——事件迴圈,非同步無處不在的屬性——這使我掌握瞭如何實現“類似Node”之類東西的知識。有一段時間我甚至想寫利用新的C#提供的async/await實現一個Node類似的HTTP框架,但最後放棄了,因為網上像這樣的東西很多,比如ASP.NET MVC控制器等,只是不通用。
還有一個事情就是,某種程度是,我仍然有點“恐懼”WPF(Windows使用者介面框架)。我談不上是特別喜歡客戶端開發,但從感受層面上,從各種表現上,WPF是一種比XAML更有吸引力的框架。並不是說WPF很複雜難用:我理解它的一些基本實現原理,比如資料繫結,風格,資源,以及資料模板,這些足夠讓我實現簡單的桌面應用或簡單的Windows8和Window Phone應用。是WPF的深度和廣度讓我困惑:我現在的做法是否是最好的做法?這些XAML表示式究竟是如何在這樣的資料環境和屬性依賴條件下工作的?是否我應該把這段程式碼放到一個單獨的動作或控制裡?…我不是沒努力過:我至少讀了3本關於WPF的書,總頁數超過1500頁,但它們並沒有給我多大幫助。結果是,在潛意識裡,我儘量避免基於XAML的框架,因為我不知道如何實現它。而可笑的是,我對一些“輕量級”的客戶端技術,包括MFC,Windows Forms,Android,以及iOS,都非常有信心,而對於XAML,對於它的那些相對高階的東西,已經在我的心裡留下了畏懼的條件反射。
說一些我感到非常有自信的東西,我對那些利用反射技術的東西,從序列化校驗到程式碼生成,我都感覺很輕鬆。這些屬性,這些反射,10年前當我做一個大.NET專案時就根深於我的腦子裡,從那時起它們對於我就是一個非常強大的工具。我想這歸功於我能理解它們這些物件如何存放在記憶體裡,知道.NET的原資訊是如何組織的。事實上,我差不多同時也就對其他語言和框架裡的反射機制很清楚了:例如,當我在開發非官方的Adnroid SDK時,第一直覺就是想寫自己的JSON序列化工具,而不是利用第三方類庫。之後雖然證明這並不是最好的做法,但我能夠在2小時內讓我的程式支援所有型別的WAMS要求。
最後一個例子,我對新語言有很大的心理壓力,尤其是當這種語言不只是從一種語言編譯成另外一種語言。換言之,我對像TypeScript或CoffeeScript這類語言沒壓力,我可以清楚了理解這種原始碼如何編譯成JavaScript,如何一種新語法變成同種功能語法的一種簡寫。但是,對於一些“新物種”語言,例如Objective C,引起我腦海裡一大堆問號。並不是它的括弧語義給我造成麻煩,而是這種語言的原理,“how”。Objective C語言的物件是如何分配記憶體的?方法是如何排程的?如果方法可以被過載,還能通過名稱進行動態排程嗎?編譯器是如何動態管理記憶體的?(沒錯,引用數計數——但問題遠比這幾個字複雜)。同樣的事情也發生在Python這樣的語言上:我可以使用Python開發指令碼,編寫模組,甚至和C語法風格的DLL互動,但我對這種動態語言裡如何存放一個屬性,如何型別化,沒有一個清晰的畫面。
作為總結,我希望所有的教材都提供一個“工作原理”的章節,來告訴我我如何能實現這種語言、技術和框架——我自己。至此,我希望這篇文章解釋清楚了我為什麼喜歡對技術原理刨根問底、喜歡自己去實現它們。歸根結底的原因是,我喜歡對系統、框架、語言做全面的理解;也許我只需要對某個系統修改一個bug或做效能調優,但最終結果是,我要去知道它是如何執行的,否則,它會變成我的一個心病,拖得越久我會越痛苦。
相關文章
- 我眼中的技術高手
- 我的“技術架構”之旅架構
- 我的技術成長之路
- 是我們控制著技術,還是技術控制著我們?
- 我的技術之路 | 掘金年度徵文
- 我的技術書單 [Hex Note]
- 我的前端之路 | 掘金技術徵文前端
- 我的啟蒙技術經理
- 再見,我的技術夢想
- “我是技術總監,你幹嘛總問我技術細節?”
- 我討厭技術猿
- 從 0 到 1:我的 Flutter 技術實踐 | 掘金技術徵文Flutter
- 我面試過的那些爛技術大哥面試
- 我喜歡的技術性網站網站
- 我是如何準備技術面試的面試
- [譯] 我們採用 GraphQL 技術的經驗:營銷技術活動
- 我在 GitHub 上看到了一個喪心病狂的開源專案!Github
- IT核心技術與我,曾有交集
- 我對技術潮流的一些看法
- 我看技術人的成長路徑
- 我的另類秋招 | 掘金技術徵文
- 雲端計算技術便捷我們的工作
- 我拒絕參加你們的技術面試面試
- 我們Pikacode公司的技術選型
- 「我在淘天做技術」雙11背後的營銷技術體系
- 我走過的學習之路(記我對技術的選擇) (轉)
- 如果我是一線技術主管……
- 我們來聊聊技術債務
- 我為什麼要學技術
- 2010年,我要啟用我的技術blog
- 我最推薦的一本技術書
- 我和技術部落格的這一年
- 五年了,我的技術管理成長之路
- 我的2020回顧——技術篇
- 關於前端技術寫作✒,我想要說的?前端
- 我所瞭解的Linux運維技術Linux運維
- 我是如何從技術轉向產品的
- 我讀過的⼀些優秀技術書籍