Github 365天: 給你一年的時間，你會怎樣去提高你的水平
給你一年的時間，你會怎樣去提高你的水平？？？
正值這難得的sick leave（萬惡的空氣），碼文一篇來記念一個過去的366天里。盡管想的是在今年里寫一個可持續(xù)的開源框架，但是到底這依賴于一個好的idea。在我的Github 孵化器 頁面上似乎也沒有一個特別讓我滿意的想法，雖然上面有各種不樣有意思的ideas。多數(shù)都是在過去的一年是完成的，然而有一些也是還沒有做到的。
說說標(biāo)題
盡管一直在Github上連擊看上去似乎是沒有多大必要的，但是人總得有點追求。如果正是漫無目的，卻又想著提高技術(shù)的同時，為什么不去試試？畢竟 技術(shù)非常好、不需要太多練習(xí)的人只是少數(shù)，似乎這樣的人是不存在的。大多數(shù)的人都是經(jīng)過練習(xí)之后，才會達(dá)到別人口中的“技術(shù)好”。
這讓我想起了充斥著各種氣味的知乎上的一些問題，在一些智商被完虐的話題里，無一不是因為那些人學(xué)得比別人早——哪來的天才？所謂的天才，應(yīng)該是未來的智能生命一般，一出生什么都知道。如果并非如此，那只是說明他練習(xí)到位了。
練習(xí)不到位便意味著，即使你練習(xí)的時候是一萬小時的兩倍，那也是無濟(jì)于事的。如果你學(xué)得比別人晚，在很長的一段時間里(可能直到進(jìn)棺材)輸給別人是必然的——落后就要挨打。就好像我等畢業(yè)于一所二本墊底的學(xué)校里，如果在過去我一直保持著和別人(各種重點)一樣的學(xué)習(xí)速度，那么我只能一直是Loser。
需要注意的是，對你來說考上二本很難，并不是因為你比別人笨。教育資源分配不均的問題，在某種程度上導(dǎo)致了新的階級制度的出現(xiàn)。如我的首頁說的那樣: THE ONLY FAIR IS NOT FAIR——唯一公平的是它是不公平的。我們可以做的還有很多——CREATE & SHARE。真正的不幸是，因為營養(yǎng)不良導(dǎo)致的教育問題。
于是在想明白了很多事的時候起，便有了Re-Practise這樣的計劃，而365天只是中間的一個產(chǎn)物。
編程的基礎(chǔ)能力
雖說算法很重要，但是編碼才是基礎(chǔ)能力。算法與編程在某種程度上是不同的領(lǐng)域，算法編程是在編程上面的一級。算法寫得再好，如果別人很難直接拿來復(fù)用，在別人眼里就是shit。想出能work的代碼一件簡單的事，學(xué)會對其重構(gòu)，使之變得更易讀就是一件有意義的事。
于是，在某一時刻在Github上創(chuàng)建了一個組織，叫Artisan Stack。當(dāng)時想的是在Github尋找一些JavaScript項目，對其代碼進(jìn)行重構(gòu)。但是到底是影響力不夠哈，參與的人數(shù)比較少。
重構(gòu)
如果你懂得如何寫出高可讀的代碼，那么我想你是不需要這個的，但是這意味著你花了更多的時候在思考上了。當(dāng)談?wù)撝貥?gòu)的時候，讓我想起了TDD(測試 驅(qū)動開發(fā))。即使不是TDD，那么如果你寫著測試，那也是可以重構(gòu)的。(之前寫過一些利用Intellij IDEA重構(gòu)的文章：提煉函數(shù)、以查詢?nèi)〈R時變量、重構(gòu)與Intellij Idea初探、內(nèi)聯(lián)函數(shù))
在各種各樣的文章里，我們看到過一些相關(guān)的內(nèi)容，***的參考莫過于《重構(gòu)》一書。最基礎(chǔ)不過的原則便是函數(shù)名，取名字很難，取別人能讀懂的名字更難。其他的便有諸如長函數(shù)、過大的類、重復(fù)代碼等等。在我有限的面試別人的經(jīng)歷里，這些問題都是最常見的。
測試
而如果沒有測試，其他都是扯淡。寫好測試很難，寫個測試算是一件容易的事。只是有些容易我們會為了測試而測試。
在我寫EchoesWorks和Lan的過程中，我盡量去保證足夠高的測試覆蓋率。
從測試開始的TDD，會保證方法是可測的。從功能到測試則可以提供工作次效率，但是只會讓測試成為測試，而不是代碼的一部分。
測試是代碼的***一公里。所以，盡可能的為你的Github上的項目添加測試。
編碼的過程
初到TW時，Pair時候總會有人教我如何開始編碼，這應(yīng)該也是一項基礎(chǔ)的能力。結(jié)合日常，重新演繹一下這個過程：
-
有一個可衡量、可實現(xiàn)、過程可測的目標(biāo)
-
Tasking (即對要實現(xiàn)的目標(biāo)過程進(jìn)行分解)
-
一步步實現(xiàn) (如TDD)
-
實現(xiàn)目標(biāo)
放到當(dāng)前的場景就是：
-
我想在Github上連擊365天。對應(yīng)于每一個時候段的目標(biāo)都應(yīng)該是可以衡量、測試的——即每天都會有Contributions。
-
分解就是一個痛苦的過程。理想情況下，我們應(yīng)該會有每天提交，但是這取決于你的repo的數(shù)量，如果沒有新的idea出現(xiàn)，那么這個就變成為了Contributions而Commit。
-
一步步實現(xiàn)
在我們實際工作中也是如此，接到一個任務(wù)，然后分解，一步步完成。不過實現(xiàn)會稍微復(fù)雜一些，因為事務(wù)總會有搶占和優(yōu)先級的。
技術(shù)與框架設(shè)計
在上上一篇博客中《After 500: 寫了第500篇博客，然后呢?》也深刻地討論了下這個問題，技術(shù)向來都是后發(fā)者優(yōu)勢。對于技術(shù)人員來說，也是如此，后發(fā)者占據(jù)很大的優(yōu)勢。
如果我們只是單純地把我們的關(guān)注點僅僅放置于技術(shù)上，那么我們就不具有任何的優(yōu)勢。而依賴于我們的編程經(jīng)驗，我們可以在特定的時候創(chuàng)造一些框架。而架構(gòu)的設(shè)計本身就是一件有意思的事，大抵是因為程序員都喜歡創(chuàng)造。(ps:之前曾經(jīng)寫過這樣一篇文章，《對不起，我并不熱愛編程，我只喜歡創(chuàng)造》)
創(chuàng)造是一種知識的再掌握過程。
回顧一下寫echoesworks的過程，一開始我需要的是一個網(wǎng)頁版的PPT，當(dāng)然這類的東西已經(jīng)有很多了，如impress.js、 bespoke.js等等。分析一下所需要的功能：markdown解析器、鍵盤事件處理、Ajax、進(jìn)度條顯示、圖片處理、Slide。我們可以在 Github上找到各式各樣的模塊，我們所要做的就是將之結(jié)合在一樣。在那之前，我試著用類似的原理寫（組合）了Lettuce。
組合相比于創(chuàng)造過程是一個更有挑戰(zhàn)性的過程，我們需要在這過程去設(shè)計膠水來粘合這些代碼，并在最終可以讓他工作。這好比是我們在平時接觸到的任務(wù)劃分，每個人負(fù)責(zé)相應(yīng)的模塊，***整合。
想似的我在寫lan的時候，也是類似的，但是不同的是我已經(jīng)設(shè)計了一個清晰的架構(gòu)圖。
而在我們實現(xiàn)的編碼過程也是如此，使用不同的框架，并且讓他們能工作。如早期玩的moqi.mobi，基于Backbone、RequireJS、Underscore、Mustache、Pure CSS。在隨后的時間里，用React替換了View層，就有了backbone-react的練習(xí)。
技術(shù)同人一樣，需要不斷地往高一級前進(jìn)。我們只需要不斷地Re-Practise。
領(lǐng)域與練習(xí)
說業(yè)務(wù)好像不太適合程序員的口味，那就領(lǐng)域吧。不同行業(yè)的人，如百度、阿里、騰訊，他們的領(lǐng)域核心是不一樣的。
而領(lǐng)域本身也是相似的，這可以解釋為什么互聯(lián)網(wǎng)公司都喜歡互相挖人，而一般都不會去華為、中興等非互聯(lián)網(wǎng)領(lǐng)域挖人。出了這個領(lǐng)域，你可能連個畢業(yè)生 都不如。領(lǐng)域、業(yè)務(wù)同技術(shù)一樣是不斷強(qiáng)化知識的一個過程。Ritchie先實現(xiàn)了BCPL語言，而后設(shè)計了C語言，而BCPL語言一開始是基于CPL語 言。
領(lǐng)域本身也在不斷進(jìn)化。
這也是下一個值得提高的地方。
其他
是時候?qū)戇@個小結(jié)了。從不會寫代碼，到寫代碼是從0到1的過程，但是要從1到60都不是一件容易的事。無論是刷Github也好(不要是自動提交)，或者是換工作也好，我們都在不斷地練習(xí)。
而練習(xí)是要分成不同的幾個步驟，不僅僅局限于技術(shù)：
-
編碼
-
架構(gòu)
-
設(shè)計
-
。。。
