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