【51CTO.com原創稿件】不久前，在團隊內部和大家做了一次分享，內容就是“用認知和人性來提升自己的技術水平”，大家反響不錯，所以整理出來分享給大家。
最初我是想用“借優秀的產品經理思維來做最棒程序員”的這個標題，但想想還是要有同理心，技術同學平時和產品同學已經是相愛相殺了，就不刺激大家啦。
但是必須要說的是優秀的產品經理思維和優秀的程序員思維確實是殊途同歸的，兩者是相通的，就是來自認知和人性。
這裡我不會過多去梳理認知和人性的概念，後面會用很多例子來說明，保證通俗易懂，只想先提兩個概念：
- 對人性的理解能幫助提升認知。
- 狹義的技術是指 Java、PHP、Android、Spring、Vue 等的掌握和實踐，它們只是幫助你提升認知的工具，卻絕不等同於認知。
下面我來逐一舉例說明。
例子 1：技術選型
問題：今年開始慢慢火的一個移動端跨平臺技術是 Google 發佈的"Flutter"，如果你作為一名移動端的開發人員來評估這門技術是否值得選型作為公司產品的語言框架，你怎麼能保證評估不會看走眼?
認知：Flutter 強化了跨平臺的生產效率，且性能比前端框架更好。
解釋：很多同學會想，怎麼第一句感覺就像廢話一樣，人家官方文檔也是這麼寫的，這叫什麼認知。
別急，所謂的認知，就是能夠提煉成外人看上去貌似一句很普通的話，但只有經過深度思考的你才知道它真正的價值。
在 Flutter 沒有出現前，我存在一個認知偏差，我認為客戶端一定會被前端諸如 React，Vue 這樣的技術取代。因為它們既可以跨平臺，也可以隨時更新，符合互聯網快速變化的節奏。
但我的認知存在一個非常嚴重的漏洞，那就是跨平臺和隨時更新在客戶端技術裡的佔比各應該是多少?哪個更重要?
經過分析思考，以我們公司當前用戶量的發展階段，提升跨平臺的生產效率且不損失太多性能更重要，所謂的運營快速需求變化有時候可以通過事先想清楚，而降低頻率。
Flutter 帶來的生產效率提升，不僅僅是一個開發可以同時產出 Android 和 iOS 兩端應用。
更在於產品經理以後只需要和一個開發溝通需求細節，不會再擔心出現 Android 和 iOS 功能細節實現偏差的問題了。
由於有了這樣的認知，雖然 Flutter 作為新技術，還有需要完善的地方。但這不是主要問題，我們願意為它去冒險，在我們的產品裡去儘快實踐。
人性：最後多說一句，為什麼 Google 先做了 Kotlin 後又做了 Flutter 呢?
我的認知是：大公司兩個部門做重複輪子很正常，互相競爭，看誰更好。
一個想試探性取代 Java 以避免被 Oracle 捏住命脈(如果接受的人多，將來把底層的 JVM 再抽掉)，一個野心更大希望統一所有平臺，不同部門的想法而已。
大家不要把 Google 的佈局想得那麼純粹技術化，大家都是人嘛。人脫離不了：競爭，征服，自保的人性。
例子 2：查線上問題
問題：覺得查線上問題很痛苦，壓力很大，查得也不快怎麼辦?
認知：①查線上問題是成本最小的，鍛鍊邏輯思維的方式，相比寫代碼更有效率。 ②查問題要看本質，抓住案發第一現場。
解釋：很多同學碰到線上問題的時候，都很痛苦，因為要加班了耽誤我學習技術的時間，所以有時查問題態度也不積極。
這個認知是非常錯誤的，大家平時都會認可優秀程序員的核心特質看的是思維邏輯，而不是用哪個語言哪個技術。那如果是思維邏輯優先，寫代碼就能比查線上問題更能提升嗎?
顯然不是，大家知道我們在寫代碼時，往往要花費很多時間在編寫冗餘代碼(如 get、set 代碼，配置文件)，普通的 crud 邏輯，編譯，部署等這些非核心點上，它們並不能幫助我們提升思維(動手寫代碼前的思考才是最核心的)。
但是查線上問題就不一樣了，你不需要寫任何代碼，但是需要在很短時間內，讓自己理清思路，按正確的步驟去查出代碼的核心問題，底層系統的核心問題。
你需要對系統很瞭解，對業務邏輯很瞭解，對代碼細節很瞭解，這真是一個幾乎沒有任何冗餘步驟，但是卻能快速提升嚴謹思維的好方式! 怎麼讓查問題更有效率?
其實很簡單，我們如果借鑑名偵探柯南的想法，那就是“抓住案發第一現場”。
舉兩個例子，對於 Java 這樣的靜態語言，查詢線上日誌的方法是非常重要的。很多同學發現某個請求出問題了，就去看當次請求的日誌，這種方式不一定準確。
因為對於靜態語言，它的案發第一現場可能已經不是當次請求了，很有可能是首次發生這個問題的時候，或者服務器剛剛啟動的時候(靜態語言的”緩存”特色)。
當你發現上層的業務系統發生了 MySQL 死鎖的報錯，就不要太糾結於上層業務系統的日誌了。應該去看 MySQL 的 Binlog，抓住這個案發第一現場，看看到底發生了什麼。
不知道怎麼解決線上問題，99% 是因為連案發第一現場都沒找到，等你找到了，基本也有解決方法了。
人性：每個人都喜歡做省力的事情，喜歡的事情。但是人往往有偏見，根本沒有想明白查線上問題的價值，就認為這是一個很 Low 的事，是不可取的。對自己不瞭解的，未知的事物，應該敬畏和學習。
例子 3：技術面試
問題：很多同學的技術經驗已經很紮實了，也能寫出很穩定的代碼，但是作為技術面試官，為什麼老是會看走眼呢?
認知：對應聘者而言，能否獨立解決問題是能通過面試的及格線，應聘者專業技術的掌握程度只決定 Offer 薪資的高低。
解釋：是不是覺得又來歪論啦?嗯，繼續解釋一番。首先問你，你為什麼要招人，我相信很多人都會這麼說：當然是找你來幫我幹活啊，我現在天天干到 11 點，累死了，急需人幫忙啊。
恩，所以你很清楚，這個人是要能獨立解決問題的，能幫你分擔的，不是來了還要你天天在那裡盯著的。
但是我們看到很多同學的內心認知是混亂的，雖然他能看懂這句話，但是在面試的時候他會這麼做：準備 10 個左右他擅長的技術細節問題，一個個問，應聘者只能答出 5 個，廢柴，不送。
答出 7 個，嗯，可以進來。答出 10 個，還說了 1 個我不知道的，好牛逼，絕不能讓他看出來我比他弱，否則進來後還怎麼帶他。
但是這個和你之前痛恨的應試教育又有什麼區別呢?這種招聘方式有很大的風險，招進來的人是研究手機屏幕從幾樓摔下去不會碎，而不是研究讓屏幕顯示更清晰的人。
正確的方式應該是：讓他講一個之前投入度比較高的項目，描述下自己是怎麼獨立去解決問題的。
對每一個點的描述，只要你覺得還不能體現他“獨立解決問題”的能力，那就繼續扒皮深問，直到他竭盡全力，被你”逼到牆角”。
特別優秀的人被逼到牆角後，具備現場把牆砸掉的能力，這樣的人是死也不能放過的，具體什麼意思大家可以去體會思考。
之前我們曾經面試過一個性能測試工程師，從技術細節看對性能測試的工具和方法是比較瞭解的。
在項目描述中我們問了他一個問題：你之前通過性能壓測發現的服務端問題，有去了解過發生的原因嗎?
他給的答覆是：因為我們是外企，制度比較明確，開發也是另外一個部門，所以我沒有去了解。
不好意思，這個回答基本體現了沒有獨立解決問題的能力乃至意識。碰到一堵很小的牆，他都沒有辦法獨立解決，好奇和學習的慾望也很弱。
他在技術細節上的積累只是因為看了幾本書，用了幾次工具，這些都只是為了應付面試和不懂的領導，根本沒有深入實踐，他未來的瓶頸一定非常大。
只要能夠獨立解決問題，就一定能通過面試，有些技術不瞭解，最多就是被砍點薪資而已。
在這一點上，10 年工作經驗的同學還真未必比得上 2-3 年工作經驗的同學，如果沒有獨立解決問題的能力，那只是多累積了一些所謂的專業經驗，但還是無法解決問題。
很多大公司喜歡校招優秀的畢業生，也是這個原因，雖然這些學生還沒有實際工作過，但已經具備了很強的獨立解決問題能力。
我們曾經招過一名同濟大學的測試實習生，有一次她獨立組織了部門的團建活動，搞得井井有條，方方面面都考慮到了，這樣的同學做好技術只是時間問題。:)
人性：應聘者的人性有哪些呢?懶：影響獨立解決問題的意識。要面子：比如剛剛舉的例子，拿公司制度掩蓋自己無法獨立解決問題的現狀。(並且他自己是意識不到的，因為他內心的認知是混亂的) 盲目自信又不自信：對自己做的熟的東西盲目自信，對沒接觸過的技術很不自信。
例子 4：最嚴重的線上故障
問題：到底是什麼原因，會導致嚴重的線上故障呢?是我們團隊的技術水平不高，還是流程問題才造成了如此嚴重的故障呢?
認知：個體的過失很難造成嚴重的線上故障。真正的原因是：集體性的認知出錯。
解釋：在現代微服務的架構下，各服務之間的解耦性已經做得非常好了，總體來說出現全面嚴重問題的概率已經降得非常多了。就像一個國家一樣，不怕局部的腐敗，怕的是整個鏈條的腐敗。
舉個例子，如果一個系統上線前，需要在數據庫裡配置一個關鍵的參數，如果不配置會導致很多請求處理錯誤。
但是開發同學發生了錯誤的認知，潛意識裡認為配置不是寫代碼=配置沒有寫代碼技術含量高=配置沒有寫代碼重要，最後把它忘了。
測試同學認為測試配置不是測試新寫的代碼=優先測試新寫的代碼，再測試配置=測試代碼比測試配置更重要，最後把它也忘了。
那這基本上是救不回來了，上線後一定會發生嚴重的問題，每個鏈條的檢查機制都失靈了。堅決預防集體性的認知出錯，就可以避免很多嚴重的問題。
集體性的認知出錯往往是從一些小現象開始的，比如我們的團隊曾經發生過一次正常的項目延期，原因是週五到了，沒有完成測試，為了避免倉促上線出問題，所以延期一天發佈。
其實到這裡都是非常正常的，但是當測試同學在釘釘群裡發出這個原因的時候，有一些同學發出了大拇指的表情。
注意，這個時候大家是沒有犯錯的，但是認知已經出現了偏差，變成了“以後就算測不完，只要說項目風險，就可以延期”。
群裡很多同學都看著，一旦這個集體性的認知偏差形成，未來項目的延期就會越來越多。
所以需要立刻出來說一句：因為風險項目暫時不上可以，但是延期的原因要總結反思。
通過這樣一句讓大家心裡不太舒服的話，儘快把集體性認知偏差扭轉過來。
馬雲說過”小事要大做”，就是這個道理，不大做，等發生大事的時候就來不及了。
人性：盲目自信：對自己做的領域有天然的偏見，哪個重要，哪個不重要。隨大流：別人也這麼做了，應該不會錯，還省力，我也這麼做。懶：默守所謂的安全方案，其實在那個場景下已經不安全了，但是內心認知出現偏差，懶得去破局改進。
例子 5：如何看待代碼邏輯複用
問題：對於代碼邏輯的複用，大家的看法往往不一樣，有些同學認為只要是有公共性的代碼都該不斷抽出通用函數複用。有些則認為對重要的通用邏輯才該複用，過度複用反而增加成本。
認知：能力該複用，業務不該複用。分久必合，合久必分。
解釋：這裡提出了兩個認知，我們來分別解釋下。能力該複用，業務不該複用，這個很好理解。
能力是指對這個系統有價值的功能，會長期存在且擴展下去的。而業務是一個泛指，既可以表示單一的產品需求，也可以表示某個局部的功能。
比如你的應用裡接入了一個支付寶支付，對支付這個事情我們判斷下來是一個基礎核心能力，且將來很有可能也要接入微信支付，所以應該抽出公共的函數。
再比如對於客戶端的登錄頁面和註冊頁面，雖然渲染邏輯 90% 是一樣的，但是不應該複用，因為它們是單一功能，不是能力，貿然複用反而帶來了很大的風險。
分久必合，合久必分，這個的理解就很有意思了。大家都知道，這句話的出處來自三國演義，說的是一個國家分裂久了就會合並，合併久了也會分裂，其實對代碼邏輯的複用也是如此。
大家在合併抽出公共函數時，會發現有 10%-20% 的邏輯不是那麼順眼，總感覺暫時放在裡面是可以的，但將來可能會拆出來。
那麼在寫公共函數時，就要特別注意這部分邏輯。它雖然暫時在函數里，但是需要做到和上下文相對隔離，甚至還可以加入明顯的換行和 TO DO，為下一次的拆做好準備。
而在拆出一些獨立邏輯的時候，也要思考這些邏輯可能和其他的哪些邏輯有機會是合起來的，那麼儘量放在一個類裡，一個包裡，為後續的合做好準備。
人性：不要刻舟求劍，妄圖用一套規則來應對外部複雜變化的世界，要因地制宜，實事求是，學會變通。
例子 6：開源的意義
問題：為什麼現在很多中國的互聯網公司開始重視開源的宣傳了?
認知：開源直接決定了公司的成本收入，以及人才儲備。
解釋：是不是要崩潰了，開源無償寫代碼，然後免費給別人用，不是在消耗公司成本嗎?
別急，還記得馬雲說過的一句話嗎，“免費的才是最貴的”。嗯，這個道理同樣適用於開源。
今天中國很多的互聯網公司已經非常明白了，甭管你的開源技術到底好不好用，宣傳一定要大，一定要讓大家參與進來。帶來的好處太多了，因為用了你的開源消息隊列，之後就會用你的雲計算平臺。
因為程序員都很懶，開發環境和線上保持一套嘛，你後面一定能賺大錢。因為開源項目非常知名，讓你公司的技術形象立刻高大起來(先不管這個項目到底創造了多少有價值的產品)，每年校招的優質學生資源盡收囊中，其他公司要搶人，只能花更多的錢。
而每年中國優秀的畢業生就那麼多，早就供需失衡，誰搶到了大部分，那之後在技術上一定能保持絕對優勢。
最後萬一公司財報不好看了，不好意思開始收授權費，就像 Google 收 Android 的費用一樣。
不作惡只是口號，開源帶來了無比巨大的利益，不能賺錢，誰開源?!現在微軟也懂了這個道理，成為了開源社區的標杆，但在早期的鮑爾默時代可是出現了認知偏差呢。
人性：開源者的人性：追求利益，喜歡聲譽。 接受開源的人：渴望進步，賺便宜，崇拜權威。
提升認知的四個關鍵點
內心簡單
內心越簡單的人，將來能到達的境界就越高。大家千萬不要誤解了，我說的不是思想淺薄，而是內心簡單純粹要像少年一樣。
一個很好的例子，郭靖，用世俗的眼光來看他天資不高，開始學什麼都慢。但是他有一個很大的優點，就是想法簡單，無私心，持之以恆。
報家仇，報國仇，保護好他愛的人，不會去想是不是別人騙了他，他多做一點是不是虧了。
20 歲就達到五絕水平，最後終於融合“降龍十八掌”、“九陰真經”和“左右互搏”三大蓋世武功為一體，武林尊為“天下第一俠士”。
內心越簡單，就越不會花費額外的精力在一些無關緊要的事上面。隨著時間的推移，你的認知水平就一定能提升得更快。
不要去想今天你學的語言明天是否還流行，先利用當前語言訓練好你的思維模式。
不要去想我作為測試給開發指出太多問題後，開發會不會不爽，做為測試你的核心是保證產品質量。
不要去想今天我幫組內的開發分擔了額外的代碼編寫，我是不是虧了，這些付出一定會在將來某個時候兌現，因為你比他們有更多的代碼實踐。
相信跨界的力量
iPod+手機誕生了 iPhone，手機+錢包誕生了支付寶，C，Python+Java 誕生了 Go，人類的創新其實都是來自於跨界的結合。
很多時候大家去看一個技術大神，會認為他一定是看了很多專業的書，看了很多牛逼開源項目的代碼，寫了很多項目才達到現在的這個水平。
然後又看到別人的興趣愛好：音樂，滑雪，畫畫，牛逼，大神就是大神，做好技術的同時還能“兼顧”這些興趣。
這個認知完全錯了好嗎，我告訴你，寫代碼看書固然很重要，但如果他沒有這些興趣，他在技術上可能根本達不到今天的程度。
一個有畫畫功底的人，理解向量，理解數據的 PCA 分析就是快好嗎。一個財務出身的人，寫支付系統的代碼就是不容易出錯好嗎。
人類的大腦從來都是一個網狀的，互相關聯的知識圖譜，根本不存在靠”單一事物”修煉成功的好嗎。
千萬不要成為技術上的孔乙己，天天學各種 API 的寫法，和學習茴香豆的茴字有幾種寫法沒有任何區別。
在方案想不出來的時候，在代碼水平感覺到瓶頸的時候，在看不懂一些專業書籍的時候，一定要跳出來，和自己的興趣結合，和自己經歷結合，和自己的生活結合，這樣才能突破瓶頸，提升到更上一層的認知。
相信更高認知人的指引
科幻神作三體裡，外星人看地球人就像紙片一樣，在三體人的眼中，地球人是二維的，而不是三維的。
回到現實中，高認知的人看低認知的人也是一樣的，不是低認知的人不夠努力，而是你的知識圖譜裡比高認知的人少了一些維度。
所以不管你怎麼努力，你會發現仍舊無法超過他，他還比你輕鬆，學霸給大家留下的陰影就是這麼來的。
在實際工作中，你的 Leader，你的架構師只要不是水貨，往往他們的認知就是比你高的。
一旦你覺得這個人的本性是靠譜的，你就該無條件去相信他給你的建議和指引。
因為他能看到在你那個維度上感受不到的東西，照他的話去實踐幾次，你才有機會到達他那個維度，才能升級認知。
不過在現實情況中，我們往往看到很多 Leader 和架構給下面的同學苦口婆心說了很多，但是他們不理解，反而更叛逆。
這份痛苦我懂，你是拼了命想拉他到你那個維度，但是他還年輕著呢。
持之以恆地實踐
人就是一個如此奇妙，如此複雜的生物，不管你看多少書，看多少源碼，寫多少 Demo，你不真刀真槍地去實踐，去寫代碼，這些知識無論如何都無法進入你大腦的知識圖譜。
它們永遠只能是“狹義上的知識”，而不是“有價值的認知”。相信大家人生中都有過類似的經歷了，越是辛苦的實踐，越是堅持，你最後的收穫一定越大。
簡單來說，認知不通過持之以恆的實踐是不可能升級的。還有一點我必須要強調，實踐應該儘量和公司的項目去結合，而不是依靠於自己寫 Demo。
這裡面有一個很大的誤區，自己私下寫 Demo 經常是沒有“明確，高壓的”目標的(人性總是偏懶的)，這種實踐往往很難提升認知。
而公司的項目往往不同，會提出"支持多少用戶訪問"，“為什麼你每次開發都不能更快一點”(核心挑戰的是你架構的擴展能力)，“為什麼這個功能這麼卡”(性能優化)。
這些“明確的，高壓的”目標能督促你去拼命提升自己的認知(只是寫 Demo 是很難給自己設下這些障礙的，是反人性的)。
當然從結果來看，又是公司的壓榨剝削啦，讓我們回憶一下前面說的，如果你覺得這個公司是靠譜的，那就讓我們的“內心簡單一點”，持之以恆地實踐升級認知吧。
總結
最後總結一下，現在已經不是一個單純比拼知識量的時代，而是比拼認知高低的時代。
作為程序員我們並不特殊，和市場，財務，產品，運營的這些同學一樣，核心看的是認知，並不存在誰比誰困難，誰比誰辛苦的這種淺層比較。
而我們學習的那些語言，框架，工具，和我們大學時期學習的微積分，高等物理沒有區別，都只是幫助我們不斷訓練提升認知的實踐工具，而不是認知本身。
讓我們不要再侷限於程序員狹義技術的範疇內，把提升自己的認知作為最重要的目標，我們要努力做到“既是程序員，也不是程序員”。
閱讀更多 51CTO傳媒 的文章
