程序员如何跨越35岁危机？这篇给点干货建议！
職場&認知洞察?丨 作者?/?findyi
這是findyi公眾號的第83篇原創文章
這兩天在我的讀者群里做了一個職業小調研，發現關注我公眾號的70%以上都是程序員。
畢竟程序員吸引程序員，這也算猿糞吧，哈哈。
這個小調研也引發大家對程序員行業的激烈探討，一個讀者丟出了一張圖，是大劉老師發的一段話：
不得不佩服大劉老師的洞察力和敏銳，不干這一行居然對我們這么了解！
突然瑟瑟發抖....
前文其實也寫過一篇給碼農后浪的六點建議，也提到程序員不是老中醫，極容易被淘汰替代。
沒辦法，這的確是殘酷的現實。
事實上，我們不用去抱怨也不用去郁悶。
我們更應該思考：如何盡可能的延長我們的程序員生涯。
另外一個事實是：優秀的程序員，從來不擔心因為年齡大而被淘汰。
我身邊有好幾個45+還奮斗在架構一線的老哥，干的生龍活虎。
年齡增長的同時，競爭力和薪資依然同步增長！
今天我想跟大家聊聊優秀程序員必須掌握的那些知識。
—?1?—
程序員必讀書單
除了工作實踐，我們要精進技術，一定要多讀技術書籍。
為了給大家推薦這份書單，我先后問了10多個技術大牛，要求他們只推一本覺得最牛逼的。
這些大佬包括阿里P9、百度T9、58技術總監、前58技術委員會主席等等。
結合我自己過去看過的技術書，挑出10本：
《代碼大全》?
雖然這本書有點年頭了，且厚到可以墊顯示器。
但是這絕對是一本經典的書。
《程序員修練之道》?
這本書也是相當經典，我覺得就是程序員的指路明燈。
《代碼整潔之道》
細節之處的高效，整潔成就卓越代碼。
《計算機的構造和解釋》?
經典中的經典，必讀。
《算法導論》?
美國的本科生教材，這本書應該也是中國計算機學生的教材。
《設計模式》?
這本書是面向對象設計的經典書籍，掌握設計模式是讓你的代碼做到「高內聚、低耦合」的第一步。
《重構：改善既有代碼的設計》
代碼壞味道和相應代碼的最佳實踐。
《人月神話》?
軟件開發這個行業能不能堆人數？怎么做好項目管理？如何敏捷迭代？
看完這本書，都會有答案，它適合任何軟件開發行業的從業人員閱讀。
《深入理解計算機系統》
這本書以程序員的視角全面講解了計算機系統，深入淺出地介紹了處理器、編譯器、操作系統和網絡環境。
《C程序設計語言》
無論是做不做C/C++，這本書都值得推薦！
C語言是除了匯編之外，最能讓你洞察計算機體系知識、計算機系統運行原理的語言。
—?2?—
一些硬核技能
程序員行業新技術發展迅猛，可以說是日新月異。
也正是這個原因，中年危機成為我們必須面對和攻克的問題。
思考一個問題：那些能工作到45、50、甚至60的程序員們，究竟具備了哪些過人的能力？
就我過去的經歷和觀察來說，我認為：他們掌握了一些硬核技能。
這些硬核技能幫助他們克服了年齡帶來的劣勢。
1.算法能力
很多程序員朋友覺得：如果我不從事算法相關工作。
算法可能對我沒有價值。
雖然大多數程序員可能在工作中用不到算法，但這一點都不妨礙算法的重要性。
培養算法能力，就是訓練了我們的編碼能力、解構能力和超強的邏輯能力。
我一直認為編程的本質其實類似解數學題，那么算法就是最難的數學題。
碼皇MIT教授Erik Demaine的建議更為直接：
If you want to become a good programmer, you can spend 10 years programming, or spend 2 years programming and learning algorithms.如果你想成為一個碼農或是熟練工（Code Monkey），你大可以不學算法，因為算法對你確實沒有用。
但如果你想成為一個優秀的開發者（Developer），扎實的算法必不可少，因為你會不斷的掉進一些只能借助算法才能爬出去的坑里。
2.裸編程能力
什么是裸編程能力？
處理程序實際實現部分的子任務，實現函數或者算法之類的能力。
聽起來很簡單對吧？實際上很多程序員缺失這樣的能力。
不知道大家有沒有見過「復制粘貼工程師」，Review他們的代碼甚至會發現一些網上的注釋，又或者其他人的編寫錯誤。
并不是所有程序員都具備利用必備的基本編程結構有效的實現某個產品或者某個模塊。
不少工作多年的程序員甚至連一個簡單算法排序都沒有考慮，當然這并不影響普通工作的輸出。
充當代碼世界的搬運工，如同搬磚工人一般，完全可以在職業生涯初期求得茍存。
但在面臨調優或者攻堅，這類型的程序員的表現甚至比剛畢業的優秀程序員還要糟糕。
當他們步入中年，當他們承擔越來越復雜的任務之際，無力感會與日俱增。
3.Debug能力
調試能力某種程度上比編碼能力更重要。
在工作中，編碼只占據了我們一部分時間，查找和解決BUG會占用更多時間。
查找BUG產生的根源不是一件簡單的事情。
需要整體的分析和經驗的沉淀，同時還需要對各種調試工具熟練應用。
團隊的架構師除了架構設計，最重要的工作就是去解決那些其他人解決不了的BUG。
4.底層系統知識
處理復雜任務或解決復雜BUG時，具備深厚的底層系統知識非常重要。
比如數據結構、網絡協議、操作系統相關知識，等等。
程序的很多問題都是源于對計算機工作原理的誤解。
即使是使用高級語言開發的程序也一樣。
另外，一些更偏應用層的架構或框架，基礎一定是更底層的系統。
了解了底層原理，我們才能看穿眼花繚亂的技術背后的東西，不被層出不窮的新技術所累。
比如Docker技術興起，改變了CI/CD的方式，推動了云原生技術的發展。
那么Docker到底是什么東西呢，其底層無外乎：CGroups進行資源限制、Namespace對進程視圖修改、rootfs為容器進程提供隔離后執行環境的文件系統。
了解了Docker的底層原理，才能在實際工作中更好的駕馭Docker。
以上四點，作為程序員，需要深耕取得突破。
大家可能會注意到，我并沒有推薦任何一門語言作為基礎能力。
對于真正的程序員大牛，語言只是工具，并不是本質。
這些大?？梢院茌p松的熟練使用多種語言來實現業務目標。
—?3?—
領略代碼之美
你如何看待編碼這件事？
是把它當作一份簡單重復的工作，還是像打造藝術品一樣精雕細琢？
這個問題的答案恐怕決定了你是否能成為一名優秀的程序員。
代碼世界充滿了美輪美奐的風景，充滿了領略美麗之后的喜悅。
如果不具備找到代碼之美的能力，恐怕并不適合這個行業。
下面說說有哪些代碼之美：
一.優美的代碼
可讀性高的代碼才有可能是優美的代碼。
相信大家都有過這樣的經歷：接手一個項目要修復bug或者開發新功能，發現代碼可讀性非常差。
哪怕是在有說明文檔的情況下，都不太敢提交代碼，唯恐引入新的bug或者直接導致系統崩潰
《重構》里有這么一段話：“任何一個傻瓜都能寫出計算機可以理解的代碼。唯有寫出人類容易理解的代碼，才是優秀的程序員。“
那么如何寫出可讀性高的代碼呢？
有如下建議：
1.不要寫過長函數
可讀性差的代碼有很多特征，其中最典型的就是存在大量過長的函數。
2.過于復雜的類
3.過于復雜的依賴關系
4.注釋要簡單明了
二.優美的架構
并不是架構師，才會跟架構打交道。
一旦我們開始編碼，架構就是必備技能了。
我尤其建議：在寫任何功能之前，先想清楚代碼架構。
設計優美的架構要做到如下幾點：
1.穩定性原則
架構盡可能的簡單，清晰，不過度設計。
2.高內聚低耦合
鑒于這個展開講完全可以寫一篇文章，下次專門寫下。
3.隔離
穩定業務和易變業務要分離處理，核心業務和非核心業務要分離處理。
應用和數據要分離，服務和實現細節分離，前臺和后臺分離。
三.重構之美，不斷打磨你的藝術品
無論我們怎么努力，也很難一下子就寫出可讀性很強的代碼。
這就像寫文章一樣，我們的大部分精力都放在表達思想上面，文從字順有的時候就不太顧得上。
寫代碼，第一要務是能運行，能實現軟件系統的功能。
《代碼整潔之道》的作者寫道：“我沒指望你能夠一次過寫出整潔、漂亮的程序。如果說我們從過去幾十年里面學到什么東西的話，那就是編程是一種技藝甚于科學的東西。要編寫整潔代碼，必須先寫骯臟的代碼，然后再清理它?！?/p>
很多人寫出了可以運行的、“骯臟”的代碼，或者說接手了一個可讀性比較差的系統，往往不愿意去重構它們。
他們的理由看上去是十分充分的，那就是容易引入新bug。
事實上，不斷重構才能讓你的代碼始終具備「可維護性」。
同時重構的過程，是一個飛速提升代碼能力的過程。
多年前，我曾接受一個幾十萬行代碼的工程。
一個類就有2萬行，一個函數幾千行.....
我花了半年時間，在保證上線迭代的同時，把這個工程徹底重構。
這個過程的確收益良多。
最后的話
成為優秀程序員的路并不好走，你可能要經歷孤獨、自我懷疑、放棄、痛苦、絕望。
但，這世間所有好走的路，都不值得去走。
只有那些難走的路，征服它才會收獲巨大。
跨越泥濘小路，才能抵達理想彼岸。
祝我的程序員讀者朋友們，都能成為優秀程序員。
祝大家都能開心Coding每一天。
【您的在看，我的莫大鼓勵】
總結
以上是生活随笔為你收集整理的程序员如何跨越35岁危机？这篇给点干货建议！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Typescript前端接口联调自动化的
- 下一篇： 写了多年代码，你会 StackOverf