NPM 與 left-pad 事件：咱們是否是早已忘記該如何好好地編程？

轉自：http://www.techug.com/npm-left-pad-have-we-forgotten-how-to-program

開發者朋友們，咱們該談一談這個問題了。大家應該知道本週的 left-pad 事件： React 、 Babel 和許多流行的npm模塊都受到波及，沒法正常運行。

這一事件的原由十分使人詫異。

這些受到影響的模塊都引入了一個叫作 left-pad 的模塊。截至此時， left-pad 這個模塊在Github上也只有寥寥十一個star。在整個模塊中，做者只用十一行代碼實現了一個簡單的字符串處理函數。

如下就是這十一行代碼：

module.exports = leftpad;
function leftpad (str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch !== 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str;
}

讓我感到有意思的是，社區中許多的模塊都選擇引入這個十一行的模塊，而不是花上兩分鐘的時間本身去實現這個簡單的字符串填充功能。

事件發生以後，我開始仔細研究npm生態系統。如下是一些有趣的發現：

• npm上有個叫作 isArray 的模塊。今天一天以內，它就被下載了八十八萬份；光是今年二月，它就被下載了接近一千八百萬份。模塊自己只有一行代碼： return toString.call(arr) == '[object Array]'
• 還有一個模塊叫作 is-positive-integer 。這個只有四行代碼的小模塊，居然還要依賴另外三個模塊。事件以後做者把那三個依賴去掉了；但我仍是弄不明白做者爲何不早這樣作。
• 裝一次 babel 模塊就要引入四萬一千多個文件。
• 隨便一個以 npm/jspm 爲核心的項目模板就要引入超過兩萬八千個文件。

以上這些事實讓我以爲，

咱們是否是早已忘記該如何好好地編程？

這種過分依賴其餘npm模塊的作法是否是解決問題的正確方式呢？如今，一個空白項目模板一裝好就要引入兩萬八千多個文件、依賴成百上千個其餘的npm模塊。這太瘋狂了、並且過分複雜。

我以爲npm生態系統中，開發者有一種不良的、對微型模塊的熱衷。相對於本身實現一些小函數，開發者們更願意去依賴其餘人寫好的模塊。我甚至以爲npm生態系統中的開發者只想儘量地少寫代碼，大量引入別人寫的模塊，拼拼湊湊、串起來交差。

一個函數並不能被稱爲模塊

函數自己過小了，不該該被作成一個模塊並被別的項目引入。一個函數自己並無什麼總體意義，只是隨便一小段代碼而已。假如咱們如今要求一個角度的餘弦值。 咱們確定不會專門爲求餘弦值引入一個「cosine」模塊。若是要算cosine的值，咱們更想要一個功能完整、帶有其餘三角函數的「三角」模塊。 .NET 與其餘許多框架都選擇提供這樣一個功能統一又完整的「核心」模塊。大部分語言的設計者都會很仔細地編寫語言自帶的「核心模塊」：這部分基本上是很安全沒有bug的。

第三方依賴帶來的問題

首先，沒有人能確定別人寫的依賴是否是徹底正確的。也許它們都不能正常工做。退一步說，就算這些東西都寫對了，它們的實現就是最高效的嗎？若是你選擇不用依賴本身去寫，你至少能夠本身fix你能看到的問題、還能去嘗試把它寫得更高效。這不僅是依賴寫得對不對的問題。

其次，就算這些模塊的邏輯正確也十分高效，我仍是感到十分吃驚：開發者們居然懶得本身寫這些一兩行就能實現的功能，選擇去依賴別人寫的模塊；這些功能明明閉着眼睛都能寫對。在我看來，若是你連上面提到的 left-pad 、 is-positive-integer 或者 isArray 都不能五分鐘內邊搜索邊調試着寫完，你其實根本就不會寫代碼。哎，這些小功能真應該被看成面試題：寫不出來的話，只能說候選人不會寫代碼。

最後，我以爲把這些API串到一塊兒、拿別人的模塊七拼八湊的作法根本就不叫編程。這只不過是某種七拼八湊、過分設計、把事情複雜化的行爲。

更糟糕的是，若是你的代碼或者你引入的代碼出了問題或者有些bug，你又不懂得如何真正「編程」，你就沒法解決問題。

咱們應該儘量減小依賴的模塊

每一個你依賴的模塊都會引入其餘的模塊。這些依賴，顧名思義，是一些你不得不須要的東西。你越多地依賴別人的模塊，你的項目就會有越多崩潰的隱患。同時，你的項目出錯的機率更大：你根本就不知道這些第三方模塊的做者是否靠譜。

只有在遇到很是複雜，本身解決起來須要花不少時間、金錢的問題時才應該考慮依賴其餘模塊。好比，當須要一個數據庫中間件（ORM）或者一個作客戶 端緩存的組件時，你應該選擇引入一個依賴而不是本身去寫，由於這些活兒太耗時、太複雜了。引入這些組件能夠省下不少時間；相比之下，它們出問題的風險也變 得能夠接受。

可是除此以外，就算是由於對「編程」這件事的執念，你都應該去寫這些基本的小函數。爲了一個一兩行就能實現的功能多引入一個依賴是一件很蠢的事情。你不信麼？儘管想一想 left-pad 事件以後React 團隊的感覺。如今，他們確定寧願本身去實現那個十一行的字符串填充函數。