1 興趣不是程式設計最大的動力，成就感才是

        不騙人，我對程式設計談不上興趣。對程式設計有沒有興趣也不是一個人能否寫好程式的必備條件。興趣必然是一種不求回報能讓自我陶醉甚至是沉迷其中的持續性行為。

        ”興趣“太過於美麗，我覺得我遠沒有達到這種高度。”成就感“這個詞也許會更貼切一些。事實上，我們絕大多數人程式設計其實只是為了混口飯吃或者讓自己生活的更好一些。但不得不承認，長期從事一種近似枯燥的“勞作”沒有一些信念與寄託是不行的。

        排除掉程式設計是為了生存這個殘酷的現實，還能支撐我持續程式設計的我認為是成就感。這和打遊戲給我帶來的感覺其實是沒有區別的。

        當我一次次的擊倒關底的boss，當我角色的等級不斷的提升，當我通過自己的努力打出超越常人水平的DPS，當我流暢的按出QWER 5殺後，這種滿滿的成就感是不可替代的。

        程式設計也是一樣。記憶中，我曾經無數次揉著睡眼惺忪雙眼，一邊看著窗外微微發白的夜色，一邊偷瞄幾眼連夜趕出、正在流程執行的程式，心中暗自得意。

        這種感覺妙不可言。

        準確的在程式設計中找到這種”成就感“，甩開”興趣“或者”愛好“的包袱，對於一個程式設計師來說極其重要。為生存程式設計也好，為藝術程式設計也好，為理想程式設計也好，總之，你一定要找到一個可以驅動你長期程式設計的動力。

        debug與提問是程式設計過程中兩個截然相反的方向。debug代表著自我解決問題，而提問代表著尋求幫助。

        如果有可能，我們應當儘量的通過debug來解決問題，而不是通過提問來解決問題。

        我才工作時，當我的程式碼出現了錯誤，我也曾天真爛漫的向我的同事尋求幫助。結果只有兩個：要不就是別人來幫我debug除錯錯誤，要不就是不怎麼搭理我。

        漸漸的，我意識到，不怎麼搭理我是因為我提的問題根本就不是問題，直接把答案放到搜尋引擎上搜一下大把大把的答案就瘋狂的湧現出來；別人幫我debug，這實在是自己懶惰的藉口。

        從此我基本上不再向他人尋求幫助，因為，我不是在造火箭大炮，我也不是在做前無古人後無來者的工作，對於一個才工作的程式設計師，我必定是在重複了其他程式設計師已經重複了無數次的工作，這些必然是可以通過搜尋引擎+自己debug就能尋找到答案的。

        工作5年後，我才真正意識到自己debug分析問題是多麼的重要。初級程式設計思維的形成不是來源於寫程式碼的過程，而是來自於自己除錯程式碼的過程。所以，每一次把希望寄託在他人身上來解決問題，其實都是浪費了一次培養自己程式設計思維的機會。

        那我們可不可以向他人來提問或者尋求幫助呢？可以，但是如果自己一點都不思考就匆忙的發出提問，這絕對不是一個好的做法。如果要提問，儘量保證提問的是優質的問題。

        debug毫無疑問是倚天劍，但只有“優質”的問題才是另一把屠龍寶刀。

        什麼是優質的問題？每個程式設計師功底不同，很難有個準確的定義。但我認為優質問題的前提是，問題必須已經經過你充分的思考，至少要保證你提出的問題思路是清晰的，而不是需要他人debug來幫你解決的問題。我們很難保證一個問題絕對的優質，但如果你能夠自己先深入思考，那麼至少你可以保證整個問題對於你自己來說是足夠“優質”的。

        我再提問區裡看到的最多的問題就是“為什麼出現undefined”，為什麼出現“None”，為什麼報404，為什麼報500錯誤。這顯然都沒有觸及到問題的本質，這些都是可以通過debug來找到原因的。而這些問題恰恰是老師最難以去解決的。因為老師也需要依賴“debug”。不僅僅是老師要debug，全人類程式設計師都要debug來解決問題。除非你是ET擁有人類不具備的超能力。

        所以，遇到問題，首先debug，最好是斷點除錯，堅信debug的力量。一般來說通過debug都能觸及到問題的本質，這些本質的問題可能就超出了你目前知識的範疇，這個時候再提問，就能夠提出一個較為優質的問題。

        好的問題是由問問題的人和回答問題的人共同構建的，我們大多數時候只會想到好的問題是由答者單方面構建的，這顯示是不正確的。不要小瞧問問題，它其實也是一個人能力的體現。

        程式設計到底是不是藝術，我們不做過多的探討。藝術也好情懷也好，都是若有似無的東西。我絕對不會拿程式設計是藝術來說服你為什麼要努力寫出優質的程式碼。

        我在管理研發團隊的過程中發現二個很有意思的現象，第一個就是前面我談到的：鮮有真正視程式設計為“興趣”的coder。第二個就是，程式設計2到3年時，大部分的初級程式設計師不僅不會把程式設計當做興趣，反而會認為程式設計很“無聊”。

        通過與這些coder的聊天和檢視他們的程式碼，我發現，這些coder普遍都只是完成了程式的功能，從來不考慮複用，不考慮維護，不考慮擴充套件。就像一次性的筷子，用完就扔。

        可軟體開發不能像吃飯一樣，吃完就把筷子丟了。軟體開發必然是一個反覆迭代、修正、調整的工程，甚至調整和維護的人並不是你自己。

一次性筷子你用完後自己都不想再撿回來用第二次吧，那怎麼可能別人還願意撿回來繼續用呢？

        咱們很多coder寫程式碼太直白了，標準的“直男型”程式碼。一個Controller中寫100多行程式碼的人大有人在。

        對於普通的程式設計工作，尤其是Web開發，只完成功能不考慮效能、程式碼結構，實在是太過於簡單。你只需要掌握一門語言裡最基礎的流程控制和基本語法就能實現各種各樣的功能，連稍微高階一些的語法都完全不需要。如果一件事情太簡單，沒有任何挑戰，那必然會覺得無聊。

        追求優質程式碼的寫法，是可以讓你長久保持程式設計動力的一個法寶。每個人其實內心都多多少少對“美”有一種期待，長期看到亂糟糟的程式碼，很容易讓你對程式設計厭倦。

        此外，程式碼風格其實分兩類：一類是具體的程式碼，另外一類是抽象的程式碼。人類最直觀的思維方式是從具體開始，所以寫出具體的程式碼是很容易的，但要寫出抽象的程式碼其實是不太容易的。這就好像你通過簡單的繪畫學習就可以畫出一些還不錯的風景，但你要成為梵高，這還是有點難度的，對吧。

        如果要培養這種抽象程式碼的編寫能力，起步條件就是追求優質的程式碼，如果連起步條件都不具備，那程式碼編寫的能力必然逐步趨於平庸。放棄對於優質程式碼的追求，其實等同於放棄了程式設計思考的樂趣，沒有了思考，程式碼哪兒還有你自己的風格和靈魂？

        很早就想談談如何有效的通過視訊進行學習。方法太多了，而且根據每個人的學習習慣又可以演化成各種側重點不同的學習方法。

        但收益最大一種方式是：對於有一定基礎的同學，先不要看課程，直接先看老師專案成品，自己完全獨立的1：1的完成整個專案。全部完成後，再細看老師的課程。

        沒有對比就沒有傷害，也許對比後“傷害”的是你，也有可能“傷害”的是老師。但無論“傷害”的是哪一方，收益的終將是你。假如你被“傷害”了，那你必然是深刻理解了為什麼老師的方案比你要更加優秀；如果老師被“傷害”了，那麼，還用說嗎，你可以去當老師了。

我們平鋪直敘像看小說一樣看完整個課程不能說沒有收穫，但相對於這種對比式的學習，“旅遊”式的學習實在談不上對視訊課程“物盡其用”，挺遺憾的吧。

        我當然知道很難有同學有足夠的耐心先靜心自己實現一遍整個專案。但是，這個行業就是這樣，你必須衡量一下你與你同行業者的優劣勢。如果你沒有良好的外部資源，比如優質的專案、精英的團隊，那麼你只能從自己身上下功夫，去做一些自己惰性所不不願意做的事情，只有這樣才能彌補自身資源的不足。

        如果實在無法完整的實現整個專案，那麼其實可以階段性的自我實現和思考。我的課程通常小節的劃分都是比較講究的，大多數小節是留有“懸念”的，整個懸念就是給你思考的節點。我很多時候會在小節的末尾提出問題，這個時候你就不應該急著去看下個小節的答案。

也許這樣是不是更容易實現一些呢？

        老生常談的一個問題。

        程式設計不是考試，還按照初高中備考的思路去學習程式設計這是不現實的。程式設計是一個實踐性非常強的工種，很多知識和語法你知道並不代表你掌握了。程式設計考究的是你是否能夠靈活的應用這些程式設計知識。很多時候，你只需要在你腦海中留下一個淺淺的印象，當需要解決問題的時候，迅速能夠調出這些知識片段，把他們“組合”在一起來解決問題。細節不記得，不要緊，語言的速查手冊就是幫你具體化這些知識的。

        很多程式設計基礎知識就如同阿拉伯數字一樣，你只看他他就是數字，但你可曾想過數字也能演化出正數、負數、小數、實數、虛數、指數、複數？

        這些變化只有在實踐中，只有在你真正去解決問題的過程中，你才能體會到變化的奧妙與組合的奇妙。

        很多同學經常會抱怨我不在大公司，我沒有優質的專案機會，可你要知道80%的coder都在中小公司，絕大多數coder都沒有接觸優質專案的機會。

        那難道我們就放棄實踐？

        人之所以為人，就在於我們有很強的主觀能動性。外界條件不夠優越，我們就自己尋找。模仿你會嗎？找一個自己很欣賞的產品，1：1或者儘可能在細節上覆制一個產品作為自己的練習專案，有什麼不可以嗎？連設計師的UI設計都給你省了。

        但這個過程中，大家一定要注意細節，如果你只是實現了大體的功能，這意義不大。好的產品其實就優秀在細節上，好的程式設計師和普通的程式設計師一定的差距也在細節上。

        我常在我的課程中談到這個問題。熟悉我課程的同學應該都知道，我很少去講API的呼叫，更多的是關注程式設計思想。程式設計思想具體到課程中其實就是推導的過程。

        工作中我們要更關注成果，但學習一定要注重過程。

        比如在《Python Flask RESTFul API》中，我幾乎二次開發了Flask框架。如果你只是拿到了一份很好用的Flask API框架那我覺得意義不大。關鍵在於我是怎麼一步步的推導、分析和落實這個優質框架的。比如為了解決Python序列化模型很麻煩的問題，我是怎麼想到去尋找JSONEncoder這個物件的，又是如何來重寫他的；而當我們想進一步優化程式碼時，居然發現Sqlalchemy的模型物件在被動態建立時是不會呼叫建構函式的，這個時候你需要注意我是如何去sqlalchemy文件中去找到一個可以出發構造的裝飾器的；再比如，我們採用JWT令牌，那在Flask中我應該如何來支援Token令牌。這所有的實現，我都不僅僅是直接給出大家一個好的結果，而是詳細的描述了我思維的過程。

        語言和框架是學不完的，你只有認真的去跟著我一起思考，才能擺脫受限於語言和框架的思維。很多時候，我課裡所講的內容和思路你放到任何一個語言或者框架裡都是通用的。

        結束語：近兩年來，我看到太多努力學習的同學，很多同學在本科一年級就開始勤奮的程式設計和學習。這讓我回想起我的大學生活，只有兩個字“慚愧”。分享一些我的心得，希望能夠幫助到大家。