演進：如何用練習快速提升技術

有人可以靠中彩票，然後一夜暴富；有人隨隨便便發幾張自拍，就一不小心一夜成名。可技術成長，要一步一個腳印地練習，才能掌握某項特定技術。等到我們掌握了學習的技巧，才能用更短的時間，來掌握某項特定的技術。

而練習，也不是

一天裡寫一萬行程式碼

，也不是

重複寫一百行程式碼

，而是在

一百天裡，每天寫下一百行程式碼

。它需要一定的技巧，不懈的堅持，還有一些休息。因此在這篇文章裡，我將分享工作幾年裡的練習技巧：

基礎篇：正確的練習姿勢。從程式設計師的基本技能：盲打，到練習使用快捷鍵、重構技能等，再到如何使用新的框架練習。

進階篇：如何透過練習來提高。初學時，我們可以使用 Vue、React去高仿一些專案；有經驗以後，高仿應用只會讓我們更累。我們便需要一些更高階的練習技巧，從引入別的框架思想，到造各式各樣的輪子。

找到合適的時間練習。早上，慢慢進入狀態；中午，適合做一些 Review；碎片時候，可以做一些知識的管理等等。

怎樣才能持之以恆下去。分享一些制定目標的技巧，及激勵自己的方式。

當然，練習有一個大前提是：

我們有充足的時間

。時間是一種很珍貴的資源，特別是對於長期加班的開發人員來說。因為

技術能力不足導致的加班

，會變成惡性迴圈。

如果你還沒工作，那麼便相當的幸運，你有相當多的時間。工作的時候，大家都忙於實現業務功能，沒有時間讓你提升自己。如果你已經工作了，那麼你需要每天預留一些時間，才有機會去練習。每天會佔用一些遊戲、看電視時間，哪怕只是半個小時，一週、一個月、一年下來，幫助就很大了。

進行這些練習之前，請不要忘了根本——

能熟練地用框架、語言完成工作

。完成工作，相當於必須達到的 60 分及格要求。在勝任工作之外，提高能力到 80、90 分，追求更好的技術能力，才是正確的路線。

下面，讓我們開始第一部分的內容吧~。

基礎篇：正確的練習姿勢

程式設計的時候，我們只是在碼字——編碼的過程（即思路）實際 上是在腦子裡完成的。嫻熟的碼字能力，可以幫助我們更好地程式設計。

小學時，自參加了五筆打字比賽之後，便開啟了我的程式設計生涯。可當工作的時候，已經可以

熟練的完成工作

的我，仍然無法打對每一個字元。有一天，看到了一個名為 Typing（

https：//

typing。io/

） 的線上程式碼打字練習工具。練習了一次之後，發現它會給出一些建議，便開始進行了一些編碼練習。但是得到的反饋能表明，在打字這方面，仍然有一些提升的空間：

我的“自我解釋”是：

今天的程式語言設計得不合理

——使用了各種字元，導致了右手在這方面的負擔比較大。在那之後，我便陸續進行了一些基礎的練習，並整理他們的因果關係，便有了下面的一些練習專案：

作為經常用電腦的人，應當掌握好打字的基本技巧，比如說採用正確的打字姿勢，以及盲打技能。

作為一個程式設計師，應當“精通”使用手上各式的IDE、編輯器，熟練使用它們的快捷鍵。

作為一個專業的程式設計師，我們還要將重構程式碼、命名等高階的技巧掌握好。

這些練習，可以讓我們成長為一個更專業的程式設計師。

語言與框架的練習

對於語言與框架的練習，算是比較簡單的。於我而言，這種練習過程便是：

買本相關的書籍，或者尋找份教程、官方指南。

再找個合適的 Demo，熟悉基礎概念，並掌握好相關基礎。

在 Demo 的基礎上，實現一些業務功能，瞭解各種功能、特性。

檢視官方文件，查有沒有漏掉了什麼重要的東西。

撰寫部落格、日誌來記錄這個過程。

因此，只需要找一個合適的網站、APP，作為模仿的物件，一步步往下練習即可。唯一的難點在於，第一次寫 Web 應用的時候，可能會多花費更多的時間。新手期的程式設計師，對很多的概念都不清楚，如若能找到一個新手社群、群體，提高起來就會方便多了。

熟練使用語言或者框架，不能幫助我們成為一個『優秀』的成員。只能帶領我們成為一個“勝任”的程式設計師，即我們可以憑藉著這種練習，找到一份養家餬口的工作。

工程實踐練習：模仿開源軟體

工作的時候，寫的都是業務程式碼，純技術上的實踐並不多。這意味著，

多年的工作經驗，與技術能力的關係並無太大關聯

。如果有一天，我們看到幾年前寫的程式碼，和今天寫的程式碼並沒有太大的區別，那麼說明了：我們已然陷入了這樣的一個瓶頸。

在學校寫的程式碼，與工作寫的程式碼，最大的區別在於：

軟體工程實踐

。單單憑藉工作經驗，那麼在軟體工程實踐上的提高可能不會太大。受限於上線 deadline 的影響，多數專案的軟體工程實踐，並不能做到最好，甚至可能很差勁。如我們所見，國內的大部分公司（包括BAT）在這方面的實踐也很難做全，更不用說做好。這些實踐包括：

使用版本管理。諸如 GitHub 上的專案採用的 Git，基本已經普及

使用持續整合。它可以為團隊協作，提供一個可靠的幫助。

完整的測試用例。編寫單元測試、功能測試等等

程式碼檢視。用於提高整個專案的質量

等等

而對於一個優秀的開源軟體來說，為了保證好專案的質量。擁有者往往付出了很多的精力，在提高軟體工程的實踐上。因此，對於軟體工程實踐來說，最好的練習，便是模仿開源軟體，並自己去創造一些輪子。以 React 為例，其在首頁擁有下面的幾個徽章（badge）：

分別是：

Circle CI，即持續整合，諸如測試是否都透過、部署是否成功等等。

Travis CI，同上。

Coverage，程式碼的測試覆率，81%。

npm，當前的版本號。

PRs welcome，即歡迎來 Pull Request。

那麼，我們在實踐的時候，就可以模擬這樣的專案組成，一步步往下實踐：

為專案新增測試框架，如 Java 裡的 JUnit，Node。js 裡的 Mocha 等等。

新增自動化測試指令碼，如 Java 裡的 Gradle，Node。js 裡的 Grunt、Gulp、NPM 等等

新增測試覆蓋率工具。

新增持續整合，如 Travi CI 或者 Circle CI。

新增程式碼質量分析工具，如 Code Climate

制定目標，並完成。

最難的實際上是最後一步，制定一個目標並實現。它可以是測試覆蓋率要達到 90% 以上，這就需要一步步的來完成。如先將目標放到 60%，再慢慢地往上提升，直到 90%，甚至 100%。在這個過程中，會不斷地遇到一些挑戰，如

難以測試的程式碼

，

為了編寫測試而修改功能程式碼

等等。但是，它能確確實實地幫助我們提高工程能力。

基礎練習：從碼字到盲打

編碼的時候，如果我們心裡想輸入的是一個

print

，結果打下的字元是

oront

，那麼我們就需要刪了重來。又或者是小心翼翼地，邊看鍵盤邊輸入一個個字元。雖說，編碼只是一個打字的過程，但是很多時候，經常出現的錯字會中斷我們的思路。因此，

盲打應該成為程式設計師的基本技能

。而這裡的盲打，指的並不是我們可以閉上眼晴打字聊天，而是可以完成程式設計工作，即能盲打下 26 個字母，及各種字元，還有各種功能鍵。

而在進行這一類練習的時候，

我們經常會遇到的一個障礙：度量

。即以某種方式來衡量練習的成果，我們做了很多的練習來提高自己，但是沒有資料來支撐。它不像編碼，我們寫了幾行程式碼，完成了一個功能，那麼寫下的這些程式碼的價值就是可以衡量的。因而練習的時候，我們可以尋找一些合適的工具，如

http：//

Typing。io

、

http：//

Keybr。com

這一類工具。如 Typing 使用的是真實的程式碼片段，它能幫我們發現真實場景下：我們容易打錯哪些字，容易按錯哪些鍵，我們的打字速度是多少等等的內容。

對於

可以衡量的

打字練習，我們可以訂下

每天十幾分鐘的時間

，一段時間要提升到什麼水平的目標。這樣它便能滿足

SMART原則

，就能讓我們看到我們在這段時間內的提升。

當時，我拿 Typing 練習的時候，差不多練習了一個月，每天大概半小時左右。因為打字的速度比較快，所以容易出錯，所以便將注意力放在減少錯誤上。而對於有些人來說，則是相反的，即打字速度比較慢，但是準確率比較高。而這個練習的主要目的是，能熟練地做到

盲打

，不讓它影響我們的效率。

掌握了熟練開關機、鍵盤上的各種按鍵後，我們就在使用工具上做一些效率的提升。

基礎練習：掌握開發工具

剛工作的時候，發現每個有經驗的程式設計師，幾乎可以不用滑鼠程式設計。熟練的使用各種快捷鍵，進行程式碼重構、開啟新頁面、開啟新視窗等操作。慢慢的，我覺得自己在這方面上有相當大的提升空間。

這意味著，我要學習、探索開發工具的功能，也要能使用快捷鍵來控制。儘管在日常結對程式設計、程式碼檢視、交流的時候，可以請從別人身上學習。但是理想的方式，還是應該自己去練習。

對於大部分的開發工具，它們都有對應的手冊、Keymap 或者 cheatsheet，即“作弊表”。如下是 Intellij Idea Keymap 的截圖：

上面列出了其可用的快捷鍵，及其相應的用途。因而只需要列印好，放在眼睛能看到的地方，就能有效的改善。除了列印成紙質資料，他們還可以有不同的形式，如滑鼠墊、杯子的形式。需要的時候，便可以一眼看到；平常多看到幾次，也能多多少少的多記住一些。

需要注意的是

：對於開發工具而言，沒有必要掌握所有的快捷鍵，而是隻掌握

常用的功能

。我曾陷入了一個誤區，練習使用快捷鍵的時候，邊練習一些重構的技巧，同時也花費了時間在練習一些『屠龍之術』上——一些非常少用的功能，除了炫耀，也沒有什麼用。時間一久，我便忘了很多的快捷鍵。

再舉些例子：如 Vim，對我而言，一般用於伺服器維護及 Git 修改。因此，主要使用的功能便是：快速地改幾個字元、更新配置，儲存並退出。如 Chrome 瀏覽器，在日常使用時，配合下 Vim 外掛，便不需要滑鼠。在進行前端開發的時候，便需要使用滑鼠來除錯。

對於大部分的工具來說，我們只需要一個 CheatSheet。複雜的工具，如 Vim、Emacs，則需要有一本更專業的書。它們是高度可定製的，這也意味著我們需要一步步的定製這些工具，尋找合適的外掛，自定義快捷鍵，又或者是使用別人的配置。

而，要衡量快捷鍵使用方面的提升，目前還沒有看到有效的度量工具。如果有的話，那麼就是編碼的時候，使用滑鼠的頻率。因此，在某些特定的時候，可以透過禁用滑鼠來提升自己在這方面的能力。

進階篇：如何透過練習來提高

儘管我在上面指出，學習新框架的最好姿勢是：基於現有的業務來學習。即從工作中學習，從做中學。但是，如果一直

只使用

新的框架來重寫舊的業務，那麼你的成長就會趨近於 0。第一次，使用新框架時收穫可能頗豐；第二次，收穫的東西就更少了；第三次，你可能就學不到東西。

因此，在業餘的練習時間裡，不要一直練習新的框架，不要再拿 Vue、React Native 去高仿一些應用。

當且僅當，你所處的專案正在使用新的框架

，這種練習才是有意義的。

經過上面的練習，我們提高了我們的工作效率。同時，在別人的眼裡，我們更像是一個專業的程式設計師。在這之上，我們還需要提高頂層的能力。下面介紹的是，我嘗試過的一些，比較有效果的提升方法：

閱讀開源軟體與重構程式碼

造自己的輪子來重寫應用

結合設計模式

引入其它領域的思想

總的來說，收穫還是蠻多的，特別是造輪子，能有更大的提升。與其他的練習稍有不同的是，因為涉及到程式碼設計，這裡的練習有些難以衡量。這時候，我們應該是保持著

練習的心態

，並意識到我們是在做這方面的練習。

閱讀開源軟體與重構程式碼

如果在工作環境中，沒有程式碼寫得比較好的人，那麼我們就只能從開原始碼中去學習。筆者之前寫過一篇《如何以“正確的姿勢”閱讀開源軟體程式碼》的文章，文中我建議的閱讀開源軟體程式碼的方式是：

clone 某個專案的程式碼到本地

檢視這個專案的 release 列表

找到一個看得懂的 release 版本，如1。0或者更早的版本

讀懂上一個版本的程式碼

向後閱讀大版本的原始碼

讀最新的原始碼

可只讀這些程式碼，不能讓我們顯著的提高水平，我們應該結合『重構』這個技能來練習。從我的練習經驗看來，

對於重構的練習是最有意思的

。我們可以見證，一段不好的程式碼在我們的調教之下，煥發出新的光彩。當我們重構一段壞味道的程式碼，對比重構前後的程式碼，便會發現自己竟然有這樣神奇的能力。

如果找不到合適的練習專案，可以到 GitHub 上找一些

star 多

，但是

沒有測試

、

缺少 CI

等的專案練習，這樣的專案在 GitHub 上也是蠻多的。

有一次，我在尋找一個迷你的 Markdown 解析器，看到 GitHub 有一個精巧的實現。它有 100+ 的 star，但是沒有測試、四百行的程式碼裡，有一個方法有三百多行等等的壞味道。於是，便花了幾天的時間，邊思考邊重構這個專案。這樣對編碼的提升比較大，因為工作的時候，完成任務是第一優先順序，然後才是質量。

因此，對於我們練習來說，我們只需要：

找一個不錯的開源庫

閱讀其中的程式碼

找到程式碼中設計不好的地方

對

自己認為設計

得不好的程式碼重構

結合《重構》一書，來改進設計

需要注意的是

：不同的人對於程式碼設計，有著不同的觀點。因此，在這時如果只是因為程式碼的設計不好，而不是程式碼裡有各種壞味道（code smell），那麼，就不應該去給別人的程式碼提 Pull Request。

造自己的輪子來重寫應用

與閱讀程式碼、重構相比，造一個自己的輪子，來實現同樣的功能，便是一個更不錯的選擇。在 Web 開發領域，大部分的開發框架本身都是『通用型』的框架。即它擁有相當多的功能，其中有很多的功能都不會用到。如你使用 jQuery 的時候，你可能只會使用到其中的 Ajax、Event等功能，那麼你就可以寫一個新的框架，相容這兩個介面。

練習時間充裕的時候，便可以自己動手去做一個。上面說到的閱讀框架程式碼，是一種好的方法。除此無論是前端還是後端，我們都可以找到從零建立框架的資料，來幫助我們理解框架的組成。

透過閱讀諸如 Python 裡的 Flask、 Ruby 裡的 Sinatra 等輕量級的框架，我們就能理解一個框架所需要的元素，並模仿他們做出一個新的系統。這些框架的關注點是：處理 HTTP 請求的 CGI、與資料庫互動的 ORM、控制邏輯的 Controller 層、返回 HTML的 View 層等等。除了相關的框架，我們還能在 GitHub 上看到很多人模仿這些框架。做一個這樣的後臺框架，搭建自己的部落格，那就能理解好這一系列的邏輯了。

對於前端來說，也是類似的，諸如 Building React From Scratch，可以讓我們在 250 行理解 React 的原理，並做出一個類似的框架。除了 MVC，還有模組化設計、資料請求等等的內容。在兩三年前，《JavaScript框架設計》就是這方面一個不錯的選擇。

我曾經造過一個名為 Lettuce 的前端框架，它的主要目的就是用於：學習前端框架的設計，便在自己的多個業餘專案上使用這個框架。而在前端領域，定製自己的 UI 框架、CSS 框架也是一個很不錯的選擇。再用到自己的部落格上，再寫上『自豪地採用xx框架』，豈不是更加的自豪？

在底層領域，又有各式各樣的《自制作業系統》、《自制程式語言》、《自己動手設計物聯網》等等的書籍，它們都能讓我們從底層理解一個系統的組成。除此，還有各種各樣的剖析類書籍，可以讓我們理解底層機制的同時，也能讓我們製作出一個框架。

最後，我們只需要能不改寫或少數改寫程式碼，將我們的應用執行在上面，便是成功的一個仿造的輪子了。

結合設計模式

設計模式，不同的人有不同的看法。在我看來，一個優秀的程式是要能『看懂』的。即不一定要精通，但要能識別出來，它是一種設計模式。當我們看到了一次又一次的相似設計時，應該猜想到，其背後應該是一種設計模式。如在前端開發框架中的『雙向繫結』，它實際上就是釋出-訂閱模式，又或者稱觀察者模式的一種實現。

在筆者看來，模式就是一種高階的語言。當別人一說『工廠模式』，多數人瞬間就明白了，不猶得會發出：原來如此，這一類的感嘆。認識了一些模式後，一遇到一些特定的場景，我們就能一下子套用這種模式。

可只憑閱讀 GoF 的《設計模式》一書，又或者《Head First 設計模式》、《重構與模式》等設計模式書籍，我們所學的知識便是有限的。我們要做的是：

先熟悉書本上的示例程式碼，來對不同的設計模式有一個大的瞭解

識別日常程式碼中的設計模式

練習這些設計模式，並

掌握常見的設計模式

嘗試在日常的程式碼中，套用設計模式

重構現有的程式碼到設計模式

要對設計模式進行練習，不是一件容易的事。並且很多時候，容易模稜兩可的情況，即適合使用 A 模式，又適合使用 B 模式。這是因為我們是在為設計而設計，因此會盡可能的貼近現有情況。

引入其它領域的思想

不同的領域裡，都有自己領域的優秀思想。如我們熟知的設計模式，便是受建築領域的《建築的永恆之道》中描述的 253個 建築模式的啟發。又如今天流行的精益思想，最早是來自汽車製造業，可它對軟體行來說，有著令人受益匪淺的啟發。好的框架、軟體是會相互學習，如 iPhone 與 Android，都在不斷地借鑑——通知中心，但是又在那之上做一些改進。

又比如，今天的前端框架裡，很多思想都是從後端“借鑑”過來的。如 Angular 中採用的依賴注入，便是深受 Java 語言的影響。近一點來說，Redux，框架最初是用在 React 上，但是它已經被推廣到了 React 和 Vue。js 上。

因此，當我們發現一個新的優秀思想產生時，便可以嘗試引入到自己的領域裡。又或者我們所處的領域，正遇到一些難題，答案可能就在別的領域裡。可在這方面的練習，往往都是一些創新性的練習。多數時候，我們的探索可能沒有結果，但是它往往能對自己有更大的啟發。

找到合適的時間練習

每天能有半小時、一小時甚至更長時間的穩定練習，比三天打魚兩天曬網的效果要好得多。清理出一些固定的時間，用於為自己騰出時間來提高自己。既然，你都有時間到這篇文章，那麼你應該屬於能騰出時間的人。

如果不能的話，那麼我們也可以嘗試去擠出一些時間，如從上下班去尋找空間。即使是同一公司，不同的人都有不同的上下班時間，所花費在路上的時間也有所不同。有的人，需要在幾環外坐個一個多小時的地鐵，再轉公交才能到公司；有的人，只需要出門左轉，走個十分鐘就到公司了。因為在路上花費的時間不同，也在一定程度上影響了學習、練習等等的時間。

因此，如果可能的話，應該減少花費在上班路上的時間，才能避免繼續陷入這樣一個惡性迴圈：

租不起近的房子，花費大量的時間在路上，沒有時間提升技能

。

早上

早上的練習，是一種慢慢進入一天工作狀態的感覺。一旦上班時間到來的時候，就已經進入工作姿態了——對於“資本家”來說，可謂好事一件。早晨剛醒來，總會想不起昨天專案做到哪一步，便更容易反思哪裡做得有問題。

如筆者已經習慣了，每天七點起床、洗漱，隨後寫會程式碼，再去上班。有時候，可以有一個半小時的練習時間，有時候會有半個小時，將這些時間浪費在夢裡總是有些可惜。同時，之前為了能成功地上公交，便提前半個小時到公司，寫一些開源軟體的程式碼。畢竟，作為一家非產品公司，你無法和別人解釋說，我們做了些什麼、取得了哪些成就。

在很多地方，這是一個很好的策略：

錯開高峰期上下班，路上就不容易堵車

。所花在路上的時間就縮短了，那麼我們就有時間來練習了。

需要注意的是：

練習的時候不要關注時間，而是關注怎麼於提高

。關鍵點在於：讓每天進步一點。

中午

吃完飯後，因為米飯血糖指數高的緣故，容易犯困。對於北方的同學來說，因為主食不是米飯，所以這就不算是一個問題了。這個時候，身體會妨礙我們進行一些練習。可如果你的午休時間比較長，那麼也可以做一些練習，再去休息片刻。

碎片時間

對著螢幕寫程式碼，時間一久，集中力就會開始渙散，便應該休息會兒。刷刷資訊、朋友圈，又或者收集各種資料，開放我們的視野。接收各種新的知識，來擴大自己的視野，以便於自己瞭解整個市場的水平。

常見的方式有：

閱讀個人部落格、微信公眾號。

維護自己的 Awesome 列表——尋找自己覺得好的開源專案

IT新聞、技術文章聚合網站——我很不喜歡聚合網站，大部分的聚合站點的行為無異於文章抄襲

GitHub Trending

將這些內容儲存到 Evernote、WunderList、OneNote 等各式各樣的雲筆記裡，然後

定期清理

、

定期清理

、

定期清理

。收集只是一種方式——沒有啥用的方式，

因此建議先讀完一遍

，再去收藏這樣的文章。多數時候，我們會發現自己收藏了很多的內容、買了很多的書，但是卻沒有時間去讀。

晚上

經歷了漫長的加班，回到住的地方，可能就會想休息了。如果白天沒時間練習，晚上也不能抽出時間練習，長期以往，一年的工作經驗就要變成五年來用了。

晚上練習的同時，我們應該注意：在睡覺前 30~60 分鐘停止編碼，否則上床的時候，腦子裡可能還是這些程式碼，就容易失眠。萬一靈感一來，那就還要爬起來繼續寫。這個時候，可以

閱讀

一些相關或者無關的書籍、資料。在閱讀的過程中，儘管我們已經不在思考內容。但是潛意識裡還在思考中，

這時就能很容易就會遇到一些靈感

。

最後，休息的時候，盡情睡覺吧~。

怎樣才能持之以恆下去

在上文裡，我們只談論一些方法和技巧，可是它們並沒有什麼用。每個人都知道所謂的『一萬小時理論』，但是真正要堅持下來，並沒有我們想象中的那麼容易。

我們需要從娛樂時間裡抽到一部分，原本舒適的玩遊戲、睡覺、刷微博時間，現在要成為另外一種『痛苦』？可是，既然這些“無聊的事情”我們都能上癮，那麼我們是不是沒有找到合適的路？

設定目標與 SMART 原則

按上文中的分法，練習可以分為：

日常固定時間的練習

，及針對

某一特定主題的練習

等多種型別。當我們開始練習某一個具體的技術、框架、模式時，最好能制定一個簡單的練習計劃，如每幾天練習某一內容、多少天內用某一個框架實現什麼功能。

先設計一個小的目標，並且能在短期實現

。當發現自己可以輕鬆地堅持下來時，再慢慢的擴大目標，直至我們能做得更好。可是，設定一個練習目標也不是一件簡單的事，它也有很多考量的地方。

畢業的時候，在公司接受了針對於畢業生的培訓，期間學習到了一個用於制定任務、目標的 SMART 原則：

具體的（Specific）

。即我們要有一個

明確的

目標，如在一週內用 Django 寫一個部落格系統，而不是用 Django 寫個東西。

可度量的（Measurable）

。即衡量是否達成目標，我們只需要能建立、檢視、刪除部落格，那麼我們就算完成了這樣的任務。它可以用來不斷地突破自己。

可實現性（Attainable）

。即這個目標一定是可以實現的，不能實現的目標沒有啥意義。與些同時，練習初期定下的目標不能困難。

相關性（Relevant）

。即目標與其他目標的關聯情況，如我們練習 Django 是為了提高 Django 或者後臺的技能。如果我們的大目標是提高前端技能，那麼這個目標對於當前的意義並不是太大。

時限（Time-based）

。即時間限制，如上面提到的

一週內

用 Django 寫一個部落格系統的期限。

經常能在微信朋友圈看到，朋友的 100 天英語閱讀計劃，這樣的目標就是合理的——可實現的、具體的、有時間限制、可度量的。

如果我們想每天固定時間進行練習，那麼我們應該做一個短暫的嘗試，如七天，再慢慢的不斷擴大時間目標，二十一天、兩個月，隨後再擴大到一個更大的目標。

堅持與激勵自己

我們可以使用 GitHub 上的 Contributions 來激勵自己，每一天的痕跡都很明顯，甚至於可以拉攏一些小夥伴，與我們一起參加類似的活動。GitHub 本身具有社交屬性，可以讓我們看到別人做了什麼，做了多久。

由於 GitHub 的伺服器在國外，訪問的時候可能會受限於網路。國內的開源中國的碼雲和 Coding 也有類似的活躍度，建議訪問 GitHub 有問題的讀者，可以使用這些服務。

上文中提到的朋友圈 100 天英語閱讀計劃，也是相似的，它可以讓別人監督你是否完成——前提是，有人一起和你做相同的事，因此

可以找個人和你一起練習，相互監督

。

剛開始練習的時候，練習的內容基本上很充實。時間一長，可能就會陷入一些瓶頸：要麼找不到合適的練習內容，要麼覺得練習過於乏味。因此這個時候，可以切換不同型別的練習專案——如，做一些自己覺得有意思的小專案練習。又或者，當我們完成一個目標時，給自己一些獎勵，以此來鼓舞自己。

總結

練習完之後，還有一種很好的提高方式，就是輸出、總結。整理自己練習過程中學到的知識，將之與我們需要的技能做對比，我們就會發現：在哪些地方還需要提高。我們就能製作出下一次練習的目標，不斷地反覆，以些來提高自己。

經常做總結，除了看到自己提高的地方，還能讓閱讀文章的人，鼓勵你更好的前進。

那麼，現在讓我們建立一個專案，更新一次 README，開始練習吧！

原文於 2017。05。23 寫在 GitChat 上，現在可以發在自己平臺上了。

這是一篇價值 5000+ 的文章~~。點選

可以購買支援~~，哈哈