關於高效、高質和高產

關於高產，不得不提到的一位就是 Sindre Sorhus 大神，截止到寫這句話爲止，Sindre Sorhus 一共在 npm 上發佈了 1123 個包（你看我都不敢說「截止到寫這篇文章爲止」）, 在 Users Ranking - Gitstar Ranking 中能夠看到用戶得到star數量的排名，高居第一而且幾乎是第二名的三倍，以下圖：

什麼？你說你沒用他的包，那你真應該去翻翻大家公司項目的直接或間接依賴。在 Discover your ranking on GitHub 中能夠看到 Discover your ranking on GitHub 關於 JavaScript 的排名，世界第13：

而排名高於他的前12位都是組織而非我的，因此他就是真正意義上的王者。

介紹了一位國外小哥以後，我再給你們介紹一位國內小哥，能夠說接下來要介紹的這我的是個人精神領袖：EGOIST 。固然啦這是他的網名不是真實姓名，可能有的同窗壓根就沒聽過，也不奇怪，由於他在國外的知名度確實比在國內還高，上圖：

看排名狀況，JavaScript 在中國排第五，實際狀況你們能夠去看看，前四位中分別有兩個組織和兩個真人，這兩我的分別是阮老溼和首席Markdown程序員。要是真論起創造和貢獻， EGOIST 第二誰第一？固然了他本人不會這麼說的，畢竟低調的很，不像我就會寫寫文章還騙不來流量。

感覺到了別人的生產力以後，你有想過爲何嗎？

之因此上面提到的兩位被承認，不只僅是他們高產似母豬，更重要的緣由是：他們的做品在質量上是絕對「生產友好」的，換句話說他們的做品讓別人以爲用起來靠譜，做品靠譜的本質是人靠譜。

人的因素咱們不談，咱們來談一下如何讓做品變的靠譜。假設如今的你在看到上面兩位以後早已變得熱血沸騰，巴不得立馬發個包到 npm，惋惜你只是建立了一個 README 而已，殊不知接下來該怎麼作，不要緊讓咱們一步一步來。

首先你要保證代碼風格統一，並附以質量控制，這時候你開始找到 eslint / tslint 求助，通過你無數次的敲擊鍵盤、安裝依賴、翻查文檔你終於搭建了一個你以爲還ok的架子。

接着你發現 prettier 對你來講是個好東西，因而你又經歷了一次敲擊鍵盤、安裝依賴、翻查文檔，不過好在你成功的把 prettier 集成到你的項目中了。

這還沒完，你忽然想要實現一個功能，你但願當文件被保存時自動 fix 代碼風格，因而你找到了一個 vscode 插件，但你只想該插件做用域當前項目，因而你又開始了 敲擊鍵盤、安裝依賴、翻查文檔......

接着你發現了新的問題，假如別的開發者沒有使用用來格式化代碼的vscode插件或者壓根沒用vscode的時候怎麼辦？這時別人是能夠提交「髒」代碼的，因而你開始但願在 commit 以前經過 git hook 可以完成自動格式化代碼的工做，因而你轉而求助於 husky 和 lint-staged 等工具，你再次經歷敲擊鍵盤、安裝依賴、翻查文檔。

好景不長，commit 這個關鍵詞讓你想起來另外一個問題，那就是對於 commit msg 的校驗，由於你想讓你的項目變得專業，因此你但願你的全部 commit msg 都符合必定的規範，因而你開始想辦法校驗 commit 信息，不過好在你的無敵三連「敲擊鍵盤、安裝依賴、翻查文檔」足夠強大，你最終搞定了。

當你發現你的 commit 規範化了以後，你又產生了疑惑，既然 commit msg 已經規範了，那麼若是能自動生成或以交互式的方式填寫 commit msg 就更好了，因而你開始求助於 commitizen 和 cz-conventional-changelog 等工具，雖然此時你已經滿頭大汗，但你不想就此放棄你仍是堅持着把他們集成到了你的項目中。

你擦了擦額頭，當你冰涼的手背觸碰到你額頭的一剎那，你又產生了一個新的想法：咦，既然 commit msg 規範了，是否是能夠經過 commit msg 自動生成 changelog 呢？因而你喝了一口咖啡，準備去拜訪 conventional-changelog-cli 。

至此，你的項目在規範化和代碼風格質量上的保證有了必定的轉機，可是這就是優秀的項目了嗎？不，這只是漂亮的外殼而已，優秀項目的內在必定是經過單元測試(或E2E，因爲是純js項目爲主，因此不提E2E)保證的。因而你又開始了集成單測之路，在一開始你就遇到了一個小問題，你不知道使用哪一個測試庫好，通過你一些列的調查，你發現你最喜歡的兩個測試庫是 jest 和 ava ，可是無論選擇哪一個，你老是要集成進來，因而你又亮出了你的大招：無敵三連。

既然測試都已經集成了，那順便生成測試覆蓋率報告唄，在集成一下 CI 工具，你發現你的無敵三連雖然強大，可是天色已經見晚了，你家裏的女友還在等你....，抱歉我忘記了你沒有女友。

到了這裏，一個項目的雛形就算是有了，不過你卻忘記了一個直觀重要的東西：編譯。你的項目是準備爲何環境提供的？node 仍是 web，環境的具體狀況如何，你的代碼是否須要編譯，若是編譯的話是用 rollup 仍是 webpack？假設你開發的是純 js 項目，並認爲 rollup 更適合一些，你把 rollup 集成了進來。

通過一些列的戰鬥，你仍是以爲差點什麼，你開始糾結於 README 該怎麼寫，你開始查看各大開源項目的 README，企圖借鑑，你開始處處收集 badges ，例如

。最後你拼裝了一個還看得過去的內容，你終於認爲你的項目及格了。忽然，你收到的一條來自你女友的短信：「今晚不用回來了」，抱歉我又忘了你沒有女友了......

雖然你沒有女友或者你女友和你分手了，可是你仍是很開心，由於你有一個及格的項目了，你在回家的路上憂喜參半。

次日你思路爆棚，老子又有一個驚天地泣鬼神的項目了，那麼大哥冷靜一下，我問你個問題：「上面的那些流程你是準備從新走一遍，仍是把第一個項目copy過去改一改？」。若是你重走一遍，恭喜你，你除了對工具的集成熟練度以外可能沒什麼提高，若是你copy修改的話，你卻發現第一個項目除了那些基本內容以外還用了不少本身的依賴和工具，你苦於修改。

並且你是使用 jest 仍是 ava 編寫測試用例的代碼是不太同樣的，最重要的是，是否須要編譯將影響你編寫 jest 測試代碼的方式，諸如此類細枝末節的東西，你要考慮不少。

咳咳，接下來就是廣告時間，爲了不以上問題，咱們可不能夠開發一個模板，而後每次建立新項目的時候都使用這個模板以交互式的方式來初始化？固然能夠，有的同窗可能早就用過 Generators | Yeoman 了。但我這裏給大家推薦我更喜歡的項目：saojs/sao 。

我編寫了一個用於初始化項目的SAO Generator：sao-hcy-nm

每次當你新建項目的時候均可以使用命令 sao hcy-nm，你將會以交互式的方式來根據你的意願建立新項目的模板，並具備本篇文章提到和沒提到的全部特性，以下是一個截圖：

支持以下特性：

• ✅ Respect the code style of prettier
• ✅ Automatically formatted when saving (You need to install the Prettier - Code formatter plugin)
• ✅ Automatic fix code style before commit (Thanks to husky and lint-staged)
• ✅ Check committed messages when committing
• ✅ Use yarn commit instead of git commit (Thanks to commitizen)
• ✅ Automatically generate changelog using yarn changelog (Thanks to conventional-changelog-cli)
• ✅ Automatic deployment with yarn release (Thanks to release-it)
• ✅ Optionally Unit test (jest or ava)
• ✅ Optionally test coverage
• ✅ Optionally compile ES2015 code using (Thanks to bili)
• ✅ Optionally add badge to README

如今，你的生活水平基本脫貧了，想要達到小康水平，那麼還應該繼續向 Sindre Sorhus 和 EGOIST 學習。

最後補充一點，HcySunYang/sao-hcy-nm 做爲 saojs/sao 的生成器，其中使用到了用於編譯的 bili ，而且 saojs/sao 和 bili 都是 EGOIST 的做品。回頭我會和 EGOIST 要廣告費的，手動微笑。