關於 JavaScript 的政治、貨物崇拜和可維護性
最近人們重新關注我所說的 JavaScript 中的反傳統運動。似乎每年有一兩次，有人要么發表演講，要么寫一篇文章，說所有所謂的 JavaScript 專家告訴你的事情都是錯誤的，你應該做任何你想做的事。我注意到了，因為我經常和那些告訴你不要做某些事情的人一起列出（你知道，你不應該聽的人）。最近的貢獻是來自 Web Directions 的 Angus Croll 的 JavaScript 政治談話 1 和 James Padolsey 的 NetTuts 文章，JavaScript 中的 Cargo-Culting。兩者都反對關於如何編寫 JavaScript 的普遍信念。雖然我總是喜歡就最佳實踐是否有意義進行激烈的辯論，但我覺得有時討論會出現在錯誤的地方。
可維護性
我有偏見。我認為可維護性在所有代碼中都很重要（不僅僅是 JavaScript）。如果您對我的工作完全熟悉，那麼這不足為奇。畢竟我寫了一本關於 JavaScript 可維護性實踐的書，我寫了幾篇文章並就這個主題進行了討論。對我來說，可維護性是關於創建可以在彼此的代碼之間無縫移動的高效團隊。旨在提高可維護性的代碼約定和其他最佳實踐是通過降低同一團隊中的兩個人以不同方式解決同一問題的可能性來實現的。這對某些人來說似乎是小問題，但在實踐中，以同樣的方式看待事物對團隊來說很重要。
我喜歡將美式足球視為一個很好的例子。也許場上最有趣的關係是四分衛和他的外接手之間的關係。四分衛的主要工作是閱讀防守並找出如何最好地取得進步。外接手的工作是閱讀防守並弄清楚如何最好地打開空位，以便四分衛可以將球傳給他們。這個過程中最有趣的部分是四分衛必須在接球手到達接球位置之前實際投球。因為球需要幾秒鐘才能到達那裡，所以等到接球手完全打開意味著等待額外的幾秒鐘，在此期間防守可能會阻礙。這就是為什麼四分衛和外接手在防守端看到同樣的事情並以同樣的方式做出反應是很重要的。當一名防守球員表現出某種特定的行為時，四分衛和外接手都必須意識到這一點，並以互補的方式做出反應。這是通行證的唯一方法。
開發團隊也是如此。您希望每個人都以相同的方式閱讀該領域。代碼庫中的獨特模式越少，每個人就越容易使用。正如我在許多著作和演講中所說的那樣，代碼實際上是開發人員之間的交流媒介。確保每個人都說同一種方言很重要。
我在做什麼
我發表的第一個演講是關於可維護性的。我並沒有試圖大肆宣傳，也沒有試圖阻止任何人做他們想做的任何事情。我當時所做的，以及我現在繼續做的，就是分享我的經驗。當我說要避免某事時，那是因為我實際上在使用它時遇到了麻煩。當我說某件事是解決問題的好方法時，那是因為我發現它在我自己的工作中很成功。我的大部分建議都與構建大型 Web 應用程序和在大型團隊中工作有關，因為這就是我過去幾年職業生涯的方式。如果您曾經看過我親自發表演講，您可能聽過我說，當您獨自或與其他幾個人一起完成一個項目時，其中一些並不適用。
因為我喜歡與大量人員一起處理大型項目，所以我將大部分精力集中在使這些系統正常工作上。我喜歡可擴展性問題，因為它比其他任何事情都困難得多。我從不從理論背景出發，我從不聲稱我的方式是做事的唯一方式。我公開分享的一切，從我的博客文章，到我的書籍，再到我的演講，都是為了分享我所學到的東西，希望它也能對你有所幫助。如果它對您沒有幫助，我衷心邀請您將我的建議留在不妨礙您的一邊。我不想讓你相信我是對的或者你是錯的，我唯一的願望是分享我學到的東西，讓你以你認為合適的方式使用它。
“我不傻！”
安格斯和詹姆斯的論點都基於這樣一個假設，即那些推薦某些做法的人認為其他人都是愚蠢的。雖然我不能代表所有人，但我認為情況並非如此。推薦某些做法與您是否認為開發人員愚蠢無關。如果這是真的，你可以對每個發表演講或寫書推薦任何東西的人說同樣的話。我不知道人們什麼時候開始對推薦感到如此沮喪，但是指責那些提出推薦的人並說“不要說我愚蠢”是荒謬的。不幸的是，每當有人不同意某項建議時，這似乎就會發生。
這並不是說所有的建議都是好的。這也不是說您應該始終遵循所有建議。但是，您應該停下來思考一下給出建議的背景以及該背景是否適用於您。沒有規則適用於 100% 的時間。這不僅適用於 JavaScript，而且適用於整個世界的每條規則。有例外的事實並不意味著這是一個糟糕的規則。如果這條規則在 99% 的時間裡都成立，那麼它就值得編纂為一個好主意。人們圍繞最佳實踐提出的建議應該以同樣的方式對待。所有規則都是起點，繼續前行，由你決定。
想想開車。大多數道路的中心都有一條線，有些道路的側面有護欄。大多數時候，您希望人們在正確的道路上行駛，而不是駛離道路到人行道上。為什麼要麻煩那些線路和護欄？我相對確定，一個國家/地區的每個人都知道要在道路的哪一邊開車，並且希望保持在您定義的車道內。線條和護欄只是用來加強你在開車時已經知道的東西。他們會給你一些額外的提示。因此，如果您開始在路中間越過界線，您就會知道您可能正在進入一些危險的領域。這條線不會阻止你這樣做，它只是一個期望的指標。然而，我不知道有誰被馬路上的線條或護欄冒犯了。
就像最佳實踐一樣，有時您實際上必須越過這條線或開車越過人行道。如果你要轉向街道的另一邊怎麼辦？如果您需要駛入車道怎麼辦？如果一輛車壞了，你需要繞過它怎麼辦？甚至道路規則也有例外。沒有人真正考慮它，因為我們都只是自然而然地去做。
如果您來自一個向您推薦練習的人認為您很愚蠢的職位，那麼您就是在傷害自己。沒有全球性的 JavaScript 競賽來看看誰能讓最多的人遵循他們的做法。沒有人會通過讓更多的人使用逗號優先而不是逗號最後來贏得任何東西。從字面上看，這個遊戲中沒有任何人的皮膚。
為維護者編碼
Angus 和 James 都使用以下引用（我的最愛之一，來自 Code for the Maintainer3）：
不幸的是，兩者都錯過了這句話的上下文，然後才將其視為不好的建議。這句話並沒有談論你現在的隊友，也沒有暗示要維護你的代碼的人會比你更愚蠢。這句話背後的意思是，您不知道將來誰將維護您的代碼，並且該人將缺乏上下文來弄清楚您的代碼在做什麼。缺乏背景與智力無關。
回想一下你不得不從別人那裡接管代碼的時候。也許那個人還在公司，也許不在。您覺得需要使用該代碼如何？我可以從個人經驗告訴你，這些年來我繼承了一些非常糟糕的代碼。難以使用的代碼，因為很難理解它在做什麼。我認為自己相當聰明，通常在大多數日子裡都高於平均水平，但如果你讓我坐在一些我以前從未見過的代碼前並告訴我解決問題，我可能需要一段時間才能做到這一點.
如果我以一種希望能讓人們更好地理解意圖的方式重述這句話，我會重述如下：
從引用中刪除恐嚇策略短語使其更可口。這個想法是維護您的代碼的人不會將您作為資源，因此代碼必須自己有意義。只存在於你腦海中的假設和組織知識是維護者的敵人。不管那個人有多聰明，沒有適當背景的工作就是一場噩夢。這就是為什麼即使我非常了解 JavaScript，我也無法介入並開始維護您的 JavaScript 庫。這就是為什麼代碼約定和文檔之類的東西對於可維護性如此重要的原因。
如果您的代碼不能被其他人輕鬆維護，那麼這不是質量的標誌。我工作過的團隊都採用了共同的約定，這使得任何人都可以在任何時間點處理任何文件。了解約定意味著您了解文件，這意味著您可以以非常低的進入門檻來完成您的工作。對於我的團隊來說，無論是誰編寫的代碼最終看起來都是一樣的，這讓我的團隊感到自豪，因為最終這是團隊對代碼的責任，而不是個人的責任。
這是一個起點
值得慶幸的是，安格斯以一個非常重要的聲明結束了他的演講：沒有絕對。您聽到的所有規則和最佳實踐只是一個起點。我總是告訴我團隊中的人，我們將定義一些規則並遵循它們，直到它們沒有意義為止。當它們沒有意義時，我們將討論為什麼會這樣，並弄清楚我們學到了什麼。這些規則可以幫助您正確地下車，並確保您無需停下來隨時詢問正確的方法是什麼。這很重要，因為我們的工作基本上是重複的。
我們每天大部分時間都在做同樣的事情。如果您的工作是在產品上創建功能，您會發現功能可以以非常相似的方式實現，即使功能本身非常不同。如果您的工作是修復錯誤，那麼您傾向於以相同的方式調試和修復事物。我們所有人都一樣，編程是重複的。如果每個人最終以不同的方式完成相同的任務，那麼代碼就會變得更難管理。因此，您首先要定義一些關於如何編寫事物的規則，並在出現異常時處理它們。
而且會有例外。例外並不意味著規則不好，它只是意味著上下文發生了變化，規則可能不適用。
我們在這裡真正談論的是技能獲取[4]。這些規則可以讓您開始學習之旅。所有初學者都被教導規則，讓他們快速行動，同時避免常見的陷阱。隨著您的經驗越來越豐富，您會了解更多規則，並開始找出規則不適用的上下文。並非每個人都處於相同的專業發展水平，因此每個人都沒有正確處理他們正在做什麼來拋棄規則。只有通過經驗，這些才會變得更加明顯，因為新手棋手最終會成為大師。
有效學習
這實際上都取決於您選擇學習的方式。每個花時間寫博客文章或發表演講或以其他方式分享他們知識的人都在為您節省寶貴的時間。他們正在為提出一個想法做繁重的工作，而這個想法是否適合你所做的只是由你來決定。認為那些人自動認為你是愚蠢的會適得其反，根本不重要。建議只是提出供考慮的想法。很多時候，這些想法來自推薦者在某個時間點遇到的問題。找出問題所在，您就可以確定上下文是否適用於您。這是最有效的學習方式。或者說得更有說服力：
參考
- Angus Croll (SpeakerDeck) 的 JavaScript 政治
- James Padolsey (NetTuts) 的 JavaScript 中的 Cargo-Culting
- 維護者代碼 (Cunningham &Cunningham)
- Dreyfus 技能獲取模型（維基百科）
