驀然回首,從畢業到現在做后臺開發已經十年了，這十年中我獲得了很多，技術能力、培訓、出國、大公司的經歷，還有很多志同道合的朋友。但再仔細一想，這十年碼農路上我至少浪費了五年時間，這五年可以足夠讓自己成長為一個優秀的程序員，可惜我錯過了，我用這五年時間和很多程序員一樣在困惑和迷茫中找不到出路!

在大公司做事情有一個特征，你只需要在工作時間做好公司給你安排的那份工作，你就會做的很好，這也就是說每個人都是一顆螺絲釘。所以，我在一進入大公司后，由于自己經歷不夠，再加上剛畢業就作為大學班上進入大公司的佼佼者，所以有點飄，不能沉下心來研究技術，所以浪費了一段時間。

后來在和在貝爾實驗室(上海)工作的研究生同學的一次交流中，讓我嚴重的意識到，做為程序員除了做好公司安排的工作只是為了自己“活著”，而程序員的“生活”應該是體現在自己對技術的追求和對源碼的執著之上。

雖然自己經常和周圍的朋友進行程序生涯的交流，唯獨這次交流才真正影響了我的程序人生?；叵肫饋?，影響程序員明天困局的往往就是一直掛著我們嘴邊的小事，那些源碼啊，框架啊，實戰，造輪子，開源這一切都需要我們實實在在親力親為的一行行代碼去解決。

今天，就為大家整理一份目前互聯網公司Java 后臺最主流的技術選型。

[[240127]]

1. 閱讀源碼

程序員每天都和代碼打交道。經過數年的基礎教育和職業培訓，大部分程序員都會「寫」代碼，或者至少會抄代碼和改代碼。但是，會讀代碼的并不在多數，會讀代碼又真正讀懂一些大項目的源碼的，少之又少。這也造成了很多錯誤看源碼的方式。

那要如何正確的分析源碼呢?

我們的目標應該放在最常用的框架上面，下面就介紹兩個：一個是Spring，另一個是大家用來覺得一直不怎么出問題的Mybatis。

△spring源碼

△mybatis源碼

2. 分布式架構

隨著我們的業務量越來越大和越重要，單體的架構模式已經無法對應大規模的應用場景，而且系統中決不能存在單點故障導致整體不可用，所以只有垂直或是水平拆分業務系統，使其形成一個分布式的架構，利用分布式架構來冗余系統消除單點的故障，從而提高整個系統的可用性。同時分布式系統的模塊重用度更高，速度更快，擴展性更高是大型的項目必不可少的環節。

3. 微服務

關于微服務架構的取舍

• 在合適的項目，合適的團隊，采用微服務架構收益會大于成本。
• 微服務架構有很多吸引人的地方，但在擁抱微服務之前，也需要認清它所帶來的挑戰。
• 需要避免為了“微服務”而“微服務”。
• 微服務架構引入策略 – 對傳統企業而言，開始時可以考慮引入部分合適的微服務架構原則對已有系統進行改造或新建微服務應用，逐步探索及積累微服務架構經驗，而非全盤實施微服務架構。

4. 性能調優

我們不僅僅對項目要運籌帷幄，還要能解決一切性能問題。只有深入學習JVM底層原理，Mysql底層優化以及Tomcat調優，才能達到知其然，知其所以然的效果。除了性能優化之外，也能提供通用的常見思路以及方案選型的考慮點，幫助大家培養在方案選型時的意識、思維以及做各種權衡的能力。

5. 開發工具工程化

通過一小段描述信息來管理項目的構建，報告和文檔的軟件項目管理工具。程序員的戰斗，往往不是一個人的戰斗，我們如何在一個平臺下高效的去重，進行代碼review，對功能進行調整，debug，做到在統一的規劃下步步為營，混亂的堆代碼的過程中找到自己的記錄。這一切都依賴于有效的工具。

6. 項目實戰

要想立足于互聯網公司，且能在互聯網浪潮中不被淹沒，對于項目的開發實戰演練是不必可少的技能，也是對自身能力的一個衡量，有多少的量對等于獲得多少的回報?？此坪唵蔚囊粋€項目需求圖譜，其中的底層原理，實現原理又能知道多少?你搭建一個完整的B2C項目平臺到底需要多少知識?這一切都是需要我們考量的。

【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】

戳這里，看該作者更多好文