如果我們僅僅是將自己的程式碼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: falsebefore_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，這樣我們才能提高自己。