可維護的 JavaScript：不要修改不屬於你的對象
我到雅虎後的第一次演講！標題為可維護的 JavaScript（視頻）。與我撰寫或談論的大多數主題一樣，我認為這不會引起太大爭議。談話的基礎是，自己動手和在企業環境中編寫代碼是兩件不同的事情。 Web 開發人員真的很獨特，因為我們都沒有學到我們在學校所知道的東西。我們都以某種方式開始作為業餘愛好者，並自學了我們所知道的大部分（如果不是全部）。
專業化
由於我們不同的開端，Web 開發的專業化一直是一段艱難的旅程。即使是那些最終在雅虎這樣的大公司工作的人！不可避免地開始自己，到處亂砍。也許你甚至是一家小公司的“網絡人”，幾乎可以做任何你想做的事情。當大公司開始利用這個以前未被發現的資源時，它把很多黑客帶到了一個他們遇到限制的公司環境中。不再是小戰場上的孤軍奮戰，所有這些自學成才、自我指導的人必須弄清楚如何作為一個團隊一起工作。
在我發表演講的時候（2007 年），Web 開發正在演變為前端工程，人們在轉換過程中遇到了麻煩。像 Nate Koechley 這樣的聰明人談到了前端工程的專業化（視頻）以及我們的學科是如何發展的。我的演講目標相同：通過確保代碼盡可能可維護，幫助前端工程師適應團隊環境中的 JavaScript 開發。
為什麼我不能修改我不擁有的對象？
我仍然收到有關可維護 JavaScript 的電子郵件和評論，最流行的問題是，“為什麼我不能修改我不擁有的對象？”當然，JavaScript 是一種動態語言，它允許您隨時添加和刪除對象及其成員。對於許多人來說，這正是他們喜歡這種語言的原因：語言施加的限制很少。我告訴他們不要這樣做。為什麼？
可靠性
簡單的解釋是，企業軟件產品需要一致且可靠的執行環境才能進行維護。在其他語言中，您將已經存在的對象視為庫供您使用以完成您的任務。在 JavaScript 中，人們將已經存在的對象視為一個遊樂場，您可以在其中做任何您想做的事情。我的觀點是，您應該像對待實用程序庫一樣對待已經存在的 JavaScript 對象。不要覆蓋方法，不要添加新方法，不要刪除現有方法。
當您是唯一一個在項目中工作的人時，很容易擺脫這些類型的修改，因為您了解它們並期待它們。在與團隊合作進行大型項目時，進行這樣的更改會導致大量混亂和大量時間浪費。我仍然記得在 My Yahoo! 上工作時發生的一個錯誤。因為有人重寫了 YAHOO.util.Event.stopEvent() 做別的事情。追踪這個問題需要幾天的時間，因為我們都認為這種方法正在做它一直做的事情。一旦我們發現了這一點，我們還發現了其他錯誤，因為相同的方法正在其他地方使用其最初的預期用途……但當然，它的行為方式並非如此。解開這是一個令人難以置信的混亂，如果沒有工程師必須進行類似的練習，我會非常高興。
不兼容的實現
但開發人員的困惑並不是唯一的問題。修改不屬於您的對象的另一個風險是命名衝突和不兼容的實現的可能性。從 Prototype JavaScript 庫的歷史中吸取教訓。 John Resig 不久前寫過這篇文章，所以我將快速總結一下。在 1.6 版本之前，Prototype 實現了自己的 document.getElementsByClassName() 方法早在它成為 HTML5 的一部分之前，早在任何瀏覽器考慮本地實現它之前。此外，Prototype 還添加了 each() Array 的方法 對象。因此，Prototype 庫的用戶開始編寫如下代碼：
document.getElementsByClassName("myclass").each(doSomething);
在原生 document.getElementsByClassName() 之前，這不是問題 方法實現了。而 Prototype 的版本返回一個 Array 的實例 ，本機實現返回一個 NodeList 目的。自 NodeList 沒有 each() 方法，無論是原生的還是由 Prototype 添加的，上述編碼模式在具有 document.getElementsByClassName() 原生實現的瀏覽器中執行時都會導致 JavaScript 錯誤 .最終結果是 Prototype 的用戶不得不同時升級庫代碼和他們自己的代碼；真是一場維護噩夢。
如果每個人都這樣做會怎樣？
當您修改不應該修改的對象時，查看一些孤立的示例並不能真正代表維護問題的嚴重性。要理解這種觀點，退後一步看看道德哲學（又名倫理學）會很有幫助。道德哲學就是確定一個行為是否道德。關於這個話題有很多學派，但我指的是最喜歡的現代哲學家伊曼紐爾·康德。
雖然我不想太深入地研究道德哲學並將其展開哲學辯論，但康德以試圖將“普遍法則”確定為道德行為的基礎而聞名。簡而言之，你可以通過詢問來確定一個行為是否道德，如果每個人都這樣做會發生什麼？例如，如果每個人都在考試中作弊怎麼辦？那樣的話，測試就沒有用了，所以這一定不是道德行為。
將同樣的推理應用於手頭的主題，如果團隊中的每個人都開始修改他們不擁有的對象怎麼辦？如果我進去修改 document 我團隊中的其他人也是如此嗎？如果團隊中的每個人都創建了自己的全局變量怎麼辦？我希望這些行為對團隊開發環境的不利影響是顯而易見的。
簡而言之：如果您團隊中的每個人都修改了他們不擁有的對象，您很快就會遇到命名衝突、不兼容的實現和維護噩夢。
作為旁注，我發現康德的問題與任何必須擴展的系統都非常相關。 “如果每個人都這樣做呢？”作為技術設計的一部分，確實可以為您節省一些麻煩。
結論
可維護代碼是瀏覽器更改時不需要修改的代碼。您不知道瀏覽器開發人員將如何發展現有瀏覽器以及這些發展的速度。您編寫的代碼需要繼續在未來的瀏覽器和未來版本的 JavaScript 庫中工作而無需修改，並且您無法確保在修改對象時不是您一開始就創建的。唯一可以確定保持不變的代碼是您自己編寫的代碼。
我不能足夠強烈地說明這一點：當您的代碼需要修改不是您創建的對象時，它是不可維護的。走下這條路只會導致未來的維護噩夢。
附言如果您有興趣了解更多信息，請查看我關於可擴展 JavaScript 應用程序架構的演示文稿（視頻）。
