Node.js與JavaScript各自為用戶帶來強大的功能與性能表現，但二者卻又擁有自己獨特的使用成本。首先，JavaScript是一款相對較新的通用型編程語言;其二，Node.js堆棧所采用的錯誤報告與調試方式相當特殊。

[[112863]] 

當我最近與Node.js項目負責人Timothy J. Fontaine探討這些問題時，他表示Joyent——以及其它一些Node.js用戶——在處理過程中采用的辦法值得我們借鑒。

“Node.js使用JavaScript并具備動態特性，”他表示，“因此當大家遇到問題時，很難準確把握到底是哪里鬧出了毛病。在傳統應用程序當中，一旦出現崩潰狀況、我們能夠找到與之相關的核心文件與符號。然而在Node.js JavaScript的V8引擎當中，如果進程卡死、我們根本沒有足夠的信息來弄清到底是哪一步處理過程引發了故障——這是因為全部JavaScript信息都已經不復存在。作為僅有的途徑，大家只能通過添加更多日志記錄或者搜索現有日志來摸索問題發生的原因。”

作為***知名度的Node.js部署問題的受害者，沃爾瑪對此表示有話要說。據稱經過調查，沃爾瑪方面竟然發現Node.js就是導致內存泄露的罪魁禍首，不過Fontaine認為這樣的情況只能算是極端性個例。他同時解釋稱，在大多數情況下、決定事態的關鍵因素在于Node.js與JavaScript的實際使用方法以及環境開發人員對二者的熟悉程度。

“在Node.js的眾多特性當中，最難以把握的就是它的異步本質，”Fontaine指出。“大量內容同時處于運行當中，相比之下PHP、Python以及Ruby的調試對象則只有單一進程或者每個請求中的單一線程。因此對于JavaScript而言，即使是對堆棧進行全盤追蹤都不足以達成調試目標。”

為此，Joyent公司認為大多數由Node.js部署所引發的問題都屬于意料之外的突發事件以及應用程序錯誤，而且這一切在部署流程的早期階段中并不容易發現。

“Node設計思路所帶來的一大副產品在于，”Fontaine解釋道，“JavaScript是一種動態語言，因此我們并不能從編譯器當中獲取靜態運行狀態。這一點既有積極的效果、也會引發消極影響，具體取決于大家的實際開發方式。其實我們遭遇的大部分故障用例都屬于很普通的應用程序漏洞，只不過我們很難重新構建運行歷史、從而再現曾經引發的問題。

為了解決調試過程中面臨的這一阻礙，Joyent公司將其自家SmartOS作為開發平臺。SmartOS屬于OpenSloaris系統的一個分支，其DTrace技術成為該平臺的***特色（除了其他開發人員之外，Joyent公司CTO Brian Cantrill也參與了該技術的開發工作）。DTrace能夠在幾乎不影響性能表現的前提下對應用程序的執行過程進行追蹤與概括，Fontaine與其他不少技術從業者都將其視為檢查Node.js運行代碼的理想手段。

“大家可以在代碼運行過程中查看JavaScript堆棧幀，”Fontaine解釋道。“在其它環境下，我們沒有辦法從這個層面進行檢查。在其它平臺上，我們必須配合特殊標來運行Node、從而獲取額外調試信息，而這會給性能帶來負面影響。”

“Joyent之所以能夠繼續延續這種處理方式，是因為我們編寫了相關工具以幫助自身處理此類問題。此外，我們還積極與其他用戶接觸、將這些技術成果用于幫助他人。”

SmartOS本身是一款基于CDDL許可的免費系統，但大多數人顯然希望能在自己已經在使用的系統平臺上獲得理想的調試工具——而隨著Node.js向著更完善的1.0版本邁進，Joyent方面可能也正在進一步作出探索。

英文原文：http://www.infoworld.com/t/open-source-software/how-joyent-debugs-node-code-242287