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

這是我在知乎上關於問題「只會 if, else, 數據庫 CRUD 的 Java 程序員如何提高本身？」給出的答案。其實，這應該就是一個關於早期技術人員怎樣突破瓶頸的問題。

做爲一個愛好技術的人，咱們最多見的技術入門——或者說技術切入點——就是開發有實際可見結果的應用——由於這個夠簡單，夠有成就感。而不管哪一個平臺、框架上面的應用開發在現階段都逃不開樓主所說的，某個編程語言的學習（Java、Ruby、PHP 等），某個數據庫（Mysql、Sqlite、Mongodb 等），再加上樓主不曾說的該框架、平臺（Rails、Android、IOS 等）的知識的掌握。

編程語言、數據庫、應用開發框架——這三個部分構成了早期從事應用開發的程序員的所有。

因此當進行了夠多的應用開發後，咱們就每每會產生這樣的思考——我會寫應用了，可是我以爲我學會的技術別人學了也會，個人優點在哪裏？我想繼續提升，我該怎麼走？以及相似於樓主這樣更爲具體的問題：只會 if、else，數據庫 CRUD 的 java 程序員如何提高本身？

我以爲，一句話能夠指點這個階段的開發人員——向上走，向下走。

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

向下走，指的是去了解系統下面的世界——也就是說，去學習系統的運行機理，「知道機器在幹什麼」（我最敬佩的 C 語言老師所言）。一個應用程序運行起來，就得有各類支持它的系統——計算機硬件系統、計算機操做系統、編譯系統、語言運行時系統。若是不去了解這些「土壤之下」的機制，你就會以爲本身寫的程序有如空中樓閣，不得其中真諦——譬如，一樣能達到目的兩條語句哪一個機器執行的效率最高？哪樣的代碼組織會致使最終程序執行的崩潰？怎樣去避免代碼中的內存泄漏？——所謂知其然，不知其因此然也。因此，代碼要寫的明白，咱就得往下走，去了解底層。咱們能夠去看看 linux 對於進程的內存、CPU 管理機制是怎樣的，從而去優化咱們程序的性能；咱們能夠去看看數據庫的存儲引擎，從而在深入理解以後寫出更爲高效的 SQL 代碼，而且進一步對本身的數據庫進行設置、調優；咱們能夠去看看 JVM 是怎樣進行垃圾回收的，從而避免 java 中恐怖的隱性內存泄漏。樓主向下走，能夠去學習操做系統、計算機體系結構、編譯原理以及運行時等知識——你會在學習的過程當中對於本身曾經遇到的問題恍然大悟（我就經歷過好多回了，每次都高興不已哈哈）。

最後再提最重要的一點——不要把寫代碼自己做爲終極目標，而應該把代碼之上、之下的東西弄透。我想，這也是區別代碼工人和研發工程師的界限之一吧！

via 巴赫在編碼