程序員如何培養解決複雜問題的能力？

今天在上網時候，忽然看到了這篇文章，感受很是的適合如今的本身去思考下，可能也適用在座的讀者。程序員不只僅是敲代碼，更是一個複合能力的結合體，也不只僅停留在技術和代碼階段。你想要成長就得從新審視下「程序員」，看看本身的基礎是否牢固，萬丈高樓平地起，說的就是這個意思，聊天時候不少人說「程序員只要懂得多，不須要那麼深的。」其實這句話是錯的，好比說，disruptor底層是個什麼結構？爲何選這種結構？解決了什麼問題？什麼原理呢？你都知道嗎？只知其然，不知其因此然是不行的！看看本身如今項目中你能發現什麼問題，或者說能預料到什麼問題，有什麼解決方案，最優方案是如何定下來的？這一系列的問題都是進階「程序員」所必備的，死寫代碼是不行的。（非原做者所述）

程序員大體能夠分爲三類：碼農、工程師、高級工程師

• Level 1 - 碼農
  能作事，但缺少思考，Coding只是體力活。
• Level 2 - 工程師
  不盲目，懂得思考與進步。
• Level 3 - 高級工程師
  不止有足夠的思考，還具有解決複雜問題的能力。

從碼農到工程師並不難，只要懂得不盲從、主動思考、學習、改善就能夠很容易進入工程師的行列，可是大多數就止步於工程師了，由於要從工程師成長到高級工程師，須要解決複雜問題的能力。

什麼是複雜問題

首先明確一點：
解決問題 ≠ 解決複雜問題

問題 = problem
複雜問題 = ( complex + complication ) problem

complex，說明問題是複合的，是多個領域複合在一塊兒組成的問題
能夠是技術上的複合，好比
數據結構 + 操做系統原理 + 網絡 + 分佈式 => 分佈式數據庫問題
也能夠是非純技術的複合，好比
產品思惟 + 溝通能力 + 架構能力 + 代碼能力 => 將業務需求落地

complication，說明問題是複雜的，須要系統性思惟、嚴謹的問題分析能力，抽絲剝繭才能找到問題的根源並解決。

如何具有解決複雜問題的能力

引用曾經高級Node.js，現在的初級Ruby/Rust/Go工程師兼SRE對我說過的一句話：

將來最值錢的技能，第一個就是「解決複雜問題的能力」，
技能表上是沒有 Node.js，沒有Go，沒有MySQL，沒有Web開發的。
解決複雜問題的能力須要你有系統性思惟，嚴謹的分析問題能力，溝通能力和組織管理能力。

技術變化得太快，每段時間都會有新的技術、新的工具出現，大多數程序員都以爲疲於應付，每當有新的技術出現，大多數程序員的學習路徑是這樣的：

看「Quick Start」/ 實操教程 => 跟着操做 => 好像會用了

遇到問題後殊不知道緣由在哪裏，如何解決，開始Google，而後一個個解決方案地嘗試，嘗試到第 Math.random().toInteger() 種的時候，終於解決問題，而後以爲本身真牛逼，又解決了一個問題。
解決問題的路徑是：

搜索解決方案 => 從裏面看到別人分析的緣由 => 本身不必定看懂了分析，可是先用這個方案試試再說 => 薛定諤的解決

其實這樣並無真的解決問題，由於他不知道緣由在哪裏，爲何採用這個方案，是否有其餘方案，每一個方案的優劣在哪裏，下次再出現緣由相似，但表現不一樣的問題，他就又不懂得該如何解決，甚至也一樣找不到緣由在哪裏。
解決問題的步驟應該是：

分析問題 => 猜測 => 驗證猜測 => 找到緣由 => 構建解決方案 => 驗證解決方案 => 解決

這纔是一條完整的「解決問題」的路徑。

不少人在第一步就失敗了：分析問題，一頭霧水不知道從哪裏下手。

要分析和解決問題首先要求你有足夠的前置知識，對這個問題所涉及到的原理有足夠的瞭解，分析問題是知識的反推，解決問題是知識的順推。
只要提高相關知識的掌握程度，分析與解決問題的能力就能明顯提升。

1. 基礎知識很重要（深）

咱們所使用的任何一門技術，都有一個漏斗狀的知識體系，這門技術在漏斗最上層，而它基於它下層的全部基礎知識構建，每一層都是基於下層構建，好比MySQL:

 

漏斗狀知識體系

先問一個問題，數據庫一個表中，頻繁一塊兒讀取的數據，該怎麼存，讀取速度比較快？
你可能說得出，要把它們主鍵相鄰存在一塊兒，可是你可能不知道，爲何要把它們主鍵相鄰存在一塊兒。
由於主鍵相鄰存在一塊兒的數據會被寫到連續的頁（Page）中，相對連續的頁，數據庫會在磁盤上儘可能分配連續、鄰近的空間，能夠將隨機讀變成順序讀，而且經過系統調用read(start, length)每次讀出一頁，每頁中包括儘可能多的結果，那麼須要讀取的總頁數也會下降。若是不存在一塊兒，那麼隨機讀使得硬盤沒法進行預讀優化，若是是機械硬盤還須要增長額外的尋道時間，且須要讀取的總頁數也增長。
數據庫的一個小常識，居然涉及到了硬件、操做系統、數據庫原理，你覺得常識就是常識，可是其實這個常識也是被推論出來的，不懂得底層的知識，常識只能靠死記硬背，遇到更復雜的問題，就不知道如何分析了，由於分析是層層遞進的，若是你只懂一層，不懂下面的層次，就無法深刻。
程序員不學基礎知識就像作醫生不學解剖，不是須要上手術檯的醫生才須要學習解剖，瞭解人體的基本構造、各個生理組織間的協做關係是分析問題的基礎要求，不瞭解這些基礎，根本沒法進行精確的診斷。

 

因爲每一個技術的知識體系都是漏斗狀，因此大量的頂層技術、工具都依賴着少許的、同質化的基礎知識，只要學習有限的基礎知識，就能對大量的頂層技術舉一反三、觸類旁通，能夠下降將來的學習成本與學習難度以及加深理解的深度。

2. 如何學習基礎知識（由廣及深）

學東西，結合應用場景很重要。重要的話說三遍，結合應用場景，結合應用場景，結合應用場景。
相對於基礎知識，現成的一些頂層技術、工具更容易讓咱們有興趣去學習，緣由就是頂層的技術可以立刻被咱們結合到相應的應用場景：
學Node.js，咱們知道它是能夠作服務端編程的，30分鐘讓咱們搭出一個服務器。
學MySQL，咱們知道它是作數據存儲的，幾個SQL就知足應用的數據持久化。
學k8s，咱們知道它是作容器編排的，可以讓咱們簡單地部署應用集羣。

可是學基礎知識，就沒法結合相應的應用場景：
學計算機組成原理，我又不去裝電腦，它對於我有什麼幫助？
學操做系統原理，我又不去開發操做系統，也不作什麼基礎開發，它對於我有什麼幫助？
學數據結構，我又不是搞算法，它對於我有什麼幫助？

這樣一想，基礎知識真的沒有學習的動力…

因此咱們應該先挑一門本身想要了解的頂層技術，先經過優秀的資料瞭解這個技術，把本身能學懂的先學懂，不懂的能夠僅僅瀏覽，有個印象，知道哪裏不懂，知道本身學不懂是由於對什麼問題不瞭解。
而後總結這些本身不懂的點，是涉及到了哪些本身不瞭解的前置知識，因此學不懂。咱們每次可能只能往下推一層，好比學習MySQL時，只能總結出本身遺漏的前置知識是數據庫原理，而很難知道本身還應該補充操做系統的知識，這是很正常的，學習也是層層遞進，越挖越深。當咱們開始學習數據庫原理的時候，又會在數據庫原理學習的過程當中發現本身有遺漏的前置知識，好比操做系統。這樣學下來，不只不會浪費時間學習無用的知識，且每一個基礎知識都是帶着問題去學，帶着問題往下挖，學到對應基礎知識的時候，都能立刻與上一層的應用場景相結合，更容易理解。

尋找優秀資料 => 能學懂的就學懂，不能學懂的瀏覽便可，記住本身迷惑的點 => 根據本身迷惑的點思考是缺乏哪些前置知識 => 進入下一個循環（尋找前置知識的優秀資料）

3. 實踐

由廣及深學習了相關基礎知識後，應該只是到了理解的地步，還不算是吸取。
紙上得來終覺淺，絕知此事要躬行。
只有將理論上的理解實踐起來，試一試才知道本身的想法是否正確，在現實系統各類複雜的狀況下，如何將理論與實踐結合。
第一步能夠是本身試，隨便搭一個環境嘗試，可是這種狀況有限制，就是這是「假」環境，過於簡單了，也缺乏真實數據填充與真實應用場景檢驗。
現實工做中所面臨的問題會更加複雜也會更加豐富，能更快吸取一個知識，因此更好的方式是找到可以運用本身所學的平臺，進入一家團隊精煉、業務量大、而且發展速度快、重視技術的公司。

4. 表達與溝通

一我的的既有知識、技能、信息量都很是有限，工做中咱們都是與他人配合才能作好一個業務。
項目前期須要與產品經理、業務部門討論需求、理解需求，
項目中期須要與同事合做分工，若是是涉及多個系統的業務，還須要與其餘技術團隊的同事溝通技術實現，
項目後期須要與SRE團隊協做部署上線。
其中涉及到人與人之間互相的信息傳達，若是不能精確或者恰當地表達，對方可能沒法理解咱們的真實意思，致使無效或者失真的溝通，下降工做效率甚至沒法得到預期結果。
因此鍛鍊本身的表達與溝通能力，也是在間接提高工做效率，而且可以使團隊運做更順利，使得同一件事有更優的工做結果。
寫博客是鍛鍊表達能力的有效途徑之一，將本身學會的東西、思考的東西以講述給他人的角度寫出來，思考怎麼讓讀者理解本身要表達的意思，甚至思考怎麼讓讀者更簡單地理解本身要表達的意思。剛開始寫博客可能不知道如何下筆，不知道剛怎麼分配章節更合理，不知道怎麼組織文章的邏輯使它更簡潔、精煉、易懂，一篇博客可能要花上十幾天才能完成，可是堅持寫技術博客，會發現本身組織語言的能力也在提高，每過一年，再回頭看之前的博客，會想：「我去，這居然是我寫的？這麼爛？」，壞消息是，之前寫的博客確實挺爛的，但好消息是，你如今必定進步了，因此看出了它有多爛。
讀書時學渣一枚，個人做文能力也是很是很是差，逼着本身堅持寫一些技術博客，不止是總結所學的東西，更是提高本身的表達能力。
本身學明白一個東西是最簡單的，但怎麼表達出來讓別人也聽懂，是很是很是難的，寫博客是一件雖然困難但有收穫還有成就感的事，值得堅持，等到寫博客對我來講變得簡單的那天，我必定很牛逼了。

5. 健身

有句古話：磨刀不誤砍柴工。
還有句比較新的話：堅持作不緊急但重要的事。
深覺得然。
當你在技能、思惟等全部軟件層面都成爲高級工程師的時候，還須要讓你的硬件跟上步伐。
「解決複雜問題的能力」就是說不止得有「能」，還得有「力」，身體健康很是重要，這不止是爲了讓本身過得開心，對本身的家人負責，更是讓本身有精力和身體資本去應對各類壓力。
保持每2 ~ 3天健身一次，每次1 ~ 1.5小時，堅持下去，就能保證本身在將來20年都有充足的精力和健康的身體去學習、工做、應對壓力。
雖然健身暫時會佔用你一些時間，可是它可讓你長跑下去，若是不健身，也許你每週能夠多用幾個小時工做、學習，可是這只是短期的衝刺，衝刺的人能跑的距離仍是不如長跑的人，人生幾十年，是長跑不是衝刺。

寫在最後

世界上有四類事，咱們放眼整我的生來看一看：

1. 重要且緊急：天天分內的工做、生存、生病了看醫生
2. 重要但不緊急：學習、健身，每一件長期堅持可讓將來變得更好的事
3. 緊急但不重要：購買生活用品、食品
4. 不緊急也不重要：刷淘寶、刷劇、睡懶覺

 

                            時間四象限法則

大多數人都只作了一、三、4，不多去作2，首先他們可能不清楚什麼是重要但不緊急的事，其次是由於他們很難堅持長期作重要但不緊急的事。
若是沒法堅持作重要但不緊急的事，生活中就有出現各類緊急的事讓你焦頭爛額，好比不堅持健身，就容易生病須要請假看醫生也沒有精力作其餘事，因爲缺乏精力，又會使得工做能力降低收入下降生活質量下降。
堅持作重要但不緊急的事，會讓將來穩步上升，只着眼於重要且緊急的事，那生活中只會有愈來愈多重要且緊急的事須要你處理。應該用長遠、發展的眼光去規劃本身每段時間須要作的事。

磨刀不誤砍柴工，很是有道理。

感謝這篇文章點醒本身，感謝原做者！