全文共2949字，預計學習時長9分鐘
照片由喬納·皮特裡奇拍攝，來源Unsplas
幾個月前，我為一家技術公司做了一次關于Web元件的報告，當時大多數與會者都沒有使用過Web元件。這次報告非常有趣，廣受歡迎，最後觀衆提了一連串問題，提問環節持續了半個多小時。
接近尾聲時，有人問我：你展示了原始的DOM操作代碼，這是否意味着我們将回到使用“像jQuery那樣的面條式代碼”的時代？我看到一在場些人點頭表示同意，這使我陷入思考。
顯然，那些不屬于某個架構或庫，而隻是我們所說的“Vanilla JavaScript”的代碼，它們會被認為是糟糕的“面條式代碼”。
這沒什麼好奇怪的。
整整一代的開發人員開始時都是使用架構和入門套件，這些架構和套件附帶了一大堆現成的依賴項。隻需運作 npm install ，并根據需要調整代碼模闆即可。
雖然這可能是一個很好的起點，但我們确實需要認識到，程式設計不僅僅是将第三方的庫粘合在一起。
不反對依賴項
首先澄清一下，我并不反對使用依賴項。事實上，本人有很多次使用多個前端架構的經驗。
但是，我希望讀者在考慮使用哪個依賴項之前，先問問自己，是否真的需要這些依賴項來完成下一個項目。
這是一個非常重要的問題。我認為，思考這個問題的人還遠遠不夠。
“不要重新發明輪子”的謬論
讀者可能已經聽過很多次，作為一個開發人員，你不應該“重新發明輪子”，相反，你使用的庫應該已經能供你做想要建構的東西。
例如，當需要使用資料庫ORM時，這句話就是一個好建議。因為現在已經有完備的ORM可供使用，從頭編寫毫無意義。
問題是:決定自己編寫代碼以及決定何時使用第三方依賴項，這兩者之間，我們應該在哪裡劃定界限?
2016年，由于法律因素，left-pad的開發者決定從NPM删除所有的包，這個做法幾乎使網際網路癱瘓。這足以說明人們對第三方軟體的依賴有多麼瘋狂。
left-pad的唯一作用是用0或空格填充字元串的左側部分。這個包隻包含幾行代碼，初級開發人員也可以用幾行代碼編寫它。實際上，left-pad已經被棄用，取而代之的是标準的String.prototype.padStart()，然而仍有成千上萬的項目依賴于left-pad。
而現在情況變得更糟。isarray隻包含四行代碼，它的作用是檢查給定的參數是否為數組。當然，這是針對不支援本地Array.isArray()方法的舊浏覽器而言的，但是任何開發人員都可以在一行代碼中編寫它。
自己編寫這些包的代碼并不是“重新發明輪子”。完全沒有必要在項目中把這些包作為依賴項。
不知道自己在用什麼
盡管如此，有人仍然認為最好使用現成的第三方子產品——即使它們非常小——因為這些第三方子產品經過了“實戰測試”，是“經過驗證的解決方案”。
問題是:你确定事實如此嗎?
你是否真的知道這個依賴項是經過測試和驗證的解決方案，還是僅僅假設它是如此?
你真的知道node_modules檔案夾裡的所有東西嗎?
我不知道，也許沒人知道。坦白地說，你也不必知道。但你至少應該想想要安裝什麼依賴項，自己要編寫什麼代碼。
每個現代遊覽器都已包含fetch，這時你還需要一個龐大的庫來進行簡單的HTTP調用嗎？你自己用幾行代碼就能編寫，而且編寫的程式隻會執行你真正需要的操作，你還需要這樣的大型資料解析庫嗎？
似乎整整一代的開發人員都過于缺乏安全感，不願編寫和使用自己的代碼。反之，他們将各種庫粘合在一起，并假定這些庫已經通過了測試，沒有bug出現。
但這種安全感隻是錯覺。
圖源：pexels
我們為何會變得如此沒有安全感?
為什麼這些開發人員如此不敢信任自己的代碼，而甯願使用自認為更好、更安全的他人編寫的代碼呢?
畢竟這些在Github上釋出開源代碼的人也是開發者，就像我們一樣。他們也不是完美的，他們編寫的代碼可能也有bug。然而，我們卻選擇相信他們，而不是自己。
我了解讀者不願自己編寫像RxJS或者React這樣的庫。這些大型庫已存在多年，有許多貢獻者，并且通過了測試。除非想從中學習，否則我不建議大家重新執行這些庫。
但是對于較小的、可以輕松編寫，并使其完全适應自己需求的功能，我建議讀者自行編寫代碼。這樣至少可以在有需要時輕松修改和修複這些功能。
我猜想開發人員對于自己編寫代碼的不安全感來自于多年使用的庫和架構，這些庫和架構對我們隐藏了最初的JavaScript平台。這種情況始于jQuery的出現，而且随着Angular和React等架構的出現，這一情況變得更加嚴重。
這些架構都是抽象概念，人們認為它們本質複雜。正因如此，開發人員往往将這些作為黑盒使用。
重申，我不反對使用架構，因為我确實看到了其所帶來的價值。但是現在，似乎整整一代的開發人員，他們隻知道如何使用架構進行程式設計，而對底層平台幾乎一無所知。他們不知道如何使用原始DOM，因為他們幾乎從未接觸過它。
我曾參與過幾個evergreen項目，其中的首要問題就是我們應該使用哪個架構，而非我們是否應該使用架構。項目預設的假設就是需要一個架構，而主要論點是架構能提供我們需要的一切，我們不應該重新發明“輪子”。
諷刺的是，這些人中許多都沒有紮實的本地平台知識，無法判斷所選架構首先是否是一個好選擇。
這些架構的複雜性令人生畏，這可以了解，特别是對于初學者來說。他們傾向于将這些架構作為黑盒使用，而不去了解它們的内部工作原理。
架構也不鼓勵了解内部工作原理這種行為，因為它們的工作是通過隐藏底層細節和應用程式設計接口來簡化程式設計。
這就造成了人們對架構的依賴，反過來，也無法給開發人員自己編寫代碼帶來信心。
圖源：pexels
使用依賴項就是将業務外包
在應用中使用依賴項時，基本上就是将這一部分外包給其他開發者，是以你最好確定那個開發者做得很好。
倘若你有一家公司，而你把客戶服務外包給其他公司，這時如果他們把服務搞砸了，你将面臨大麻煩。如果他們對什麼是好的客戶服務有不同見解呢?
你可能不會讓這種情況發生，那麼你應該以同樣的方式對待應用程式中的依賴項。這并不意味着你需要審閱所有依賴項的源代碼，但至少應該切實了解其工作原理。
了解基礎原理
但是要做到了解其工作原理，你首先應該切實了解Vanilla JavaScript程式設計，因為這是一切的基礎。
前端架構肯定會帶來價值，但也意味着複雜的工作和不菲的營運費用。我經曆過學習和執行架構的痛苦，我可以告訴你，你需要確定這些努力是值得的。
使用本地平台很有必要，看看它如今的功能，你會感到震驚。
不要人雲亦雲地說不應該重新發明“輪子”。首先應該學習基礎知識，然後決定是否真的需要這個庫或架構。
如此一來，你會成為一名更優秀的開發者。
留言 點贊 關注
我們一起分享AI學習與發展的幹貨
歡迎關注全平台AI垂類自媒體 “讀芯術”
（添加小編微信：dxsxbb，加入讀者圈，一起讨論最新鮮的人工智能科技哦～）