給編程初學者的一些建議

來自專欄猿論

大家好，我是七月。從第一門《微信小程序入門與實戰》到今天上線的《Python Flask 構建RESTAPI》，我已製作了5門課程。時間流逝的速度永遠超出我們每個人的想像，但很開心的是，製作課程的近兩年時光，收穫要遠超我之前六年的工作生涯。在傳授知識的同時，其實也是對過往編程經驗的總結和提煉。

一年多前，我在慕課寫下了第一篇手記《編程之路》，此篇算是《編程之路》的後記。

知名博主和菜頭有一個常用的簽名：請你相信我所說的每一句話都是錯的。如果你理性的分析這句話，你會發現這句話其實是一個很有意思的悖論，用來證明無論正反、相信或者不相信，他永遠都是對的。

但只可惜，沒有什麼是絕對的正確，編程的經驗與教條也同樣沒有永恆的正確。所謂經驗，都是他人的感悟；所謂教條也都是他人的痕迹；你應當去實踐，去思考，形成自己獨有的編程體驗。

所以，下面的觀點，均是個人體驗形成；雖不「成器」，但好在是「自己的」。

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

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

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

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

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

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

這種感覺妙不可言。

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

2 debug是倚天劍，提出優質問題是屠龍刀

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

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

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

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

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

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

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

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

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

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

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

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

3 努力寫出優質的代碼，而不是僅僅滿足於功能的實現

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

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

通過與這些coder的聊天和查看他們的代碼，我發現，這些coder普遍都只是完成了程序的功能，從來不考慮復用，不考慮維護，不考慮擴展。就像一次性的筷子，用完就扔。

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

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

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

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

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

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

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

4 視頻課程學習最好的方式是自己先實現

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

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

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

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

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

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

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

5 真正的去實踐，而不是一味的學習

老生常談的一個問題。

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

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

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

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

那難道我們就放棄實踐？

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

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

6 學習一定要注重推導的過程，而不是關注結果

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

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

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

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

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

作者：7七月

鏈接：https://www.imooc.com/article/30702

來源：慕課網

本文原創發佈於慕課網 ，轉載請註明出處，謝謝合作

推薦閱讀：

【重磅】認證作者招募 | 打造個人品牌 so easy ！

前端處理小圖標的那些解決方案（圖文實操）

快速上手 Elasticsearch 的幾個建議

【圖片版】GRID，一起來學習CSS網格布局吧！

如何基於區塊鏈技術開發應用

推薦閱讀：