技術人員初入門，該如何突破早期瓶頸？

這是我在知乎上關于問題“

隻會 if, else, 資料庫 CRUD 的 Java 程式員如何提升自己？

”給出的答案。其實，這應該就是一個關于早期技術人員怎樣突破瓶頸的問題。

作為一個愛好技術的人，我們最常見的技術入門——或者說技術切入點——就是開發有實際可見結果的應用——因為這個夠簡單，夠有成就感。而無論哪個平台、架構上面的應用開發在現階段都逃不開樓主所說的，某個程式設計語言的學習（Java、Ruby、PHP 等），某個資料庫（Mysql、Sqlite、Mongodb 等），再加上樓主未曾說的該架構、平台（Rails、Android、IOS 等）的知識的掌握。

程式設計語言、資料庫、應用開發架構——這三個部分構成了早期從事應用開發的程式員的全部。

是以當進行了夠多的應用開發後，我們就往往會産生這樣的思考——我會寫應用了，但是我覺得我學會的技術别人學了也會，我的優勢在哪裡？我想繼續提高，我該怎麼走？以及類似于樓主這樣更為具體的問題：隻會 if、else，資料庫 CRUD 的 java 程式員如何提升自己？

我覺得，一句話可以指點這個階段的開發人員——向上走，向下走。

向上走，指的是進一步學習設計——沒錯，程式員的工作本質上也是設計（隻是我們好多人都沒有意識到）：代碼設計、算法設計、架構設計等等。之是以覺得自己在重複地做事情，是因為你的每次設計都采用了同樣的方案——排序？用快排吧；生成執行個體并且要解耦？嗯，用工廠吧；要提高系統性能、可用性？嗯，用 cache 吧。雖然說利用現有的設計方案是設計人員的必經之路，但是如果一次又一次的重複利用相同的方案，你就會覺得自己并沒有提高——雖然對于項目本身來說是安全、可靠的。在學會了基礎的應用開發之後，你就算是學會了最基礎的設計方法。然後你要提高，就得繼續去學習更為優秀的設計方法：代碼設計上，我們去參考設計模式；算法設計上，我們去了解針對同一個問題的不同的解決方案的可用場景以及相應的優劣性；架構設計上，我們去探索最适合現在我們應用所處的環境最好的解決方案（聽過騰訊一位技術總監的演講，他們背景的使用者資料、關系系統的架構就有自己的選擇：例如資料庫中的讀取盡量沒有用到鎖）。總之，學會了基本的應用開發，就可以嘗試向上走，走“形而上學”的路子。我想樓主應該已經看出來了，我的建議具體化下來的時候，就是去學習設計模式、算法設計、架構設計（現階段僅僅了解一下就好，将來在實際情況中去實踐的話體會更深）等一系列關于設計的知識。

向下走，指的是去了解系統下面的世界——也就是說，去學習系統的運作機理，“知道機器在幹什麼”（我最敬佩的 C 語言老師所言）。一個應用程式運作起來，就得有各種支援它的系統——計算機硬體系統、計算機作業系統、編譯系統、語言運作時系統。如果不去了解這些“土壤之下”的機制，你就會覺得自己寫的程式有如空中樓閣，不得其中真谛——譬如，同樣能達到目的兩條語句哪個機器執行的效率最高？哪樣的代碼組織會導緻最終程式執行的崩潰？怎樣去避免代碼中的記憶體洩漏？——所謂知其然，不知其是以然也。

是以，代碼要寫的明白，咱就得往下走，去了解底層。我們可以去看看 linux 對于程序的記憶體、CPU 管理機制是怎樣的，進而去優化我們程式的性能；我們可以去看看資料庫的存儲引擎，進而在深刻了解之後寫出更為高效的 SQL 代碼，并且進一步對自己的資料庫進行設定、調優；我們可以去看看 JVM 是怎樣進行垃圾回收的，進而避免 java 中恐怖的隐性記憶體洩漏。樓主向下走，可以去學習作業系統、計算機體系結構、編譯原理以及運作時等知識——你會在學習的過程中對于自己曾經遇到的問題恍然大悟（我就經曆過好多回了，每次都高興不已哈哈）。

最後再提最重要的一點——不要把寫代碼本身作為終極目标，而應該把代碼之上、之下的東西弄透。我想，這也是差別代碼勞工和研發工程師的界限之一吧！

​