摘要：導(dǎo)讀數(shù)人云大牛的成長(zhǎng)軌跡邀請(qǐng)到來(lái)自當(dāng)當(dāng)架構(gòu)部的張亮老師，從技術(shù)和情懷的角度來(lái)分享自己的成長(zhǎng)軌跡，具備工匠精神的同時(shí)也要注重回報(bào)社會(huì)，做到技術(shù)與心境雙重提升。張亮當(dāng)當(dāng)架構(gòu)部總監(jiān)主要負(fù)責(zé)分布式中間件以及私有云平臺(tái)的搭建。

導(dǎo)讀：數(shù)人云【大牛的成長(zhǎng)軌跡】Meetup邀請(qǐng)到來(lái)自當(dāng)當(dāng)架構(gòu)部的張亮老師，從技術(shù)和情懷的角度來(lái)分享自己的成長(zhǎng)軌跡，具備工匠精神的同時(shí)也要注重回報(bào)社會(huì)，做到技術(shù)與心境雙重提升。

張亮 /當(dāng)當(dāng)架構(gòu)部總監(jiān)

主要負(fù)責(zé)分布式中間件以及私有云平臺(tái)的搭建。致力于開(kāi)源，目前主導(dǎo)兩個(gè)開(kāi)源項(xiàng)目elastic-job和sharding-jdbc。擅長(zhǎng)以Java為主的分布式架構(gòu)和以Mesos為主的云平臺(tái)方向，推崇優(yōu)雅代碼，對(duì)如何寫(xiě)出具有展現(xiàn)力的代碼有較多研究。

*以下內(nèi)容為活動(dòng)實(shí)錄：

對(duì)于一個(gè)做技術(shù)的從業(yè)人員來(lái)說(shuō)，大部分人開(kāi)始走的是一條技術(shù)+業(yè)務(wù)的線路。從業(yè)務(wù)功能回顧一下工程師的工作的大致內(nèi)容：

業(yè)務(wù)理解和分析

通過(guò)解讀需求文檔，理解并分析業(yè)務(wù)。

UML建模

將對(duì)業(yè)務(wù)的理解抽象和歸納為領(lǐng)域模型，并通過(guò)繪制UML展現(xiàn)。

數(shù)據(jù)庫(kù)表結(jié)構(gòu)設(shè)計(jì)

大部分應(yīng)用程序都是有數(shù)據(jù)庫(kù)的。在設(shè)計(jì)過(guò)程中，有人喜歡先設(shè)計(jì)數(shù)據(jù)庫(kù)表結(jié)構(gòu)，再創(chuàng)建域模型，也可以反過(guò)來(lái)，習(xí)慣而已。

選擇合適的開(kāi)發(fā)框架

在表結(jié)構(gòu)設(shè)計(jì)完畢之后，就會(huì)選擇或搭建合適的開(kāi)發(fā)框架，然后進(jìn)入開(kāi)發(fā)階段?；A(chǔ)框架采用分層模型居多，選用ssh或ssi等流行的框架比較常見(jiàn)。

隨著經(jīng)驗(yàn)越來(lái)越豐富，工程師的關(guān)注點(diǎn)從功能需求逐漸擴(kuò)展到了非功能需求。功能的滿足只是冰山浮在水面上的一小塊；而冰山下面的的巨大沉積物則是非功能需求，它們經(jīng)常被非技術(shù)從業(yè)人員所忽視，但卻是實(shí)實(shí)在在地影響一個(gè)系統(tǒng)成功與否的關(guān)鍵。

安全性

有無(wú)SQL注入和跨域腳本攻擊的問(wèn)題；密碼是否明文在網(wǎng)絡(luò)間傳輸；是否可通過(guò)主鍵推算出其他主鍵并達(dá)到非法訪問(wèn)的目的（如：ID是連續(xù)的，只要知道一個(gè)ID，就可能獲取到其他人的信息）。

健壯性

程序會(huì)否由于異常情況導(dǎo)致崩潰，性能是否穩(wěn)定（如：鎖的不正確使用導(dǎo)致等待過(guò)多）等。

可伸縮性

業(yè)務(wù)成長(zhǎng)初期和業(yè)務(wù)爆發(fā)性增長(zhǎng)期的應(yīng)用承載量是完全不同的。當(dāng)業(yè)務(wù)快速增長(zhǎng)，應(yīng)用承載量大幅度提升時(shí)，如何通過(guò)增加服務(wù)器數(shù)量的水平擴(kuò)展而不是增加單一服務(wù)器硬件配置的垂直擴(kuò)展來(lái)達(dá)到承載更多流量和數(shù)據(jù)量的目的，并且可以在流量洪峰平穩(wěn)度過(guò)后適當(dāng)?shù)臏p少硬件服務(wù)器來(lái)控制成本。

可維護(hù)性

在需要人工介入的系統(tǒng)部署流程中，失誤難于完全避免。并且由于網(wǎng)絡(luò)抖動(dòng)而需要運(yùn)維或重啟時(shí)，大量的手工操作難免手忙腳亂，極易產(chǎn)生操作延遲。應(yīng)通過(guò)自動(dòng)化調(diào)度以及部署來(lái)幫助運(yùn)維工程師盡量降低人工介入的頻度。

在成長(zhǎng)的軌跡中，工程師大多從微觀入手，并最終領(lǐng)悟如何從宏觀看待技術(shù)。

幾個(gè)常見(jiàn)的微觀關(guān)注點(diǎn)：

如何對(duì)慢SQL創(chuàng)建索引？

相信工程師們應(yīng)該都做過(guò)這件事，分析SQL執(zhí)行計(jì)劃，查看索引命中情況等。

如何保證線程安全？

單線程時(shí)沒(méi)有問(wèn)題，但多線程時(shí)則可能產(chǎn)生莫名其妙的問(wèn)題。如何在多線程中合理的使用synchronized，volatile以及并發(fā)包等，是重要且困難的。并不是不寫(xiě)多線程代碼就能完全規(guī)避這些問(wèn)題。若使用的框架包括多線程，也需要使用者理解它的線程模型。

如何減少Full GC的頻度？

一個(gè)跑在JVM里面的程序，如果每小時(shí)做一次Full GC導(dǎo)致應(yīng)用停止響應(yīng)一秒的時(shí)間，在性能以及并發(fā)要求較高的系統(tǒng)中是難以接受的。需要通過(guò)JVM調(diào)優(yōu)來(lái)降低Full GC頻度。

如何考慮使用設(shè)計(jì)模式？

設(shè)計(jì)模式是發(fā)現(xiàn)而非發(fā)明出來(lái)的，目前設(shè)計(jì)模式已經(jīng)歸納的很成熟了，已不太容易再發(fā)現(xiàn)新設(shè)計(jì)模式。利用設(shè)計(jì)模式可以更好的寫(xiě)出結(jié)構(gòu)清晰，易于理解的代碼，并降低相互的溝通成本。

如何寫(xiě)出具備強(qiáng)表現(xiàn)力的代碼？

若代碼本身難以理解，即使通過(guò)注釋也難于讓代碼本身具有表現(xiàn)力。而且代碼和注釋也不一定是同步修改的。著急改代碼，但注釋沒(méi)有改的情況比較常見(jiàn)，這樣的注釋是沒(méi)有價(jià)值的，不如花些時(shí)間讓代碼本身更具展現(xiàn)力。

隨著時(shí)間的推移以及經(jīng)驗(yàn)的累積，工程師會(huì)漸漸地關(guān)注更加宏觀的方面，例如：

如何選用適合數(shù)據(jù)庫(kù)存儲(chǔ)相應(yīng)的數(shù)據(jù)？

存儲(chǔ)訂單、交易等核心數(shù)據(jù)，穩(wěn)定成熟的關(guān)系型數(shù)據(jù)庫(kù)是不二之選；存儲(chǔ)帖子類(lèi)的文本數(shù)據(jù)， ES就會(huì)更加合適。因此需要工程師了解各種數(shù)據(jù)庫(kù)的適合場(chǎng)景，結(jié)合上下文分析并最終確定選型。

如何規(guī)劃系統(tǒng)范圍的劃分和拆分？

規(guī)模較大公司的系統(tǒng)不可能僅有一個(gè)或幾個(gè)，它們也不會(huì)將所有的服務(wù)全部部署在同一個(gè)應(yīng)用服務(wù)器中，而是將其拆分為幾十、幾百甚至上千個(gè)系統(tǒng)。無(wú)論是當(dāng)前較為流行的微服務(wù)架構(gòu)，還是以前提及較多的SOA架構(gòu)，都需要對(duì)系統(tǒng)進(jìn)行拆分。如何合理劃分系統(tǒng)的范圍是宏觀思考的范疇，如：一個(gè)需求應(yīng)該放入哪個(gè)系統(tǒng)，多個(gè)需求是否是獨(dú)立組成的新系統(tǒng)等。

如何規(guī)范系統(tǒng)間的同步異步通訊方式？

系統(tǒng)增多，則需要考慮系統(tǒng)間的通信交互方式。通信有RPC或RESTful的同步訪問(wèn)方式，也有通過(guò)消息中間件的異步訪問(wèn)方式。定義各種交互的規(guī)范，如：確定采用同步通信以及異步通信的標(biāo)準(zhǔn)；確定采用明文、二進(jìn)制以及加密自定義序列化協(xié)議的場(chǎng)景。

分布式系統(tǒng)高可用以及伸縮性如何保障？

分布式系統(tǒng)和單機(jī)系統(tǒng)最大的區(qū)別在于分布式的不確定性，每次遠(yuǎn)程調(diào)用的請(qǐng)求是否到達(dá)難于保證。單機(jī)系統(tǒng)宕機(jī)，會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用，但盡力去維護(hù)一個(gè)單一的系統(tǒng)難度并不大。而分布式系統(tǒng)出現(xiàn)最多的場(chǎng)景是一部分服務(wù)宕機(jī)，其余的大部分服務(wù)仍然正常。在系統(tǒng)很多的情況下，其排列組合的可能性是指數(shù)級(jí)上升的。如何能在這種情況下，保證系統(tǒng)的可用性以及伸縮性，是需要從宏觀點(diǎn)考慮的。如：是否需要有服務(wù)治理系統(tǒng)，如何監(jiān)控，何時(shí)擴(kuò)容等。

如何考慮資源、調(diào)度、運(yùn)維、監(jiān)控一體化？

在容器、云計(jì)算發(fā)展的較為成熟的今天，基于Mesos、K8S、Swarm等平臺(tái)提供資源分配 +調(diào)度+部署的一體化平臺(tái)已不是難事。比如，現(xiàn)在有一個(gè)由2臺(tái)4核服務(wù)器組成的8核小集群，運(yùn)行一個(gè)任務(wù)只占用0.5核CPU，如果該任務(wù)占用整個(gè)一臺(tái)服務(wù)器，資源利用率是很低的，因此需要考慮資源的合理分配和調(diào)度。一旦某臺(tái)服務(wù)器宕機(jī)，應(yīng)將該服務(wù)器中運(yùn)行的任務(wù)分配到另一臺(tái)服務(wù)器中，這個(gè)過(guò)程應(yīng)盡量自動(dòng)化。

以上簡(jiǎn)單了聊了一些技術(shù)人員隨著經(jīng)驗(yàn)和技能的增長(zhǎng)的客觀變化。工作內(nèi)容會(huì)從僅關(guān)心業(yè)務(wù)功能轉(zhuǎn)變?yōu)橥瑫r(shí)關(guān)注非功能需求，思維方式也會(huì)經(jīng)歷的從微觀到宏觀的大局觀演進(jìn)。接下來(lái)聊一聊主觀方面的東西，從工匠精神開(kāi)始談吧。

工匠精神是什么？

借用日本劍道三個(gè)字——“守破離”。它對(duì)其他行業(yè)也有借鑒意義，對(duì)從事技術(shù)行業(yè)的同事來(lái)說(shuō)，可以這樣解讀：

守——鉆研基礎(chǔ)知識(shí)、理解經(jīng)典理論、熟悉各種輪子

首先，應(yīng)充分了解技術(shù)的現(xiàn)狀。現(xiàn)在的各種技術(shù)棧已經(jīng)趨于完善，應(yīng)該多了解、多體會(huì)、多學(xué)習(xí)，多思考。盡量多的理解經(jīng)典理論，比如，CAP理論是在說(shuō)明什么問(wèn)題，BASE的最終一致性該怎么做；基于PAXOS和ZAB協(xié)議做的ZooKeeper適用于什么場(chǎng)景，Raft和他們又有什么異同；ACID的強(qiáng)事務(wù)又應(yīng)該用在何處等。理解經(jīng)典理論的同時(shí)，再熟悉各種各樣的輪子。這時(shí)不應(yīng)急于考慮自己應(yīng)該重新做什么，如果沒(méi)有熟練的使用Spring Framework，理解它的依賴(lài)注入和控制反轉(zhuǎn)理念，直接做一個(gè)超越它的框架又談何容易。

破——嘗試修改框架源碼，總結(jié)自己的最佳實(shí)踐

通過(guò)學(xué)習(xí)鉆研，已逐漸的形成自己的獨(dú)立知識(shí)體系。對(duì)一些技術(shù)通用性不強(qiáng)，但行業(yè)通用性較強(qiáng)的問(wèn)題，可以自己寫(xiě)框架，或者改寫(xiě)優(yōu)秀框架的源碼，吸收其精華，徹底轉(zhuǎn)化為自己的知識(shí)。通過(guò)總結(jié)自己獨(dú)特的最佳實(shí)踐，慢慢的找到一條適合自己的道路，其不僅限于技術(shù)，也包括管理、做事方式等方面。

離——拋開(kāi)束縛，開(kāi)辟新境界

這個(gè)境界很多人終其一生也很難達(dá)到。觸摸到這個(gè)境界之時(shí)，可以將一切的束縛都拋開(kāi)，根據(jù)自己的經(jīng)驗(yàn)和能力，順勢(shì)而為的完成一些作品，獨(dú)立地創(chuàng)造一些東西，可以是技術(shù)產(chǎn)品，也可以是服務(wù)，更可以是創(chuàng)業(yè)的公司。

概括來(lái)說(shuō)，守，剛到公司，熟悉自己的工作，積累經(jīng)驗(yàn)；破，在團(tuán)隊(duì)中負(fù)責(zé)核心工作，根據(jù)自己的知識(shí)制定規(guī)范，領(lǐng)導(dǎo)他人；離，可遇而不可求，創(chuàng)造更大的價(jià)值。舉例來(lái)說(shuō)， Linux、MySQL、Hadoop這種級(jí)別的產(chǎn)品的所謂的神級(jí)人物，他們所做的不僅僅是一個(gè)產(chǎn)品，而是一個(gè)時(shí)代。

技術(shù)并不簡(jiǎn)單，無(wú)論是深度還是廣度，都存在極大的縱深。想真正的成長(zhǎng)為大牛，應(yīng)該要遵循工匠精神，產(chǎn)生足夠敬意，因?yàn)榻酉聛?lái)會(huì)有一條很長(zhǎng)的路要走。

興趣

只有保持足夠的興趣才能在技術(shù)上走得更遠(yuǎn)。如果做技術(shù)無(wú)法體會(huì)快樂(lè)，完全是為了養(yǎng)家糊口而被迫走上這條路，相信很難在漫長(zhǎng)的職業(yè)生涯中有足夠的動(dòng)力持續(xù)成長(zhǎng)。世界很精彩，不喜歡做技術(shù)的人不一定非要做技術(shù)，如果最終一定要轉(zhuǎn)行，越早就越能在新的行業(yè)中掌握主動(dòng)權(quán)。

決心

對(duì)技術(shù)有興趣是先決條件，但并不是僅通過(guò)興趣，隨隨便便的學(xué)習(xí)和提高，就一定能成為技術(shù)大牛。當(dāng)然不排除有的人天賦較高，成為技術(shù)大牛的路徑會(huì)稍微輕松一點(diǎn)。技術(shù)這個(gè)領(lǐng)域與變化相對(duì)少的領(lǐng)域不同，一年前的大牛，由于跟不上劇烈的技術(shù)變化而快速出局的可能性也是有的。因此想保持長(zhǎng)期的競(jìng)爭(zhēng)力，持續(xù)學(xué)習(xí)和提高決心是很重要的。

毅力

一旦下了決心就要持續(xù)的提高自己，這是一個(gè)長(zhǎng)期積累的過(guò)程，需要有足夠的毅力堅(jiān)持。最終的一蹴而就，需要各方面的積累和融會(huì)貫通。

想成為大牛的一個(gè)先決條件，一定是有想成為大牛的強(qiáng)烈愿望。這個(gè)道理與不想當(dāng)將軍的士兵不是一個(gè)好的士兵是一樣的。如果本人都沒(méi)愿望、沒(méi)信心、沒(méi)興趣，自己都不朝著這個(gè)目標(biāo)努力，他不太可能被動(dòng)的被成長(zhǎng)為一個(gè)大牛。從“守破離”三點(diǎn)來(lái)看，被推動(dòng)，即使平臺(tái)再優(yōu)秀，能走到“破”這一階段已經(jīng)是極限了，能走到“離”階段的人，是通過(guò)的興趣、決心和毅力主動(dòng)達(dá)到的。

這里特別澄清一下，我沒(méi)有任何傾向表達(dá)轉(zhuǎn)崗不好，任何崗位和行業(yè)都有其獨(dú)特的價(jià)值，行行出狀元，這里僅僅是對(duì)開(kāi)發(fā)崗朋友的一些建議。

優(yōu)質(zhì)完成工作

畢竟工作還是很重要的，而且只有工作這個(gè)平臺(tái)，給人帶來(lái)的促進(jìn)和成長(zhǎng)才是最大的。不能因?yàn)橹粚?duì)純技術(shù)感興趣，而對(duì)工作中的業(yè)務(wù)完全沒(méi)興趣，就不盡力做，不用心思考，脫離的業(yè)務(wù)的技術(shù)本身并不會(huì)產(chǎn)生價(jià)值。

保持對(duì)技術(shù)的熱情

有的朋友在接觸一個(gè)新技術(shù)一段時(shí)間之后，完全掌握了使用問(wèn)題，雖然也可能吐槽某些方面用起來(lái)不順手，但并不深究其原理，也不動(dòng)手改進(jìn)，一直停留在使用階段，用它做做業(yè)務(wù)，把工作完成。這種類(lèi)型的人如果繼續(xù)做技術(shù)，未來(lái)難免會(huì)遇到瓶頸，從而失去自己的核心競(jìng)爭(zhēng)力，盡早轉(zhuǎn)管理、業(yè)務(wù)或產(chǎn)品甚至測(cè)試都是可以的。目前新概念層出不窮，當(dāng)前的熱點(diǎn)技術(shù)過(guò)段時(shí)間也許就不再流行，因此養(yǎng)成長(zhǎng)期關(guān)注技術(shù)趨勢(shì)，保持敏感度也很重要。

完成一個(gè)基于興趣的作品

將一個(gè)作品當(dāng)做藝術(shù)品去做，不考慮排期、取舍，而是僅自己最大的努力，一點(diǎn)點(diǎn)的打磨，螺旋形的提升它的代碼和功能。當(dāng)完成了一個(gè)與工作無(wú)關(guān)，只因興趣打造的作品完成之后，一定能從中獲取很多經(jīng)驗(yàn)，帶來(lái)很大成長(zhǎng)。

維持開(kāi)放的心態(tài)

無(wú)論自己的水平成長(zhǎng)得有多高、多快，個(gè)人的精力有限，永遠(yuǎn)不可能了解和認(rèn)知所有的技術(shù)和知識(shí)。因此仍舊需要隨時(shí)維持開(kāi)放的心態(tài)，多交流、溝通、學(xué)習(xí)，充實(shí)自己。

開(kāi)源、分享、回饋社區(qū)

做開(kāi)源，讓其他工程師研究你寫(xiě)的代碼，或在各種平臺(tái)分享自己的經(jīng)驗(yàn)，以及積極的回饋社區(qū)，包括回答問(wèn)題，對(duì)開(kāi)源產(chǎn)品提交issue、提交pr、撰寫(xiě)文檔、編寫(xiě)使用心得等。做這些看似不能直接帶來(lái)收益的事情，經(jīng)過(guò)積累之后所獲取的收益不僅是能力提升，也會(huì)對(duì)技術(shù)影響力帶來(lái)提升，并且有更多的機(jī)會(huì)與更多的牛人交流。

專(zhuān)業(yè)性的態(tài)度

以兩個(gè)技術(shù)問(wèn)題聊聊專(zhuān)業(yè)性的態(tài)度。

框架是設(shè)計(jì)出來(lái)的還是演進(jìn)出來(lái)的？

這其實(shí)是一個(gè)開(kāi)放性問(wèn)題，不同習(xí)慣的人，他們的回答也許不一樣，我認(rèn)為優(yōu)秀的設(shè)計(jì)可以少走一些彎路，但一個(gè)長(zhǎng)久不衰的框架，一定是經(jīng)過(guò)層層演進(jìn)而來(lái)。如大家熟悉的Spring Framework，已發(fā)展到了Spring 5.X，Spring 1X和Spring 5.X差別很大, 在其長(zhǎng)期的演變過(guò)程中，層出不窮的出現(xiàn)了很多新技術(shù)，它為了適配一步步的進(jìn)行演進(jìn)，直至現(xiàn)在。所以，需要一個(gè)專(zhuān)業(yè)性的態(tài)度，讓自己的產(chǎn)品可以持續(xù)演進(jìn)。

如何精煉一個(gè)模塊？

去觀察一個(gè)存在時(shí)間較長(zhǎng)的活躍項(xiàng)目的提交記錄，代碼的增加和刪除行數(shù)基本成正比，有效的刪除無(wú)用代碼的重要程度和新功能開(kāi)發(fā)相當(dāng)。如果是觀察一個(gè)試水性質(zhì)的項(xiàng)目的提交記錄則另當(dāng)別論，基本上代碼只增不刪。因此，精煉一個(gè)模塊，要持續(xù)對(duì)它進(jìn)行修改和完善，它才能以螺旋型的方式去提升。

前瞻性的眼光

架構(gòu)是設(shè)計(jì)出來(lái)的還是演進(jìn)出來(lái)的？

如果剛才的問(wèn)題是開(kāi)放性的，那么這個(gè)問(wèn)題并不能算是開(kāi)放性的。我認(rèn)為好的架構(gòu)一定是設(shè)計(jì)出來(lái)而非演進(jìn)而來(lái)的。如果架構(gòu)一開(kāi)始并沒(méi)有設(shè)計(jì)的足夠好，而是隨著系統(tǒng)的演進(jìn)，架構(gòu)也隨時(shí)與時(shí)俱進(jìn)的演進(jìn)，那么架構(gòu)和業(yè)務(wù)的雙重修改所帶來(lái)的復(fù)雜性和不確定性是難以估量的，而且架構(gòu)所能提供的能力決定了業(yè)務(wù)代碼的上限。不具備前瞻性的架構(gòu)是失敗的作品。

設(shè)計(jì)一個(gè)架構(gòu)，是在設(shè)計(jì)一個(gè)世界還是實(shí)現(xiàn)一個(gè)細(xì)節(jié)？

這個(gè)問(wèn)題的答案顯而易見(jiàn)。所謂架構(gòu)，最先出現(xiàn)于建筑學(xué)，架構(gòu)相當(dāng)于一個(gè)房屋的梁與柱，用于IT行業(yè)，架構(gòu)同樣相當(dāng)于一個(gè)系統(tǒng)的基礎(chǔ)設(shè)施。因此設(shè)計(jì)一個(gè)架構(gòu)，是大方向的規(guī)劃和演進(jìn)路徑的闡述，而非細(xì)節(jié)的實(shí)現(xiàn)和優(yōu)化。

顛覆一個(gè)架構(gòu)的損失會(huì)有多大？

不到萬(wàn)不得已，企業(yè)不會(huì)輕易更換開(kāi)發(fā)語(yǔ)言和數(shù)據(jù)庫(kù)。同樣，更換架構(gòu)也是實(shí)在撐不下去才為之。因此大部分時(shí)間，工程師都是在一個(gè)已經(jīng)相對(duì)過(guò)時(shí)的架構(gòu)中開(kāi)發(fā)，那么架構(gòu)設(shè)計(jì)的是否有前瞻性，是否最大限度的靈活擁抱變化、滿足性能要求就更加重要。

系統(tǒng)性的思考

方案如何落地？

完成一個(gè)方案之后，讓其落地并不簡(jiǎn)單，如何部署、運(yùn)維、調(diào)試、灰度升級(jí)、回滾都是需要考慮的范疇。這是一個(gè)整體落地的過(guò)程，一個(gè)整體思維上的閉環(huán)。

代碼提交了就是全部嗎？

剛才提到的方案落地話題比較大，換一個(gè)小一點(diǎn)的話題。技術(shù)人員主要以寫(xiě)代碼為主，代碼提交只是工作的一部分，剩余的工作量還有很多。比如怎么交接、文檔是否易懂、如何修復(fù)bug等一系列相關(guān)問(wèn)題。同樣需要培養(yǎng)一個(gè)整體的、系統(tǒng)的思考能力。

在完成技術(shù)層面的提升外，還需要有心境上的轉(zhuǎn)換。主要包括責(zé)任心、自驅(qū)力和執(zhí)行力三個(gè)方面，它們應(yīng)隨著技術(shù)水平的提升而相應(yīng)的提升。

能力越強(qiáng)，其責(zé)任必然越大，責(zé)任心與能力應(yīng)成正比，能力再高的人，若責(zé)任心不足，企業(yè)是無(wú)法將重大的事情交給他的。責(zé)任不僅僅在于做好自己的事情，也在于敢于承擔(dān)更多的挑戰(zhàn)和職責(zé)。

平穩(wěn)的度過(guò)職業(yè)生涯早期后，自驅(qū)力的重要性就更加顯露無(wú)疑。被別人推動(dòng)去做事與主動(dòng)的高要求的做事，能力成長(zhǎng)的差距會(huì)愈加明顯。

今日事今日畢。雖然企業(yè)永遠(yuǎn)有做不完的事，但越盡早的完成一件事，才能盡早的投入另一件事。高效的執(zhí)行力與強(qiáng)大的自驅(qū)力相得益彰。

職業(yè)生涯早期看到的主要是工作愿景和個(gè)人愿景。

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

個(gè)人愿景則是獲得更高的薪水，享受更好的生活。

社會(huì)愿景也可以稱(chēng)之為行業(yè)愿景，它隨著閱歷的提高而逐漸展現(xiàn)。做開(kāi)源，寫(xiě)博客，參與分享甚至自己創(chuàng)業(yè)，都會(huì)承擔(dān)更多的社會(huì)責(zé)任，也會(huì)更多的獲得業(yè)界認(rèn)可，能更加正向的勉勵(lì)自己不斷向前邁進(jìn)。以社會(huì)愿景為最終目標(biāo)，可以更有效的促進(jìn)工作愿景以及個(gè)人愿景的達(dá)成。

分享一些我做開(kāi)源的經(jīng)驗(yàn)。在開(kāi)源的一兩年時(shí)間里，交流群和Github中被問(wèn)到很多問(wèn)題，提出很多質(zhì)疑，它們推動(dòng)著我在開(kāi)源的路上繼續(xù)前行。在幫助別人的同時(shí)，吸取社區(qū)精華，完善自己的項(xiàng)目，感覺(jué)收獲遠(yuǎn)多于前幾年的積累。

今天的分享就到這里，歡迎進(jìn)行討論。

現(xiàn)場(chǎng)分享視頻地址：http://www.itdks.com/dakashuo...

由IT大咖說(shuō)錄制