一、業務功能關注點

對於一個做技術的從業人員來說，大部分人開始走的是一條技術+業務的線路。從業務功能回顧一下工程師大致的工作內容：

1、業務理解和分析 

通過解讀需求文件，理解並分析業務。

2、UML建模 

將對業務的理解抽象和歸納為領域模型，並通過繪製UML展現。

3、資料庫表結構設計 

大部分應用程式都是有資料庫的。在設計過程中，有人喜歡先設計資料庫表結構，再建立域模型，也可以反過來，習慣而已。

4、選擇合適的開發框架 

在表結構設計完畢之後，就會選擇或搭建合適的開發框架，然後進入開發階段。基礎框架採用分層模型居多，選用ssh或ssi等流行的框架比較常見。

隨著經驗越來越豐富，工程師的關注點從功能需求逐漸擴充套件到了非功能需求。功能的滿足只是冰山浮在水面上的一小塊；而冰山下面的的巨大沉積物則是非功能需求，它們經常被非技術從業人員所忽視，但卻是實實在在地影響一個系統成功與否的關鍵。

二、非功能需求關注點

1、安全性 

有無SQL注入和跨域指令碼攻擊的問題；密碼是否明文在網路間傳輸；是否可通過主鍵推算出其他主鍵並達到非法訪問的目的（如：ID是連續的，只要知道一個ID，就可能獲取到其他人的資訊）。

2、健壯性

程式是否會由於異常情況導致崩潰，效能是否穩定（如：鎖的不正確使用導致等待過多）等。

3、可伸縮性 

業務成長初期和業務爆發性增長期的應用承載量是完全不同的。當業務快速增長，應用承載量大幅度提升時，如何通過增加伺服器數量的水平擴充套件而不是增加單一伺服器硬體配置的垂直擴充套件來達到承載更多流量和資料量的目的，並且可以在流量洪峰平穩度過後適當的減少硬體伺服器來控制成本。

4、可維護性 

在需要人工介入的系統部署流程中，失誤難於完全避免。並且由於網路抖動而需要運維或重啟時，大量的手工操作難免手忙腳亂，極易產生操作延遲。應通過自動化排程以及部署來幫助運維工程師儘量降低人工介入的頻度。

在成長的軌跡中，工程師大多從微觀入手，並最終領悟如何從巨集觀看待技術。

三、成長軌跡：微觀關注點

幾個常見的微觀關注點：

1、如何對慢SQL建立索引？

相信工程師們應該都做過這件事，分析SQL執行計劃，檢視索引命中情況等。

2、如何保證執行緒安全？

單執行緒時沒有問題，但多執行緒時則可能產生莫名其妙的問題。如何在多執行緒中合理的使用synchronized，volatile以及併發包等，是重要且困難的。並不是不寫多執行緒程式碼就能完全規避這些問題。若使用的框架包括多執行緒，也需要使用者理解它的執行緒模型。

3、如何減少Full GC的頻度？

一個跑在JVM裡面的程式，如果每小時做一次Full GC導致應用停止響應一秒的時間，在效能以及併發要求較高的系統中是難以接受的。需要通過JVM調優來降低Full GC頻度。

4、如何考慮使用設計模式？

設計模式是發現而非發明出來的，目前設計模式已經歸納得很成熟了，已不太容易再發現新設計模式。利用設計模式可以更好地寫出結構清晰，易於理解的程式碼，並降低相互的溝通成本。

5、如何寫出具備強表現力的程式碼？

若程式碼本身難以理解，即使通過註釋也難於讓程式碼本身具有表現力。而且程式碼和註釋也不一定是同步修改的。著急改程式碼，但註釋沒有改的情況比較常見，這樣的註釋是沒有價值的，不如花些時間讓程式碼本身更具展現力。

四、成長軌跡：巨集觀關注點

隨著時間的推移以及經驗的累積，工程師會漸漸地關注更加巨集觀的方面，例如：

1、如何選用適合資料庫儲存相應的資料？

儲存訂單、交易等核心資料，穩定成熟的關係型資料庫是不二之選；儲存帖子類的文字資料， ES就會更加合適。因此需要工程師瞭解各種資料庫的適合場景，結合上下文分析並最終確定選型。

2、如何規劃系統範圍的劃分和拆分？

規模較大公司的系統不可能僅有一個或幾個，它們也不會將所有的服務全部部署在同一個應用伺服器中，而是將其拆分為幾十、幾百甚至上千個系統。無論是當前較為流行的微服務架構，還是以前提及較多的SOA架構，都需要對系統進行拆分。如何合理劃分系統的範圍是巨集觀思考的範疇，如：一個需求應該放入哪個系統，多個需求是否是獨立組成的新系統等。

3、如何規範系統間的同步非同步通訊方式？

系統增多，則需要考慮系統間的通訊互動方式。通訊有RPC或RESTful的同步訪問方式，也有通過訊息中介軟體的非同步訪問方式。定義各種互動的規範，如：確定採用同步通訊以及非同步通訊的標準；確定採用明文、二進位制以及加密自定義序列化協議的場景。

4、分散式系統高可用以及伸縮性如何保障？

分散式系統和單機系統最大的區別在於分散式的不確定性，每次遠端呼叫的請求是否到達難於保證。單機系統宕機，會導致整個系統不可用，但盡力去維護一個單一的系統難度並不大。而分散式系統出現最多的場景是一部分服務宕機，其餘的大部分服務仍然正常。在系統很多的情況下，其排列組合的可能性是指數級上升的。如何能在這種情況下，保證系統的可用性以及伸縮性，是需要從巨集觀點考慮的。如：是否需要有服務治理系統，如何監控，何時擴容等。

5、如何考慮資源、排程、運維、監控一體化？

在容器、雲計算髮展較為成熟的今天，基於Mesos、K8S、Swarm等平臺提供資源分配 +排程+部署的一體化平臺已不是難事。比如，現在有一個由2臺4核伺服器組成的8核小叢集，執行一個任務只佔用0.5核CPU，如果該任務佔用整個一臺伺服器，資源利用率是很低的，因此需要考慮資源的合理分配和排程。一旦某臺伺服器宕機，應將該伺服器中執行的任務分配到另一臺伺服器中，這個過程應儘量自動化。

以上簡單聊到了一些技術人員隨著經驗和技能的增長的客觀變化。工作內容會從僅關心業務功能轉變為同時關注非功能需求，思維方式也會經歷的從微觀到巨集觀的大局觀演進。接下來聊一聊主觀方面的東西，從工匠精神開始談吧。

五、工匠精神

工匠精神是什麼？借用日本劍道三個字——“守破離”。它對其它行業也有借鑑意義，對從事技術行業的同事來說，可以這樣解讀：

守——鑽研基礎知識、理解經典理論、熟悉各種輪子

首先，應充分了解技術的現狀。現在的各種技術棧已經趨於完善，應該多瞭解、多體會、多學習，多思考。儘量多的理解經典理論，比如，CAP理論是在說明什麼問題，Base的最終一致性該怎麼做；基於Paxos和Zab協議做的ZooKeeper適用於什麼場景，Raft和它們又有什麼異同；ACID的強事務又應該用在何處等。理解經典理論的同時，再熟悉各種各樣的輪子。這時不應急於考慮自己應該重新做什麼，如果沒有熟練地使用Spring Framework，理解它的依賴注入和控制反轉理念，直接做一個超越它的框架又談何容易。

破——嘗試修改框架原始碼，總結自己的最佳實踐

通過學習鑽研，已逐漸形成自己的獨立知識體系。對一些技術通用性不強，但行業通用性較強的問題，可以自己寫框架，或者改寫優秀框架的原始碼，吸收其精華，徹底轉化為自己的知識。通過總結自己獨特的最佳實踐，慢慢找到一條適合自己的道路，其不僅限於技術，也包括管理、做事方式等方面。

離——拋開束縛，開闢新境界

這個境界很多人終其一生也很難達到。觸控到這個境界之時，可以將一切的束縛都拋開，根據自己的經驗和能力，順勢而為地完成一些作品，獨立地創造一些東西，可以是技術產品，也可以是服務，更可以是創業的公司。

概括來說，守，剛到公司，熟悉自己的工作，積累經驗；破，在團隊中負責核心工作，根據自己的知識制定規範，領導他人；離，可遇而不可求，創造更大的價值。舉例來說， Linux、MySQL、Hadoop這種級別的產品的所謂的神級人物，他們所做的不僅僅是一個產品，而是一個時代。

技術並不簡單，無論是深度還是廣度，都存在極大的縱深。想真正的成長為大牛，應該要遵循工匠精神，產生足夠敬意，因為接下來會有一條很長的路要走。

六、成長必要條件

1、興趣

只有保持足夠的興趣才能在技術上走得更遠。如果做技術無法體會快樂，完全是為了養家餬口而被迫走上這條路，相信很難在漫長的職業生涯中有足夠的動力持續成長。世界很精彩，不喜歡做技術的人不一定非要做技術，如果最終一定要轉行，越早就越能在新的行業中掌握主動權。

2、決心

對技術有興趣是先決條件，但並不是僅通過興趣，隨隨便便的學習和提高，就一定能成為技術大牛。當然不排除有的人天賦較高，成為技術大牛的路徑會稍微輕鬆一點。技術這個領域與變化相對少的領域不同，一年前的大牛，由於跟不上劇烈的技術變化而快速出局的可能性也是有的。因此想保持長期的競爭力，持續學習和提高決心是很重要的。

3、毅力

一旦下了決心就要持續地提高自己，這是一個長期積累的過程，需要有足夠的毅力堅持。最終的一蹴而就，需要各方面的積累和融會貫通。

想成為大牛的一個先決條件，一定是有想成為大牛的強烈願望。這個道理與不想當將軍的士兵不是一個好的士兵是一樣的。如果本人都沒願望、沒信心、沒興趣，自己都不朝著這個目標努力，他不太可能被動地成長為一個大牛。

從“守破離”三點來看，被推動，即使平臺再優秀，能走到“破”這一階段已經是極限了，能走到“離”階段的人，是通過的興趣、決心和毅力主動達到的。

七、一些建議

這裡特別澄清一下，我沒有任何傾向表達轉崗不好，任何崗位和行業都有其獨特的價值，行行出狀元，這裡僅僅是對開發崗朋友的一些建議。

1、優質完成工作

畢竟工作還是很重要的，而且只有工作這個平臺，給人帶來的促進和成長才是最大的。不能因為只對純技術感興趣，而對工作中的業務完全沒興趣，就不盡力做，不用心思考，脫離的業務的技術本身並不會產生價值。

2、保持對技術的熱情

有的朋友在接觸一個新技術一段時間之後，完全掌握了使用問題，雖然也可能吐槽某些方面用起來不順手，但並不深究其原理，也不動手改進，一直停留在使用階段，用它做做業務，把工作完成。這種型別的人如果繼續做技術，未來難免會遇到瓶頸，從而失去自己的核心競爭力，儘早轉管理、業務或產品甚至測試都是可以的。目前新概念層出不窮，當前的熱點技術過段時間也許就不再流行，因此養成長期關注技術趨勢，保持敏感度也很重要。

3、完成一個基於興趣的作品

將一個作品當做藝術品去做，不考慮排期、取捨，而是僅自己最大的努力，一點點的打磨，螺旋形地提升它的程式碼和功能。當完成了一個與工作無關，只因興趣打造的作品完成之後，一定能從中獲取很多經驗，帶來很大成長。

4、維持開放的心態

無論自己的水平成長得有多高、多快，個人的精力有限，永遠不可能瞭解和認知所有的技術和知識。因此仍舊需要隨時維持開放的心態，多交流、溝通、學習，充實自己。

5、開源、分享、回饋社群

做開源，讓其他工程師研究你寫的程式碼，或在各種平臺分享自己的經驗，以及積極的回饋社群，包括回答問題，對開源產品提交issue、提交pr、撰寫文件、編寫使用心得等。做這些看似不能直接帶來收益的事情，經過積累之後所獲取的收益不僅是能力提升，也會對技術影響力帶來提升，並且有更多的機會與更多的牛人交流。

八、成長的目標

1、專業性的態度

以兩個技術問題聊聊專業性的態度。

• 框架是設計出來的還是演進出來的？

這其實是一個開放性問題，不同習慣的人，他們的回答也許不一樣，我認為優秀的設計可以少走一些彎路，但一個長久不衰的框架，一定是經過層層演進而來。如大家熟悉的Spring Framework，已發展到了Spring 5.X，Spring 1X和Spring 5.X差別很大，在其長期的演變過程中，層出不窮地出現了很多新技術，它為了適配一步步的進行演進、直至現在。所以，需要一個專業性的態度，讓自己的產品可以持續演進。

• 如何精煉一個模組？

去觀察一個存在時間較長的活躍專案的提交記錄，程式碼的增加和刪除行數基本成正比，有效的刪除無用程式碼的重要程度和新功能開發相當。如果是觀察一個試水性質的專案的提交記錄則另當別論，基本上程式碼只增不刪。因此，精煉一個模組，要持續對它進行修改和完善，它才能以螺旋型的方式去提升。

2、前瞻性的眼光

• 架構是設計出來的還是演進出來的？

如果剛才的問題是開放性的，那這個問題並不能算是開放性的。我認為好的架構一定是設計出來而非演進而來的。如果架構一開始並沒有設計得足夠好，而是隨著系統的演進，架構也隨時與時俱進的演進，那架構和業務的雙重修改所帶來的複雜性和不確定性是難以估量的，而且架構所能提供的能力決定了業務程式碼的上限。不具備前瞻性的架構是失敗的作品。

• 設計一個架構，是在設計一個世界還是實現一個細節？

這個問題的答案顯而易見。所謂架構，最先出現於建築學，架構相當於一個房屋的樑與柱，用於IT行業，架構同樣相當於一個系統的基礎設施。因此設計一個架構，是大方向的規劃和演進路徑的闡述，而非細節的實現和優化。

• 顛覆一個架構的損失會有多大？

不到萬不得已，企業不會輕易更換開發語言和資料庫。同樣，更換架構也是實在撐不下去才為之。因此大部分時間，工程師都是在一個已經相對過時的架構中開發，那麼架構設計的是否有前瞻性，是否最大限度的靈活擁抱變化、滿足效能要求就更加重要。

3、系統性的思考

• 方案如何落地？

完成一個方案之後，讓其落地並不簡單，如何部署、運維、除錯、灰度升級、回滾都是需要考慮的範疇。這是一個整體落地的過程，一個整體思維上的閉環。

• 程式碼提交了就是全部嗎？

剛才提到的方案落地話題比較大，換一個小一點的話題。技術人員主要以寫程式碼為主，程式碼提交只是工作的一部分，剩餘的工作量還有很多。比如怎麼交接、文件是否易懂、如何修復bug等一系列相關問題。同樣需要培養一個整體的、系統的思考能力。

九、心境轉換

在完成技術層面的提升外，還需要有心境上的轉換。主要包括責任心、自驅力和執行力三個方面，它們應隨著技術水平的提升而相應地提升。

能力越強，其責任必然越大，責任心與能力應成正比，能力再高的人，若責任心不足，企業是無法將重大的事情交給他的。責任不僅僅在於做好自己的事情，也在於敢於承擔更多的挑戰和職責。

平穩地度過職業生涯早期後，自驅力的重要性就更加顯露無疑。被別人推動去做事與主動地、高要求地做事，能力成長的差距會愈加明顯。

今日事，今日畢。雖然企業永遠有做不完的事，但越儘早的完成一件事，才能儘早的投入另一件事。高效的執行力與強大的自驅力相得益彰。

十、目標與願景

職業生涯早期看到的主要是工作願景和個人願景。

公司願景即在公司做更重要的事，更高的職位。

個人願景則是獲得更高的薪水，享受更好的生活。

社會願景也可以稱之為行業願景，它隨著閱歷的提高而逐漸展現。做開源，寫部落格，參與分享甚至自己創業，都會承擔更多的社會責任，也會更多的獲得業界認可，能更加正向的勉勵自己不斷向前邁進。以社會願景為最終目標，可以更有效的促進工作願景以及個人願景的達成。

分享一些我做開源的經驗。在開源的一兩年時間裡，交流群和Github中被問到很多問題，提出很多質疑，它們推動著我在開源的路上繼續前行。在幫助別人的同時，吸取社群精華，完善自己的專案，感覺收穫遠多於前幾年的積累。

今天的分享就到這裡，歡迎留言討論。

作者介紹 張亮

• 噹噹架構部總監，主要負責分散式中介軟體以及私有云平臺的搭建。致力於開源，目前主導兩個開源專案Elastic-job和Sharding-jdbc。
• 擅長以Java為主的分散式架構和以Mesos為主的雲平臺方向，推崇優雅程式碼，對如何寫出具有展現力的程式碼有較多研究。

文章來自微信公眾號：DBAplus社群