一、有沒有不加班的程序員？
有，我就是。
我目前工作與一家500強外企（歐美），職稱為高級軟件開發專家。
我在這家公司（500強外企）已經服務了10年，所有加班次數合起來不超過10天，最近3年則一次都沒有。
二、不加班的程序員有沒有前途？
有沒有前途，不在於加不加班，在於有沒有成長。而有沒有成長，一則在於個人的努力，二則在於公司的技術地位，以及文化氛圍。
兩年前，我曾經一時興起，面試了幾家著名互聯網公司，職位是架構師和開發經理，最後都成功拿到了offer。
這也證明，我的綜合實力完全不遜於於加班成風的某些互聯網企業。同時也說明加班和個人的成長沒有必然關係。
三、你知不知道哪些該學，哪些不該學？
Java作為一門語言至今已有20餘年歷史， 無論是語言本身，還是相伴的工具和框架都發生了巨大變化。
- JavaEE框架，從百家混戰到現在Spring基本一統天下。
- Web開發，從標配的SSH到現在SpirngMVC + MyBatis組合。
- IDE，從當年如火如荼的JBuilder到Eclipse，再到更好用的IDEA
在不斷的技術迭代下，如果摸索出一條高效的學習路徑，可以大大的減少自己的時間成本與試錯成本。過去半年，我不斷的盤整自己的思路，想分享我對高效學習Java的看法。但不足之處是都沒有非常系統的梳理。因此，今天剛好趁此機會，我把它們整理起來，希望對大家的學習有所幫助。
spring
在Java EE開發中，Spring已經成為和Java核心庫一樣的基礎設施，所以說如果想成為一個優秀的Java程序員，Spring肯定繞不開。另一方面，如果掌握了Spring體系，Java基本上就算入門了，就有能力進行一些實用級的開發了。
但Spring本身也是日漸複雜，衍生項目越來越多，但最最核心的概念依舊是IOC和AOP，掌握了這兩個概念，再把Spring MVC學會，再學習其他的衍生項目就會平滑很多。
同時，因為Spring本身就應用了許多優雅的設計理念，所以學習Spring的過程，也是加強Java基礎知識學習的過程。因此等你掌握了Spring，原來很多你理解不透徹的Java特性，此時就會恍然大悟，包括接口、抽象類等。
我學習Spring，讀的第一本書是《Spring實戰》，坦率的說，書很一般，但市面上比它好的書，我卻沒有遇到過。還有一本《Spring源碼深度解析》也不錯，對Spring的設計理念講的尤其透徹，雖然整本書讀起來有些艱澀，但前幾章卻生動有趣，也是整本書的精華。所以建議你在學習Spring之前，先把該書的前幾章通讀一下，然後再回過頭來學習《Spring實戰》會順利很多。
以我經驗，要學透Spring，終極的方法還是閱讀源碼（我當時就是這麼幹的），待把Spring的核心源碼通讀了，人就真的自由了（所謂無真相不自由），不僅是對Spring，而是對整個Java體系。以後再遇到其他框架，大概一眼就能看出其中的脈絡，所謂到了“看山不是山”的境界。但這都是後話，可以作為以後你努力的方向。
和學習Java基礎知識一樣，學習Spring也一定要記筆記，一定要分門別類保存demo。
老實說，Spring對初學者不算簡單，因此最好能有個好老師帶一下，不用太長時間，就是在你遇到大的困難時，能及時的點撥下。
以我的經驗，要初步掌握Spring，大概需要1到1個半月的時間。
以下是我整理的spring：
Spring是Java編程的基礎設施，但真要進入到實際項目的開發，還有些東西繞不過，包括 MySql，Mybatis，Redis，Servlet等，但如果你經過Spring的洗禮，這些東西相對就簡單多了，以我的經驗，1個月的時間足夠了。
Mybatis
MyBatis，作為一個“混合式”，輕量級OR映射框架，既繼承了Hibernate的優點，同時也吸取了他的教訓。在支持配置的同時，又能接觸SQL，從而帶來了更多靈活性（包括調試、優化）。
當前，在實際開發中，Hibernate使用的越來越少了。大家更偏愛MyBatis這種輕量級框架。所以，對後來學習者，我的建議是：
“不需要再學習Hibernate了，學MyBatis就夠了。”
設計模式
設計模式，我認為是初中級程序員，向高級程序員提升的關鍵點。
在實踐中，我見過太多程序員，前期衝勁十足，但後繼乏力，最終泯然於眾生。我不敢說所有的人如此，但有不少都是吃了設計模式的虧。
在工作的前幾年，大部分程序員都是處於熟悉語言層面的階段，也就是處於“技”的階段。這個階段，如果人還算靠譜，大概在2到3年就會過去，接下來就要進入“術”的階段。在編程領域，“術”的最典型代表就是“設計模式”。因此，設計模式的重要性再怎麼強調都不為過。
當然，學習設計模式，不僅要讀書，更要從實踐中學習。例如學習Spring框架的過程，如果你有思考，就會發現其中有太多設計模式可供借鑑。
學習設計模式，就是從實踐到理論，然後再從理論到實踐，反覆實踐，反覆思索，反覆總結的過程。當然，這也是從一個“碼農”轉變成“工程師”的過程。
高效開發工具
實現一個軟件系統的過程，不僅只有編碼。還涉及到項目安排，團隊協調等一系列非技術因素。而作為一名程序員，如果想往上更進一步，獨當一面，成為team leader或者開發經理等管理職務。則軟件工程一定要跟上。
當然，軟件工程這麼多年也一直在進步，從原來的瀑布開發，到現在流行的敏捷開發，但無論怎麼變，有些經典的東西還是不變的。
當然，關於軟件工程，最好的學習方法依然是觀察。觀察你所在的團隊、所在的公司是如何處理工程問題，然後思索，閱讀，最終形成自己的方法觀。
架構
寫出一個好程序，有幾個維度，從下到上，也是一個程序員逐步升級的過程。
第一階段，首先要保證基本功紮實，最簡單的說，要做到語法熟練、基本框架熟練，成為一個功夫精熟的“碼農”。
第二階段，從“技”到“術”，從“碼農”到“工程師”。這個階段的關鍵技術是設計模式。在局部上，不僅追求實現功能，更關注實現的好，關注功能之外的維度，例如健壯性、低耦合、可擴展等指標。對主流框架（例如Spring），不僅會用，更有深刻的理解。
第三階段，從“術”到“道”。
這個階段，不僅在局部上追求一個模塊的好壞，而且還要從整個系統層面去掌控程序，例如保證整個程序不出現系統腐敗，如何安排資源的優先級等。這個時候就不是單一的維度，單一的技術能夠保證了。
經常有朋友問我是如何成為一名架構師的，很難用一句話來回答。
我可以路線鮮明教你如何成為一名優秀的軟件工程師，但至於如何成為一名架構師，我想除了努力，運氣肯定也很重要。但無論如何，有機遇，不是還得有準備嘛？
作為一名架構師，所靠的肯定不是單一的維度，也不是但靠純粹的讀書能獲得的。但就我來說，我也有自己完整的技術體系棧，這個確實給我帶來了巨大的幫助，下面我就推薦給大家：
分佈式架構
分佈式架構策略
分佈式架構之中間件
數據結構
毫無疑問，數據結構對一名程序員來說非常重要，不是有句話說“程序 = 數據結構 + 算法”。從某個角度看，這種說法即使現在依然成立。這也說明數據結構的重要性。
但大部分的數據結構課程，關注的重點都在如何從數學上實現一個數據結構（例如堆棧、鏈表）。這從研究上來說，沒有錯。
但在實際開發中，大部分主流語言（例如Java、C#）都已經內置了常用數據結構。而且即使沒有內置的，我們也常可以在第三方庫中找到現成的實現。而且這些實現，大都經過實踐檢驗，無論是穩定性還是性能都有保證。
也就是說，對大部分程序員來說，在實際開發中，很難有需求從頭實現一個數據結構。因此，就完全沒必要像科班生那樣，從數學源頭來學習數據結構，而只需做到下面幾點：
- 熟悉常用數據結構的概念（例如數組、堆棧、鏈表、Map等）
- 瞭解常用數據結構不同實現的差異（例如ArrayList和LinkList的差異）
- 關注常用數據結構的外圍算法（例如如何對List和Map進行查找）
- 關注數據結構使用中容易出錯的地方（例如是否線程是否安全等）
算法
這個要具體問題具體分析了。以我接觸的領域來說，大部分普通的業務系統都不會涉及到太複雜的算法，因此就沒必要專門在算法上投入時間。
但在一些特殊的領域，如果算法跟不上，可能“寸步難行”，例如圖形處理領域，無論是圖像的變化還是增強，無一例外都要用到矩陣變換，因此就必然涉及到線性代數的內容，順藤摸瓜，往縱深學，就必然會牽出更多的東西。
因此，對非科班生（尤其是數學不夠好的），對算法學習我是持“勸退”態度的。因為，從職業發展來說，這實在是一條太“曲折”的路線。
一方面，目前的開發越來越趨專業化，算法一般由專門的算法團隊負責，普通軟件工程師只負責算法轉換。
以我為例，雖然是科班出身，也系統的學習過算法，但也常有力有不逮的時候。複雜的算法既實現不了，甚至是理解不了。很多時候，我乾脆就不做實現，直接請算法工程師告訴我思路，甚至是偽代碼，而我負責轉化為正式代碼（例如Java）。實踐證明，這種做法不僅是可行的，而且也是高效的，正所謂“術業有專攻”。
另一方面，人的精力是有限的，你完全可以把精力投入到自己更擅長的方面，例如設計、產品、架構上，從而取得“差異化”的成功。
最後說說加班的危害
加班最大的危害除了對健康的傷害，對家庭生活的剝奪，還有一個更要命的危害：
高強度的加班（例如996），使中年危機成為每個職場人的必然。
因為中年的危機的本質在與，人日益下降的精力和高強度勞動之間無法調和的矛盾。
年齡大了之後，只要高強度加班（例如996）存在，即使企業不嫌棄你的年齡，給你offer，你也幹不了，即使你不要命。
所以，只要高強度加班一直存在，則每個職場中年人最終都會被踢出勞動市場，無論管理，還是技術。
最近到了傳統的招聘旺季，最近和朋友交流，發現了一種現象。很多工作多年的一線工程師，職級也不低，工作能力也夠強，然而在面試中卻總是能被各種“奇怪”的問題問倒。挫折的次數多了，有些朋友甚至都開始自我懷疑，懷疑自己到底是不是“水貨”？
對這種情況，我和朋友有過幾次討論，最後的結論是：不是我們的能力不行，而是準備的不充分。
本質上，任何一個軟件工程師，在一段時間內，都只能是某種“類型”選手，只“手熱”某一方面的知識。因此，貿然去應聘，被面試官問倒，也就沒什麼奇怪的。
而要解決這個問題，只有一個辦法：不打無準備之戰。
就像學生時代的期末考試一樣，要進行考前複習。而要進行考前複習，就得有複習資料。對一個一線軟件工程師來說，常見的複習資料有幾種：源碼、書籍、視頻、學習筆記。
其中最好就是學習筆記，一則重點突出，二則“量身定製”。
後臺私信回覆“架構” 就可以馬上免費獲得
閱讀更多 小刀愛編程 的文章
