很久之前有一部電影叫黑鷹墜落，里邊有一個場景是一個打字員在那兒說，因為我會打字，所以我不用上前線。這事放在現在看就比較搞笑了，畢竟現在絕大部分人都會打字。

我覺得在未來，編程會像英語、電腦一樣是一個很通用的技能。首先是編程的門檻越來越低，從 Fortran, Pascal, C  到 Java, Python，編程語言其實是越來越簡單的，即使你不是專業的軟件工程師，學會用 Python 寫一些簡單實用的腳本其實也是一個很輕松的事情，更何況還有 Excel, IFTTT, VBA 這類更簡單的工具。

另外，未來的工作對編程的需求也越來越強，你需要做更多自動化的工作，你需要把大量的不同來源的數據串起來完成你的工作，編程會成為你最趁手的一門工具。最后，我覺得編程是一種很好的邏輯思維訓練方式，畢竟任何詭辯、欺騙和逃避這種非理性的手段，在編程面前都是走不通的。

軟件是一門很特殊的學科，首先是學習編程的成本很低，你只需花兩三千元買一臺電腦就夠了，如果你要自學物理、化學、生物的話你就得有一個價值不菲的實驗室。其次是軟件的反饋很快，你有一個新的想法，快則半個小時，慢則一周就能驗證你的想法是否有效。而在化學領域，你能在一個月內驗證完一個想法就已經謝天謝地了。

這個學科另外一個好的風氣是分享交流極度地開放，各個軟件公司都非常樂于分享自己的技術、自己遇到的問題和解決方案。這對于傳統行業是很難想象的。

這樣帶來最大的好處是只要你想學，你愿意投入你的時間、精力和意志，那么你就很有希望在這個領域做出你自己的成就。

對于我來講，我是因為高中時化學競賽保送上了大學，就直接選了化學系。其實我在高中的時候就開始接觸編程，也對它很有興趣，只是苦于沒有電腦，也沒有足夠的時間能花在上面。到了大學之后，我就把自己的大部分業余時間都撲在上面了，只是因為不舍得保研的名額，又繼續上了學校的研究生，不過根據自己的興趣，選了計算化學方向，研究的課題應該可以歸到計算機輔助藥物設計這個領域。

在研究生階段，我比較自豪的一個成就就是教會了幾乎所有同學用 Python 來編程，加速了很多日常工作。不過有點可惜的是，我最后沒有拿到學位，就離開了學校，開始了自己在軟件行業的第一份工作：金山實驗室。

我一般會把程序員分為初級、中級和高級。他們的區別在哪兒呢？初級可以在別人的指導下完成工作，中級可以獨立地完成工作，高級不僅僅可以指導別人的工作，而且可以很好地提煉自己的方法論，用這些方法論去影響別人，幫助他們成長。而架構師，他更多的職責則應該是確保一個項目不會因為技術的問題而失敗，比如是不是伸縮性不足導致大量用戶涌入時支撐不住、靈活性差導致功能很難添加，設計過于復雜導致開發持續延期，技術選型錯誤導致成本和穩定性出現問題，等等。

我們公司采用了 buddy 制度，簡單來說就是任何一個新員工入職，都會指定一個 buddy ，在入職的前三個月，你不管什么事情都可以問他，這個制度對新員工快速平滑地融入團隊幫助很大。如果你的公司沒有這個制度，你可以考慮跟你的上級申請一個 buddy, 你的 buddy 也許很忙，那么你可以考慮一下定期（比如每天中午花半個小時）跟 buddy 核對一下之前遇到的問題。這些都是可以讓你快速融入團隊的辦法。

一般過了 2 年左右，很多人就不再能直接從項目或者周圍的同事身上獲得成長了，這個時候一個比較好的手段是跳出現在的圈子，多參加一些本地社區的活動，多參加 QCon 這類的技術會議（當然看直播或者視頻也行），看看這個也就的標桿長什么樣，他們在解決什么問題，他的知識體系有哪些是你缺少的。我很認同的一句話是“參加會議的目的不是為了學到什么，而是為了知道要學習什么”。找到一個好的標桿，相信你在職業生涯的前面 5 年會一直快速成長。

方法其實很多，每個人都可能有不同的選擇，甚至說在不同的團隊，你的做法也可能會不一樣，下面僅就個人的經驗講講我自己的看法：

首先一點是要把手邊的活做扎實，如果這點做不到，你的意見比較容易被人輕視和質疑。

其次是要經常參與項目中的設計與技術相關的討論，勇于發表自己的意見，但這個時候要學習一些討論問題的常識，比如說對于別人的方案，要先去接受而不是拒絕，然后從兩個方面去考慮，一方面是這個方案有什么漏洞，禮貌地提出潛在的漏洞，等待對方拋出他的觀點。另外一方面這個方案有什么可以延伸或者擴展的地方，是否可以根據對方的方案拋出一個更好的方案。對于自己的方案，不要過于強勢，畢竟很多事情一個問題有超過一個正確答案，自己的方案沒選上也要有平常心。

對于團隊來講很重要的一點其實是擔當，也就是你是否愿意為某個小項目整體來承擔責任，當然這也意味著你需要再代碼之外做很多事情，包括很多溝通、妥協和持續跟進的事宜。這一點對于那些有志于在管理或者產品方向有進一步發展的人尤其重要。如果你在很多事情上表現出不錯的擔當能力，相信你的上司一定不會埋沒你這種人才。

從我自己來看，我覺得我把自己定位從開發轉為架構的一個時間點在于，我不再是在尋找一個問題的答案，而是在從問題的一堆答案中評估哪個對我們更合適，這個時候我感覺到我已經能充分駕馭這個問題，而且也有信心來面對未來更多的挑戰。

如果你要走架構這條路，我有如下的幾個建議：

首先是要多讀一些書，其中最基礎的是類似于重構和設計模式這種書，你需要知道很多小尺度級別上的問題解決技巧（如果你要做導演，你首先要做得是能熟練地把一個句子翻譯為一組鏡頭），以及這些作者梳理問題的方式，反過來問一下自己，如果讓你來寫設計模式這本書，你有哪些知識點可以寫？你如何組織這些知識點？如何讓大家接受你的觀點。

看完這兩本書之后，非常推薦你看一下 Martin Fowler 寫的《企業應用架構模式》和 Eric Evans 的《領域驅動設計》這類書，他能擴大你的視野，專注于更有意義的問題，而不是設計模式究竟有多少種這種缺乏意義的問題。有一句話叫，“如果要成功，就要遠離那些廉價的娛樂”。類似的，對于軟件工程師來講，要想讓自己更強，就要遠離那些廉價的爭論（vim vs emacs, linux vs unix, redhat vs debian, 這些爭論其實并沒有太大的價值）。

其次，你要對大量開源軟件的實際特性有深入的了解，容量究竟多大？高可用怎么做？如何擴容？是否易維護？這些知識部分來自網上的各種測試和經驗文章，部分還要來自你的親手測試。作為架構師，你的每一個技術選型都是在挖坑，給你的開發、測試、運維團隊挖坑，而你的作用之一，就是保證你的團隊能夠在你的幫助下從坑里走出來。

另外，要解決很多大尺度的問題，你需要從很多同行去吸收經驗，我個人的經驗就是，閱讀每年兩次 QCon 和 ArchSummit 架構相關的幻燈片，先只看題目和問題部分，自己想一想解決方案是啥，然后再看一下演講者給出的解答，通過這種方式來淬煉自己的思維，豐富自己的工具箱。我想提醒的一點是，由于軟件行業還遠不成熟，所以一個架構師會長期跟進一個項目，這就導致了一個架構師如果不主動去練習的話，一輩子也做不了幾個架構，至少相對于建筑專業的結構工程師來講，我們每年的項目缺少少很多。你做的架構越少，你就越容易自滿。

最后，我希望你是一個終身學習者，不管多忙，一定要規劃你的學習時間，一個星期也許不用太多，幾個小時即可，但這幾個小時一定要用在刀刃上，所以最好是哪些需要幾十個小時甚至更多時間才能弄清楚的課題，而且一直要堅持到這個課題結束。千萬不能是學一點這個概念，遇到新事物，就馬上轉移方向。如果你有這樣的習慣，我建議你先把新想法放到一個池子里，等手邊的課題學習完，再到池子里邊撈一個新課題來繼續學習。不過關于學習，這個是一個很大的話題，就不在這兒闡述了。