幾周前，微盟爆了個大雷，數據庫讓內部員工刪庫跑路……
很明顯，微盟的技術體系是有嚴重問題的， 主要體現在：運維權限管理、數據庫備份、上雲而不上雲方案，這三點。看起來有點聳人聽聞，其實你永遠不知道一個人或者一家公司的技術會低到什麼程度，不少人可能從來都沒用過GitHub和GitLab。
程序員這個行業，是一個區隔度特別高的行業。 不少人短短几年就可以成長爲高級工程師、資深架構師、首席架構師，而另外一部分人很可能工作10年還是初中級工程師。
程序員行業還有一個特點，優秀程序員的產出是普通程序員的好多倍，甚至是10倍！ 這是因爲編程不是一門「線性科學」，而是一門「非線性科學」。
「線性科學」，比如跑步的速度就是，世界冠軍的速度也不可能是普通人的10倍。「非線性科學」是指很多種因素交匯在一起，極大增加了系統的複雜度。
程序設計和實現不是一種線性能力，像經驗、編碼能力、工程能力、知識、學習新知識的能力、對無用部分的識別等這些就不僅僅是線性優勢，匯聚到一起會對編程產生倍增級效應。
優秀的程序員能達到百萬年薪，而入門級或者初中級程序員可能只能拿10萬年薪。輸出的10倍差距帶來的是收入上的10倍差距！
很多時候，遇見複雜系統問題，派多少個初中級工程師都於事無補，而一個資深架構師就可以輕鬆搞定。
過去11年的職場生涯，我帶過過百名程序員，見過非常優秀的也見過平庸的。以下是我認爲程序員和普通程序員拉開巨大差距的7個關鍵點：
裸編程能力
裸編程能力：處理程序實際實現部分的子任務，實現函數或者算法之類的能力。 聽起來很簡單對吧？實際上很多程序員缺失這樣的能力。
不知道大家有沒有見過「CV 工程師」，Review他們的代碼甚至會發現一些網上的註釋，又或者其他人的編寫錯誤。
並不是所有程序員都具備利用必備的基本編程結構有效的實現某個產品或者某個模塊。
不少工作多年的程序員甚至連一個簡單算法排序都沒有考慮，當然這並不影響普通工作的輸出，但在面臨調優或者攻堅，這類型的程序員的表現甚至比剛畢業的優秀程序員還要糟糕。
在工作中遇到過一次將代碼時間複雜度降低幾個數量級的情況， 在壓測模擬過萬人同時使用的情況下，沒優化前服務端程序直接卡死，優化後能流暢的運行。
在這個覆盤過程中，我發現實現這個功能的程序員缺乏基礎的算法基礎。for循環的嵌套，簡直是觸目驚心。
BAT大廠招聘高級工程師，爲什麼總是要求手寫各種算法，恐怕也是基於考察裸編程能力。
調試能力
調試能力某種程度上比編碼能力更重要。 查找和解決BUG會佔用程序員大量的時間。查找BUG產生的根源不是一件簡單的事情，需要整體的分析和經驗的沉澱，同時還需要對各種調試工具熟練應用。
不少程序員，解決完一個BUG卻導致了更多的隱患，沒有真正把BUG產生的原因找到，只治標不治本。
對於程序員來說，掌握在合理的步驟內修復BUG，以極簡的方式編寫較少BUG的代碼的能力，就能顯著提升效率。
另外在團隊中擔任骨幹的往往都是調試能力極強的程序員，在其他成員遇到困境之時，快速定位解決問題。
能否運用調試技能快速解決問題，是衡量一個程序員水平高低的重要標準。
追求簡約
代碼的註釋是否恰到好處、函數模塊和類的結構是否能讓其他人直接秒懂、架構的設計是否足夠清晰等等，都屬於程序員追求簡約的範疇。
有一種炫技程序員或者架構師，喜歡簡單事情往復雜了做。明明幾個類能搞定的，弄出很多中間類，明明三層架構就解決的問題，生生弄出五層。
簡約是成敗之間最爲明顯的分界點，事實上能做到簡約的人，恰恰是深度理解了系統的複雜性。就好比微信是一個極度簡約的產品，能做到這麼簡約恰恰是因爲張小龍深度理解了通信和社交產品的複雜度。
一個產品功能，有人用了500行實現，你寫了幾千行。多出來的代碼有價值嗎？不僅沒有價值，還會對未來接手代碼的人有很大的困擾。less is more，簡單就是美，這話說的真沒錯。
看看Google、Facebook等公司的源碼，找不到太多多餘的代碼和結構。無論是代碼層面、類層面還是架構層面，都做到了恰如其分、恰到好處。
不要多寫一行無用的代碼！
準確預測技術工期
老闆想了個idea授意產品經理估工期。產品經理原型都沒畫出來，只有個大概想法，就找技術排工期。
這個時候，技術的內心大概多了幾道菜式：清蒸產品經理、紅燒產品總監、油炸CTO。
其實準確預測技術工期是程序員一項非常重要的能力。 爲什麼這麼說？只有具備這項能力，才能讓開發工作遊刃有餘、可進可退。
事實上鍛鍊這種能力也並不困難，拿移動端開發來說，一個idea大概對應多少個頁面多少個邏輯類，是能夠估算出來的，以此爲基礎完全可以估出大概時間。更不用說產品文檔出來之後的預測，會更爲精準。
那麼預測技術工期的意義在哪呢？
首先在沒有出文檔之前的估計，可以作爲給老闆的重要判斷武器。做任何功能一定會投入研發力量，而往往研發力量是最寶貴的，如果在idea出來之後就能大概知道工期，對於做什麼不做什麼的判斷，意義重大。
產品文檔出來之後的精確工期呢？對控制風險和進度把控非常有幫助，這個時候的精確排期其實對風險點的估計、資源協調的能力都有很高要求。準確預測的過程其實就是風險預判的過程。
理解底層系統原理
處理複雜任務或解決複雜BUG時，具備深厚的底層系統知識非常重要。 比如數據結構、網絡協議、操作系統相關知識，等等。程序的很多問題都是源於對計算機工作原理的誤解，即使是使用高級語言開發的程序也一樣。另外，一些更偏應用層的架構或框架，基礎一定是更底層的系統。
瞭解了底層原理，我們才能看穿眼花繚亂的技術背後的東西，不被層出不窮的新技術所累。
比如Docker技術興起，改變了CI/CD的方式，推動了雲原生技術的發展。那麼Docker到底是什麼東西呢，其底層無外乎：CGroups進行資源限制、Namespace對進程視圖修改、rootfs爲容器進程提供隔離後執行環境的文件系統。
瞭解了Docker的底層原理，才能在實際工作中更好的駕馭Docker。
再舉個應用場景的例子 ：一提到分佈式鎖問題，大多數同學想到的方案是基於Redis的Master-Slave模式來實現。這個實現方案行不行？分佈式鎖本質是一個CP需求，基於Redis的實現是一個AP需求，乍一看基於Redis的實現是無法滿足的。
脫離業務場景來談架構都是耍流氓。 從技術戰略的需求層面來看，如果分佈式鎖在極端情況下獲取鎖的不一致，社交業務場景能夠接受，那麼基於Redis的實現是完全可行的。
如果業務是交易場景，分佈式鎖在極端情況下獲取鎖的不一致性無法接受， 那麼基於Redis的實現方案是不可行的。在鎖強一致性的場景下，需要採取基於CP模型的etcd等方案來實現。
做出以上判斷，需要深度理解底層系統原理。缺乏了這種理解，無法做出正確的架構抉擇，也自然會對工作造成不利影響。
嚴格把控關鍵設計
無論是大的系統還是小的模塊，一定都有最關鍵的功能。要在最關鍵功能上投入大量設計時間，才能規避開發過程中的各種坑。
程序員非常不情願看到的一種情況是，需要在一些無關緊要的功能上浪費大量的時間，但你又不得不去將這個無關緊要的功能實現，因爲它牽扯着這個項目的主要功能。
這種時候，就需要反思，在頂層設計的時候是否考慮周全。 詳細而縝密的頂層設計能夠減少上述情況的發生，降低模塊間的耦合性。
必須意識到每一個細小的模塊都有可能成爲項目的瓶頸。 對於項目而言，最終的目標是合理的時間做最大的產出，實施重點就應該放在項目最主要的模塊上。
拿設計IM功能來說，一個IM系統最重要的核心模塊，一定是通信部分。 將通信部分的各種設計搞定，其他錦上添花的方面都可以後續慢慢補充，例如客戶端交互、好友關係等等。
拒絕完美主義
完美主義包含兩種情況，一種是追求極致性能的工程師文化、還有一種是個人性格使然。 無論哪一種，過分追求完美都會對業務交付產生影響。
完美主義會影響程序員的心態，過於擔心外部評價或過於追求內心的安全，反而會導致設計上的過度和偏差。
程序員真正產生價值一定需要和業務結合，業務交付的及時性、健壯性、簡潔性、可持續性一定是首先需要考量的事情。一定不能出現偏袒設計而犧牲生產力的情況。
不少創業公司上來就談中臺戰略，並花大量研發力量去實踐，最終中臺沒做好基礎的業務保障也出問題了。 在我看來，這也是追求完美主義的一種體現，誠然有一個類似阿里那樣的能給各業務線賦能的中臺是一個美好的願望，但很多時候連業務方向都要多變，追求這種賦能無異於空中樓閣。
前幾天我的讀者羣又有創業者在談AI中臺，我只想說既然是創業，咱能不能先MVP？等業務用戶量更大了，再來追求更漂亮的實現？
最後的話
以上關於優秀程序員的7個能力，就說完了。 其實還有一些通用的能力，比如高效學習能力、耐力、注意力等等，這些也是拉開程序員之間差距的重要因素。
今天還有個感悟：世界上的事情分兩種，一種是有邊界確定性強的事情：比如運動就會瘦、早起早睡會更健康、勤奮努力會具備架構思維。
另一種是無邊界不確定的事情：比如練就6塊腹肌、長壽100歲、成爲首席架構師。如果我們連有邊界確定性強的事情都搞不定還懊悔，那不要懊悔了，是因爲我們壓根沒有真正渴望。
2020年，希望我身邊的每個有足夠渴望的程序員都能成爲優秀的程序員
爲了幫助大家提升進階，3個月實現技能快速突破！我分享一份由幾位大佬自己收錄整理的 Android學習PDF+架構視頻+面試文檔+源碼筆記 ，還有高級架構技術進階腦圖、Android開發面試專題資料，高級進階架構資料供大家學習進階
這些都是我閒暇還會反覆翻閱的精品資料。在腦圖中，每個知識專題都配有詳細的知識點，還有相對應的實戰項目，可以有效的幫助大家掌握知識、理解原理。當然你也可以拿去查漏補缺，提升自身的競爭力。
如果你有需要的話，可以加Vx：15388039515（備註CSDN，需要進階資料）
喜歡本文的話，不妨給我點個小贊、評論區留言或者轉發支持一下唄~
