個人開源項目——Jerry

時間 2019-12-08

標籤個人開源項目 jerry 简体版

原文原文鏈接

在平常工做中，常常會碰到一些問題，好比數字金額要寫成千分位形式（1234 -> 123,4.00）、要寫成漢字大寫形式（123 -> 壹佰貳拾叄圓），又好比要進行 cookie 讀寫操做，這些問題都比較常見，可是好多經常使用的工具庫都沒有，只能去網上找 snippets，感受很不爽啊。因此我就誕生了一個想法，寫一個本身的開源工具庫！ios

說到作到，一兩週時間我把基本結構搭起來了，而且放在了 GitHub，如今還只實現了部分功能，還有不少的功能要實現。一我的的力量老是有限的，因此我想在掘金吸引一波關注，但願你們可以加入到這個項目的開發維護中來，或者幫我提供更多的建議和想法。git

我爲何要寫這個項目？

首先我先講講我爲何要寫這個項目。github

可能不少人都不屑一顧，由於不少功能都已經有人實現了，並且實現的更好，有些功能的實現也很簡單；可是別人實現了是別人的事情，我認爲我也要本身試一試，可能看起來很簡單的功能你實現的時候才發現並不簡單。又或者你在實現某個簡單的功能當中可以學習到新的知識。
我以前研究過一段時間 Underscore 的代碼，也寫了幾篇筆記，我自認爲仍是在這個過程當中學習到了不少東西的。可是學到了東西還不夠，由於尚未真正實踐過，尤爲是對於 Underscore 的代碼架構的學習，須要好好實踐一下才能深有感觸，因此此次新作的這個項目的架構也是採用的 Underscore 的那一套。實際上那套架構也是許多 JavaScript 工具庫經常使用的架構。
對於一些基礎功能的實現，有利於咱們掌握基礎知識，這是最重要的一點！JavaScript 真的有不少須要學習的地方，咱們天天用着各類框架或者工具庫工做——Vue、React、jQuery、Underscore、fetch、axios……等等等等。這些框架或工具庫確實大大簡化了咱們的工做，提升了咱們的效率，可是你真的學到了不少底層的知識嗎？寫到最後可能咱們就是一個框架使用工，熟練操做 Vue、React……問題是這些能力不少人都會，甚至比你更加熟練，那面試的時候你拿什麼作到脫穎而出呢？我以爲這是咱們都應該思考的問題，咱們不只要會使用框架，還要會一些使用原生代碼搭建框架或工具庫的本領。這也是爲何越是大公司越重視你對基礎知識的掌握程度，由於不少大公司並不會直接使用別人的框架，他們會本身搭建框架（Seajs、Avalon、Omi……）、本身搭建組件庫（Ant-Design、ElementUI……）、本身搭建腳手架（dva）以及本身搭建工具庫（umi……）等等，就算不是本身重寫，也會在別人的基礎上作很大程度的修改、封裝。這就很考驗開發的基礎功力了。因此……我以爲本身要寫這個項目，這個項目不是一個一蹴而就的項目，會經歷很長的時間，在這段時間裏，我能夠學習其餘知識，而後繼續完善這個項目。這樣就能夠作到既學習了新鮮的技術，也鞏固了基礎知識。
寫這個項目可以讓我學到新知識，好比用 rollup 打包庫代碼、用 eslint 檢測代碼語法及風格、用 mocha 作單元測試、用 travis 作持續集成……等等等等，我可以學到不少東西。最重要的是我以爲我可以在寫代碼的過程當中學習到許多兼容性問題。對於有些知識，咱們須要集中精力一舉攻破，好比 Webpack 的使用；可是對於有些知識咱們必須文火慢燉，就好比代碼的兼容性問題。這種問題只能在本身寫代碼的過程當中慢慢去學習，慢慢去積累，經過不斷地查閱 MDN 文檔，咱們就能夠了解到哪些 API 兼容性如何。這個問題實際上也是面試的時候喜歡問的一個問題。

那麼加入這個項目對你有什麼好處呢？面試

爲何加入這個項目

首先看了上面我寫這個項目的理由，我相信不少人也會有一樣的感覺，寫這個項目是有利於提升自身水平的。npm

另外在你面試的時候，對於開源項目的貢獻是可以給你大大加分的。然而不少大型的項目架構複雜、源碼晦澀難懂，並且隨着框架的成熟，須要增長的新功能和須要修改的 bug 其實是不多的，這就大大減小了你對它們作出貢獻的可能。axios

可是如今 Jerry 是一個剛剛起步的項目，功能簡單，代碼架構清晰，只須要你來實現你就能夠對這個項目作出貢獻了。bash

如何加入項目

首先你能夠參考一下這個指導文件，裏面用中文寫的很清楚了。babel

大體的提交步驟以下：cookie

去需求列表下找到心儀的、你有把握實現的且未實現的新功能，固然也能夠是去找 bug。
fork 項目 repo
而後建立一個新的分支（分支命名最好參考一下指導文件），把你的項目拷貝到你的本地：架構
```
$ git clone ...
```
而後切換到你的新分支，開始寫代碼。寫代碼時須要注意：
- （1）注意儘可能使用兼容性較好的原生 API，至少確保是 babel 會轉譯的 API。
- （2）代碼風格請參考已有代碼，運行 npm run eslint 能夠檢測代碼風格及語法錯誤。
- （3）寫完功能代碼請自行添加測試用例到對應文件下，好比 src/packages/String.js 模塊下的新功能對應的測試案例位於 test/String.test.js，而後運行 npm run test 能夠進行單元測試，測試案例所有經過以後纔可進入下一步。
- （4）本地構建代碼，運行 npm run build，確保你的代碼能被打包壓縮。
- （5）新增模塊時，請在 src/packages 下新增對應文件，而後在 test 下新增對應測試文件，最後不要忘了在 src/index.js 中引入對應模塊，不然新模塊的函數不會被暴露出來。
寫完代碼而且經過風格測試、單元測試、構建測試以後，就能夠提交到你的遠程倉庫了，而後能夠提起 Pull Request，在提交 PR 的時候記得描述清楚你本次所完成的工做。我會在 review 以後合併分支。