如何經過Github提高本身

　　若是咱們僅僅是將本身的代碼commit、push到github上，那麼對於咱們的技術不會有太多的提高。咱們所作的僅僅只是將github當成了咱們的網盤。

　　咱們每發佈一個版本的時候，是否是也就意味着給用戶一個新的版本——持續交付。

敏捷軟件開發

　　顯然我是在扯淡，這和敏捷軟件開發沒有什麼關係。不過我也不知道瀑布流是怎樣的。說說我所知道的一個項目的組成吧:

• 看板式管理應用程序(如trello，簡單地說就是管理軟件功能)
• CI(持續集成)
• 測試覆蓋率
• 代碼質量(code smell)

對於一個不是遠程的團隊(如只有一我的的項目) 來講，Trello、Jenkin、Jira不是必需的:

你存在，我深深的腦海裏

當只有一我的的時候，你只須要明確知道本身想要什麼就夠了。咱們還須要的是CI、測試，以來提高代碼的質量。

測試

一般咱們都會找Document，若是沒有的話，你會找什麼?看源代碼，仍是看測試?

it("specifying response when you need it", function (done) { var doneFn = jasmine.createSpy("success"); lettuce.get('/some/cool/url', function (result) { expect(result).toEqual("awesome response"); done(); }); expect(jasmine.Ajax.requests.mostRecent().url).toBe('/some/cool/url'); expect(doneFn).not.toHaveBeenCalled(); jasmine.Ajax.requests.mostRecent().respondWith({ "status": 200, "contentType": 'text/plain', "responseText": 'awesome response' }); });

代碼來源: https://github.com/phodal/lettuce

上面的測試用例，清清楚楚地寫明瞭用法，雖然寫得有點扯。

等等，測試是用來幹什麼的。那麼，先說說我爲何會想去寫測試吧:

• 我不但願每次作完一個個新功能的時候，再手動地去測試一個個功能。(自動化測試)
• 我不但願在重構的時候發現破壞了原來的功能，而我還一無所知。
• 我不敢push代碼，由於我沒有把握。

雖然，我不是TDD的死忠，測試的目的是保證功能正常，TDD無法讓咱們寫出質量更高的代碼。可是有時TDD是不錯的，可讓咱們寫出邏輯更簡單地代碼。

也許你已經知道了Selenium、Jasmine、Cucumber等等的框架，看到過相似於下面的測試

Ajax ✓ specifying response when you need it ✓ specifying html when you need it ✓ should be post to some where Class ✓ respects instanceof ✓ inherits methods (also super) ✓ extend methods Effect ✓ should be able fadein elements ✓ should be able fadeout elements

代碼來源: https://github.com/phodal/lettuce

看上去彷佛每一個測試都很小，不過補完每個測試以後咱們就獲得了測試覆蓋率

File	Statements	Branches	Functions	Lines
lettuce.js	98.58% (209 / 212)	82.98%(78 / 94)	100.00% (54 / 54)	98.58% (209 / 212)

本地測試都經過了，因而咱們添加了Travis-CI來跑咱們的測試

CI

雖然node.js不算是一門語言，可是由於咱們用的node，下面的是一個簡單的.travis.yml示例:

language: node_js node_js: - "0.10" notifications: email: false before_install: npm install -g grunt-cli install: npm install after_success: CODECLIMATE_REPO_TOKEN=321480822fc37deb0de70a11931b4cb6a2a3cc411680e8f4569936ac8ffbb0ab codeclimate < coverage/lcov.info

代碼來源: https://github.com/phodal/lettuce

咱們把這些集成到README.md以後，就有了以前那張圖。

CI對於一個開發者在不一樣城市開發同一項目上來講是很重要的，這意味着當你添加的部分功能有測試覆蓋的時候，項目代碼會更增強壯。

代碼質量

像jslint這類的工具，只能保證代碼在語法上是正確的，可是不能保證你寫了一堆bad smell的代碼。

• 重複代碼
• 過長的函數
• 等等

Code Climate是一個與github集成的工具，咱們不單單能夠看到測試覆蓋率，還有代碼質量。

先看看上面的ajax類:

Lettuce.get = function (url, callback) { Lettuce.send(url, 'GET', callback); }; Lettuce.send = function (url, method, callback, data) { data = data || null; var request = new XMLHttpRequest(); if (callback instanceof Function) { request.onreadystatechange = function () { if (request.readyState === 4 && (request.status === 200 || request.status === 0)) { callback(request.responseText); } }; } request.open(method, url, true); if (data instanceof Object) { data = JSON.stringify(data); request.setRequestHeader('Content-Type', 'application/json'); } request.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); request.send(data); };

代碼來源: https://github.com/phodal/lettuce

在Code Climate在出現了一堆問題

• Missing "use strict" statement. (Line 2)
• Missing "use strict" statement. (Line 14)
• 'Lettuce' is not defined. (Line 5)

而這些都是小問題啦，有時可能會有

• Similar code found in two :expression_statement nodes (mass = 86)

這就意味着咱們能夠對上面的代碼進行重構，他們是重複的代碼。

重構

不想在這裏說太多關於重構的東西，能夠參考Martin Flower的《重構》一書去多瞭解一些重構的細節。

這時想說的是，只有代碼被測試覆蓋住了，那麼才能保證重構的過程沒有出錯。

如何經過github提高

上面所說的只是一堆堆地工具，以及一堆堆的方法，真正須要的是實踐。

咱們須要有測試，有CI，這樣咱們才能提升本身。

 

　　本文轉自：https://www.phodal.com/blog/use-github-grow-self/