Github 365天: 給你一年的時間，你會怎樣去提高你的水平

給你一年的時間，你會怎樣去提高你的水平？？？

正值這難得的sick leave（萬惡的空氣），碼文一篇來記念一個過去的366天里。盡管想的是在今年里寫一個可持續的開源框架，但是到底這依賴于一個好的idea。在我的 Github 孵化器 頁面上似乎也沒有一個特別讓我滿意的想法，雖然上面有各種不樣有意思的ideas。多數都是在過去的一年是完成的，然而有一些也是還沒有做到的。

說說標題

盡管一直在Github上連擊看上去似乎是沒有多大必要的，但是人總得有點追求。如果正是漫無目的，卻又想著提高技術的同時，為什么不去試試？畢 竟技術非常好、不需要太多練習的人只是少數，似乎這樣的人是不存在的。大多數的人都是經過練習之后，才會達到別人口中的“技術好”。

這讓我想起了充斥著各種氣味的知乎上的一些問題，在一些智商被完虐的話題里，無一不是因為那些人學得比別人早——哪來的天才？所謂的天才，應該是未來的智能生命一般，一出生什么都知道。如果并非如此，那只是說明他練習到位了。

練習不到位便意味著，即使你練習的時候是一萬小時的兩倍，那也是無濟于事的。如果你學得比別人晚，在 很長的一段時間里 (可能直到進棺材)輸給別人是必然的——落后就要挨打。就好像我等畢業于一所二本墊底的學校里，如果在過去我一直保持著和別人(各種重點)一樣的學習速度，那么我只能一直是Loser。

需要注意的是，對你來說考上二本很難，并不是因為你比別人笨。教育資源分配不均的問題，在某種程度上導致了新的階級制度的出現。如 我的首頁 說的那樣: THE ONLY FAIR IS NOT FAIR ——唯一公平的是它是不公平的。我們可以做的還有很多—— CREATE & SHARE 。真正的不幸是，因為營養不良導致的教育問題。

于是在想明白了很多事的時候起，便有了Re-Practise這樣的計劃，而365天只是中間的一個產物。

編程的基礎能力

雖說算法很重要，但是編碼才是基礎能力。算法與編程在某種程度上是不同的領域，算法編程是在編程上面的一級。算法寫得再好，如果別人很難直接拿來復用，在別人眼里就是shit。想出能work的代碼一件簡單的事，學會對其重構，使之變得更易讀就是一件有意義的事。

于是，在某一時刻在Github上創建了一個組織，叫 Artisan Stack 。當時想的是在Github尋找一些JavaScript項目，對其代碼進行重構。但是到底是影響力不夠哈，參與的人數比較少。

重構

如果你懂得如何寫出高可讀的代碼，那么我想你是不需要這個的，但是這意味著你花了更多的時候在思考上了。當談論重構的時候，讓我想起了TDD(測試驅動開 發)。即使不是TDD，那么如果你寫著測試，那也是可以重構的。(之前寫過一些利用Intellij IDEA重構的文章： 提煉函數 、 以查詢取代臨時變量 、 重構與Intellij Idea初探 、 內聯函數 )

在各種各樣的文章里，我們看到過一些相關的內容，最好的參考莫過于《重構》一書。最基礎不過的原則便是函數名，取名字很難，取別人能讀懂的名字更難。其他的便有諸如長函數、過大的類、重復代碼等等。在我有限的面試別人的經歷里，這些問題都是最常見的。

測試

而如果沒有測試，其他都是扯淡。寫好測試很難，寫個測試算是一件容易的事。只是有些容易我們會為了測試而測試。

在我寫 EchoesWorks 和 Lan 的過程中，我盡量去保證足夠高的測試覆蓋率。

從測試開始的TDD，會保證方法是可測的。從功能到測試則可以提供工作次效率，但是只會讓測試成為測試，而不是代碼的一部分。

測試是代碼的最后一公里。所以，盡可能的為你的Github上的項目添加測試。

編碼的過程

初到TW時，Pair時候總會有人教我如何開始編碼，這應該也是一項基礎的能力。結合日常，重新演繹一下這個過程：

1. 有一個可衡量、可實現、過程可測的目標
2. Tasking (即對要實現的目標過程進行分解)
3. 一步步實現 (如TDD)
4. 實現目標

放到當前的場景就是：

1. 我想在Github上連擊365天。對應于每一個時候段的目標都應該是可以衡量、測試的——即每天都會有Contributions。
2. 分解就是一個痛苦的過程。理想情況下，我們應該會有每天提交，但是這取決于你的repo的數量，如果沒有新的idea出現，那么這個就變成為了Contributions而Commit。
3. 一步步實現

在我們實際工作中也是如此，接到一個任務，然后分解，一步步完成。不過實現會稍微復雜一些，因為事務總會有搶占和優先級的。

技術與框架設計

在上上一篇博客中《 After 500: 寫了第500篇博客，然后呢? 》也深刻地討論了下這個問題，技術向來都是后發者優勢。對于技術人員來說，也是如此，后發者占據很大的優勢。

如果我們只是單純地把我們的關注點僅僅放置于技術上，那么我們就不具有任何的優勢。而依賴于我們的編程經驗，我們可以在特定的時候創造一些框架。而架構的設計本身就是一件有意思的事，大抵是因為程序員都喜歡創造。(ps:之前曾經寫過這樣一篇文章，《 對不起，我并不熱愛編程，我只喜歡創造 》)

創造是一種知識的再掌握過程。

回顧一下寫echoesworks的過程，一開始我需要的是一個網頁版的PPT，當然這類的東西已經有很多了，如impress.js、 bespoke.js等等。分析一下所需要的功能：markdown解析器、鍵盤事件處理、Ajax、進度條顯示、圖片處理、Slide。我們可以在 Github上找到各式各樣的模塊，我們所要做的就是將之結合在一樣。在那之前，我試著用類似的原理寫（組合）了 Lettuce 。

組合相比于創造過程是一個更有挑戰性的過程，我們需要在這過程去設計膠水來粘合這些代碼，并在最終可以讓他工作。這好比是我們在平時接觸到的任務劃分，每個人負責相應的模塊，最后整合。

想似的我在寫 lan 的時候，也是類似的，但是不同的是我已經設計了一個清晰的架構圖。

而在我們實現的編碼過程也是如此，使用不同的框架，并且讓他們能工作。如早期玩的 moqi.mobi ，基于Backbone、RequireJS、Underscore、Mustache、Pure CSS。在隨后的時間里，用React替換了View層，就有了 backbone-react 的練習。

技術同人一樣，需要不斷地往高一級前進。我們只需要不斷地Re-Practise。

領域與練習

說業務好像不太適合程序員的口味，那就領域吧。不同行業的人，如百度、阿里、騰訊，他們的領域核心是不一樣的。

而領域本身也是相似的，這可以解釋為什么互聯網公司都喜歡互相挖人，而一般都不會去華為、中興等非互聯網領域挖人。出了這個領域，你可能連個畢業 生都不如。領域、業務同技術一樣是不斷強化知識的一個過程。Ritchie先實現了BCPL語言，而后設計了C語言，而BCPL語言一開始是基于CPL語 言。

領域本身也在不斷進化。

這也是下一個值得提高的地方。

其他

是時候寫這個小結了。從不會寫代碼，到寫代碼是從0到1的過程，但是要從1到60都不是一件容易的事。無論是刷Github也好(不要是自動提交)，或者是換工作也好，我們都在不斷地練習。

而練習是要分成不同的幾個步驟，不僅僅局限于技術：

1. 編碼
2. 架構
3. 設計
4. 。。。

原文: https://www.phodal.com/blog/github-365-days-review/ 歡迎微博關注: @Phodal