Contents
引言瓶頸期的狀態我是怎樣察覺到自己處在瓶頸期的？
我在瓶頸期的狀態如何？
如何渡過瓶頸期什麼是我的瓶頸？
如何解決這些瓶頸？掌握計算的本質
掌握目前主要的硬通貨
我目前的狀態
我在哪些方面提高了？
爲了紀念剛剛出離的瓶頸期，我寫了這篇博文。 同時也總結這一下這段時間的心態與所得。
引言
我目前的職業規劃還是做 技術 爲主。
做爲一個 程序員 ，我覺得 技術 纔是我們的立身之本。只有在技術上掌握到較高的層次，你纔好圍繞着技術拓展自己的其它能力。
當你的技術還沒達到較高的層次之前，就相當於在打基礎。那這個打基礎的過程在我的理解裏有點像上臺階。
當你走一段比較長的平臺，遇到了一個臺階，就是遇到了你的瓶頸。你跨上去了，你就成長了一點，你又會走過一段比較長的平臺。但是隨後的臺階會越來越高，有人經歷了幾個臺階後只能原地踏步、有人只經歷一兩個臺階就另換職業，有人可能會越戰越勇，不斷得突破自己。那我比較幸運，在我的 IT 職業生涯第二年就遇到了的第一個瓶頸期。
瓶頸期的狀態
我是怎樣察覺到自己處在瓶頸期的？
說到怎樣察覺，我體會到的是：
不是突然遇到一件事就讓我察覺到了自己處在瓶頸期。而是在比較長的一段時間內，遇到很多的事情讓你有以下幾種感覺：
工作沒有目標，沒有動力，看不到未來
感覺自己活得好累，事業上平平淡淡，生活上沒房沒車
感覺自己在技術方面很難進步，反而有些退步
感覺自己不明白的東西太多，而自己基礎又太薄弱
... ...
總之一句話：
感覺自己就是一個 loser幹啥啥不行，喫啥啥不剩。
我在瓶頸期的狀態如何？
我是從醫藥行業跨到 IT 行業的。
我爲什麼要來到 IT 行業？
因爲我熱愛編程，覺得編程是件很神奇的事。以編程作爲自己的職業，是我的夢想。
當初我是懷着一腔熱血進入 IT 行業的，衝勁十足，進步神速。只要是和計算機、編程相關的事，我都覺得很有意義，是個學習的機會。
但是經過差不多兩年的時間，我發現自己很難進步了。
我目前的工作是以 Python 爲主，所以就看了大量的目前市面流行的 Python 書籍。但是我發現那些書沒啥好看的，基礎的我都懂，高深的又比較理論化，感覺投影不到現實編程當中。工作的內容也慢慢 Hold 不住了，以前只用寫些小型的界面程序、輔助程序等等。現在面對着複雜的業務邏輯，複雜的業務處理流程，我不知道該怎麼這才能比較好的實現了。
自己平時都有關注一些新技術、新的 Python 庫，新的語言。然後就會花點時間學點皮毛，但總是無法深入。
不斷接觸和湧出的各種技術，讓我感覺無所適從，難不成有一個我就學一個？學到死？
談了戀愛，錢、房子、車子等等這些以前想都不想事情，在女朋友有意無意的提示之下，也覺得這些事成了當務之急。而現在自己，卻一無所有。
看了大量道家的書、佛家的書以及這些圈子的人寫的各類文章，讓我整個人的理想和實現有了很大的矛盾。
總而言之：
整個人生沒有了方向，不知道該怎麼走，也沒有什麼動力走下去。如何渡過瓶頸期
當我意識到自己處在一個瓶頸期時，第一個念頭就是怎麼出離這個令人迷茫而又不舒服狀態。
我就思考我要怎麼做。
什麼是我的瓶頸？
我是一個非科班出身的程序員，基礎的知識薄弱。
我是一個動態語言爲專業的程序員，底層知識薄弱。
我只做過一些小型程序、軟件，中型以及大型系統的設計及編程能力薄弱。
我大部分時間只是在熟悉業務，而對承載業務的各類協議、數據庫、操作系統等目前硬通貨瞭解不深入。
如何解決這些瓶頸？
想要有優質的生活，你需要有好的事業。
想要有好的事業，你需要有市場需求的鶴立雞羣的職業技能。
想要有過硬的職業技能，你需要能人所不能。
想要能人所不能，你需要了解技術的本質，一通百通。
在參考了網上一些前輩寫的文章，我確定了我以後的兩條主線：
先掌握計算的本質、再掌握計算機的本質掌握目前主要的硬通貨
掌握計算的本質
看完《The Little Schemer》、《How to Design Programs》、《structure and interpretation of computer programs》... ...掌握 Scheme、Haskell、prolog。
以實現一門自己的高級語言解釋器爲一個里程碑。
後面的路暫時還未想到。掌握目前主要的硬通貨
掌握 HTTP 協議一個 Web 框架的整個實現原理
以編寫出一個自己的 Web 框架爲里程碑
掌握 Python 實現
以實現一個簡化版本的 tiny python 爲里程碑
Linux 內核實現
以編寫一個自己的小型操作系統里程碑
我目前的狀態
我最近一段時間的心理相對於以前來說，平穩了許多。而且很明顯得感覺到自己已經開始慢慢擺脫瓶頸期了。
怎麼感覺到的？
很簡單。我現在有了方向，有了動力，並且努力朝着這個方向前進。我在哪些方面提高了？
遞歸
之前的理解
印象中的遞歸更多的是教科書內的漢諾塔之類的例子。遞歸效率不高，遞歸層次深了更可能會棧溢出。
現在的理解
在看了《The Little Schemer》後，對遞歸有了更進一步的瞭解。具體的看 glob 標準庫的學習 。
怎樣讀其他人的代碼
之前的理解
剛開始學一門語言時，語法不是很熟悉，看別人代碼關注更多的是 作者寫的是什麼
看完別人的代碼，感覺自己懂了，但是當你脫離作者的代碼想自己實現時，還要時不時地看一下原作者的代碼
現在的理解
但是當你熟悉一門語言後，你應該轉換你的觀點了，應該更多的關注是 作者是怎麼想的
你瞭解到了作者在寫代碼時的整個大腦活動，那作者的代碼就內化成你自己的代碼，同時，由於你本身處於局外人的身份，你還會發現作者的思路缺陷，能夠寫出更漂亮的代碼
程序設計基本思想
之前的理解
單一職責、自頂向下、模塊化、接口先行、自底向上 ... ...只知道這些名詞是啥意思，但是在代碼設計及實現卻沒有有意識的按照這些思想去做。
現在的理解
自頂向下體現的是一種全局觀，根據需求劃分出多個功能模塊、然後每個功能模塊需要提供哪些接口然後再自底向上挨個實現每個功能模塊，當然在每個功能模塊內部也同樣可以複用以上邏輯
設計模式
之前的理解
以前有過一段做 GUI 程序的經歷，在做 GUI 時，我覺得 GUI 這個領域算是面向對象的最佳實踐之一。當時也是首次有意識地將設計模式應用到代碼中。當然，一開始必然是生搬硬套。對着書，覺得這個設計模式有意思，好，看看程序裏哪邊可以使用上。後來，又接觸到了函數式編程的概念。網上很多文章將函數式編程和麪向對象編程放在了對立面，然後將函數式編程捧得很高，將面向對象編程批得很挫。我也受到這種思想的荼毒，走得比較極端，開始厭惡使用面向對象編程，甚至拒絕使用 Python 中的 class 關鍵字定義類。
現在的理解
設計模式最重要的是什麼？設計模式最重要的是它的 SOLID 原則。
單一職責原則：The Single Presponsibility Principle那些所謂的設計模式只是在一定的應該場景中這些原則的全部或者部分的映射。
開放封閉原則：The Open Closed Principle
里氏替換原則：The Liskov Substitution Principle
接口分離原則：The Interface Segregation Principle依賴倒置原則：The Dependency Inversion Principle
class 定義一個類是提供了一種封裝的手段，那麼閉包也是。它們都是爲了實現封裝而提供的工具而已。