【星霜荏苒】 - 程序員如何在技術浪潮的更迭中保持較高的成長速度？

時間 2019-11-16

原文原文鏈接

題記

做爲技術人，到年末都會進行一次自我反思或者總結，回過頭來看看這一年本身成長了多少。筆者也不例外，一樣打算從 2017 年開始記錄本身的年終總結。雖然這種總結的文章不算純技術文章，可是爲了不記流水帳，因此想盡腦汁想以一種新穎的方式展示在讀者面前。因而打算用一個你們比較關心的問題來貫穿全文。不出意外，之後每一年的形式都會如此。一年一個宏觀的問題。文章中的經歷保證都是筆者百分之百親生經歷的，有成功的案例也有失敗的案例，固然讀者自身的狀況也會與筆者不一樣，各位讀者能夠根據自身的狀況來取長補短。文章中的一些觀點僅表明筆者我的的一些見解，若有不妥，歡迎提出來一塊兒討論和批判。前端

筆者在網上的中文筆名是「一縷殤流化隱半邊冰霜」，經常被人簡稱爲「冰霜」、「霜菜」、「霜」。這一年一篇的年度文章既然這麼特別，那麼就給這個系列文章取一個特別的名字吧。在中國的文化中，四個字的成語讀起來能更加有內涵，成語裏面也必須帶「霜」字和光陰意思，經過大量的搜尋之後，就定下了這個系列的標題的名字 —— 星霜荏苒。vue

【解釋】星霜：星辰運轉一年一次循環，每一年秋季始降霜，因以批歲月。指歲月漸漸流逝。git

【出處】唐·溫庭筠《寄崔先生》：「星霜荏苒無音信，煙水微茫變姓名。」程序員

好了，本系列的文章該說明的地方都說明完了，之後每一年就不作此說明了。正文正式開始。github

技術更迭是有加速度的

從 2010 年開始，被定義爲移動互聯網的元年，移動開發也是從這一年開始逐漸開始火爆的。筆者也是從畢業以後加入這個浪潮的。聽說移動開發火爆之時，理髮師經過幾個月培訓之後也能夠拿到月薪1，2W的薪水，可見那個時候對移動人才的飢渴程度。可是到了 2014 年末開始，移動開發的入職要求迴歸理性，要求逐漸提升，到如今基本大公司社招也再也不招高級如下的移動開發了。面試固然也比以前幾年難度提升了很多。BAT 的面試可能會考察前沿技術，熱修復和跨平臺，底層技術，LLVM + Clang ，基礎技術，WebKit 和 JSCore 。身邊一部分 iOS 開發也逐漸開發轉寫 JavaScript 了。國內 iOS 開發者也可能會以爲大前端時代的到來，對本身技術的衝擊。（固然國外的 iOS 開發者對這些並不感冒，國外的玩法仍是原生開發。）繼續回到國內的行情，當大前端的一些東西逐漸吞噬 iOS 開發者的開發領域的時候，也許尚未等你們熟悉或者精通前端各類框架的時候，這時 AI 又出如今你們視野中了。機器學習，深度學習一大堆的概念如潮水般涌來。面試

2012 年末到 2013 年初，有大批創業公司如雨後春筍般的出生。到了 2014 年末，也有大批的公司沒有活過那年的冬天。到了今年 2017 年，依舊有大批的創業公司出生又倒下，如各個單車公司。在資本的市場裏就是如此的殘酷。算法

周圍的一些同事也有出現焦慮的，說實話，我也焦慮過。風口技術巴不得一年一變。年初的區塊鏈和三大前端框架可能尚未玩轉，年末當即就被 AI 又碾壓一波。一位前端大神這樣和我解釋到，「技術就須要時刻的跟着，前端若是幾個月不跟新技術，看到新技術可能會陌生。若是守着老技術幾年不變，呵呵，可能再瞭解新技術的時候，前端框架已經換了新天地了。」也許這個回答帶有一些誇張成分，可是從側面也能看出前端這幾年的發展速度之快。編程

你們也能夠回想一下近幾年技術的更迭，也許也能感覺到，技術更迭是有加速度的。後端

焦慮的起源？

我仍是以 iOS 開發者來舉例。經常會在 iOS 開發者羣裏出現的 3 個圖。前端工程化

一個是 iOS 開發沒人要了和 iOS 開發又有人要了。這 2 幅圖經常被做爲一個梗出如今各個討論羣中。緣由爲什麼？由於 iOS 開發的一部分需求被前端開發者承擔了。國內不少小公司招聘要求上也直接寫的要求會 JS 、RN、Weex 等技術。直接致使不會 JS 的 iOS 開發就沒人要了。往往蘋果對跨平臺或者熱修復進行「封殺」或者任何舉措的時候，原生開發都會刷一波 iOS 又有人要了的表情。前端也許一樣會有焦慮，焦慮也許來自於對三大框架的掌握程度，若是隻精通一個框架，找工做遇到了精通三大框架的人也會心虛。

這也是焦慮來源之一，不會某些知識點會致使找不到工做或者找不到好工做。

另一個焦慮可能就來自於「倒灌」吧？

每一年風口技術變化極快。好比今年 AI 技術之火爆，直接致使的狀況是應屆畢業生拿到 AI 的 offer 之後，薪水直接無情的秒殺工做2-3年的人。工做2-3年的人就算一直跟這些新技術，也會感受到壓力。因此也就有了上面的第二張圖，求你別學了，咱們跟不上。

畢竟不多有人能保證天天有大塊的時間都在學習新技術，除去完成公司的工做之外，加上可能的加班時間，人回家也會疲勞，也須要休息。天天都有大塊的時間用來學習新技術的時間也就不是不少。

人與人學習的速度和掌握的程度也都不一樣，通過相互比較之後，就會發現本身比別人學的慢學的少，若是這樣強行比較，確實也會產生本身不如別人的焦慮感。

如何高效學習？

面對技術的更迭之快，咱們應該如何高效的學習保持競爭力不被淘汰呢？這塊筆者經歷了近 10 個多月的成長之後，對這個問題有必定的發言權了。請聽我把個人這一年的經歷和心得體會慢慢道來。

我先從心理上談起，最後談到個人學習方法。按照這個思路來，但願能讓讀者能有所收益。

1. 正確看待焦慮和迷茫

程序員一旦焦慮或者迷茫之後，就會對成就感的得到大大下降。長久這樣就會致使動力不足。可是現實產生焦慮的緣由通過前面的分析，也是客觀存在的。那咱們應該如何面對呢？

我是這樣面對的。

在技術的更迭變化過程當中，若是一味的跟新技術，那你是否想過，追隨新技術的究竟是爲了什麼？是爲了跳槽或者轉崗？仍是爲了提升薪資實現人生理想和自我價值？這兩個理由都是正確的，須要注意的一點就是不要盲目追隨新技術。一味地盲目追隨只會致使最終淪爲技術的奴隸。咱們須要作技術的主人，更加從容的面對技術的變動。

如何選擇？若是在不轉崗的狀況下，在沒有目標的狀況下，去學習一些本職工做中可能用不到的知識，可能就有點「盲目」。這些知識學習的過程當中也許不夠高效。不高效的學習又遇到了別人高速的成長，一比較，新的焦慮又會產生。這裏我有切身的體會。

如下是我本人的失敗的案例，與君分享。

在今年7月份的時候，我買了一本 Haskell 的書，打算研究研究這個函數式編程的鼻祖。也是接觸了 FP 之後，對 Haskell 產生的濃厚的興趣。我選擇點 Haskell 技能點徹底就是爲了興趣。工做中也基本不用（能夠說是徹底不用）。轉崗也是徹底不可能的，若是去拉鉤等招聘網站上面搜「 Haskell 開發工程師」，內心會涼涼，國內一個對應的崗位都沒有。（國外是有一些，可是也很是少）。我買的是下面這本書：

電子書我看了這本

書上寫的打不倒的空氣人，學不會的 Haskell。我學習 Haskell 進度很慢，由於確實實踐的機會太少了。看完書確實對 FP 的理解上了一層，可是用它來開發的機會就不多。Haskell 是一門很好的語言，可是我學習它的曲線確實太痛苦了。中間走了不少彎路。（彎路，錯誤的路線就不分享了）後來組長和我說了一些話，他認爲不通過大量實踐的學習是低效的。事實證實我學習 Haskell 確實是低效了。我沒有大量的實踐。學是學了，只不過進步速度很是慢。收穫也有，可是挫敗感也很多。打不倒的空氣人，我沒有被打倒，明年有空再繼續學。

學習永遠沒有錯，錯的是選擇了低效耗時耗精力的前進方向。

這裏筆者的建議仍是優先學習公司項目裏面用到的知識，深挖技術痛點。有多餘的時間再去橫向瞭解其餘的。和 T 型人才同樣，先專注門，再擴寬廣度。先廣度沒有深度就會致使你連工做都找不到。

再說說迷茫，迷茫的來源有二個，一是看不到本身對公司的價值，二是看不到本身將來發展的路。

先說迷茫的來源一，看不到自身的價值。不少人天天在公司寫業務，俗稱「搬磚」，天天都搬，感受一點長進都沒有。回過頭來看框架部門的人或者本身部門的研究員，天天都在研究或者作一些框架或者工具。當有大量的人使用的時候，就會頗有成就感。而且認爲業務沒啥技術含量，業務裏面的邏輯和流程在換了一家公司之後就沒有任何優點了。這種想法實際上是不對的，是錯誤的片面的。如何正確的認識和改變這種想法在下一節裏面會更加詳細的討論。

再談談迷茫的來源二，看不到將來的路在何方。這個迷茫我以爲來自於對自身的定位不明確。一位老師和我說過，畢業後的頭5年，你能夠去選擇各類開發，前端後端或者移動端，能夠隨便選。這是爲了什麼呢？就是爲了找到本身感興趣的和本身的長處而且打算一生一直作下去的方向。若是你還看不到本身將來發展的路，那麼能夠考慮把眼界放的更廣一點，去找尋本身真正感興趣的方向。所謂真正感興趣的，是指如同熬夜打遊戲同樣絕不睏倦，若是某個方向你能作到不是公司強迫你加班，本身寫代碼寫到深夜或者通宵也絕不厭倦，那麼這必定是你感興趣的。方向一旦肯定就不會迷茫，朝着目標狂奔吧。

2. 業務和架構如何選擇？

程序員裏面也許會存着這樣的鄙視鏈，寫架構的鄙視寫業務的。這種鄙視是有失偏頗的。

首先，絕大多數的公司的收入來源是來自於公司的業務。除去一些極少數的公司。寫業務的同窗沒必要以爲業務沒有存在價值，大家應該明白，大家寫的業務是替公司賺錢的。

固然，能在公司裏面寫內部框架或者工具的同窗，技術必定積累到必定深度了。框架和工具沒有無緣無故的產生，它們的誕生都是解決問題或者痛點的。要麼解決開發中的痛點，要麼爲了提升開發效率。試問若是沒有對開發有必定的瞭解和認識，如何去深入的理解和感覺這些痛點？不理解它們，也作不出能解決問題的框架或者有用或者好用的工具。

我認爲能寫框架或者工具的，必定在技術上有必定積累，而且能理解和看清開發中或者業務中的一些痛點。因而乎開發出瞭解決這些問題的東西。

至少目前國內的大多數公司都是沒法缺乏寫業務的。小公司爲了生存能夠缺乏寫框架和工具的，可是不能缺乏寫業務的。大公司更加是須要寫業務的。目前國內好像還不存在不寫業務的公司。若是純寫框架或者工具給其餘公司使用，以此賺錢，那麼這些也就成爲了這個公司的業務。

再談談對架構師或者更高級的職稱的理解。

在咱們的 BU 裏面專門有一個架構組，裏面的人全是 P7 架構師以上級別。他們的工做內容是什麼呢？就是提供能解決當前開發痛點方案的人。我與他們交流過，他們雖然對業務沒有理解到每行代碼逐字逐句的代碼行，可是對公司整個業務流程，數據流轉，有一個總體的認識。他們對業務的認識更加深入，比咱們只負責單一業務理解層次更廣。他們在此基礎上還能解決開發中的難點和痛點，對 BU 部門的業務發展還能提供本身的思考。架構師們還具備自主發現業務價值的能力。

也許你們會認爲架構師不寫代碼，可是他們須要出解決方案。解決方案必定程度上比寫代碼還要難。解決方案的靈感來源於什麼？來源於對公司業務的深入理解和技術的深厚積累。缺乏對業務的理解，提出的方案可能就是不徹底適合這個公司的。缺乏對技術的深厚積累，提出的方案性能可能就不是最好的。

我以爲你們不要藐視寫業務這一環。若是你在公司是寫業務的程序員，請不要放棄本身。公司把一個業務交給你，你是否能按時高效的交付是你當前須要考慮的問題。當你對當前業務玩的很溜了，對這塊有深入理解了。能夠再去考慮理解去理解你所在的產品線，這一條業務線的流程。在理解流程的同時去考慮當前公司的架構設計爲什麼如此設計？有什麼優勢有什麼缺點？哪些能改哪些不能改，哪些是歷史遺留問題形成的？

只有這樣日積月累的積累，當你積累了大量業務經驗，以及大量業務場景下優秀合理的架構設計之後，你就能向着架構師的方向前進了。

我堅信一點，公司花錢僱一個架構師來工做，工做的職責必定是替公司設計並完成架構方面的一些事情。俗話也說，沒有最好的架構只有最適合的架構。架構師的價值就在於此，在深入瞭解公司業務需求之後，針對公司的業務，量身定製一套最好最適合的架構。

在公司裏面，個人工位旁邊坐了一位 P8 高級算法專家，在我不知道他的職稱以前，我觀察到他平時的工做內容就是把各類算法落地，切實的解決公司裏面的痛點和開發難點。往往有產品或者開發來問他某個邏輯時，他都能瞭如指掌。我一度覺得問的邏輯都是他參與開發的。直到以後我知道他的職稱之後，更加感覺到算法專家的價值所在。

在非學術工業生產中，算法專家的價值在於利用各類算法來解決公司中各類業務痛點。我看到他就用了各類圖論算法加上機器學習解決實際生產中智能調度的問題。對他所負責的業務瞭解之深入。（固然，在學術研究中，算法專家的價值應該是在於創造或者改進算法效率吧）

在 iOS 領域，你們也都認識迪哥，迪哥就是架構師，和迪哥交流以後，迪哥的平常工做內容是對部門人員的組織，對技術選型的決策，對業務的組織，對架構的方案，因此我認爲架構師的工做是以解決業務問題，推進業務增加爲基礎，在此之上改善公司的架構，使之能對外提供更加優秀的性能，並具備對人、技術、業務的組織統籌能力。

一個好的產品，必定是能完美解決用戶痛點的。如何理解和發現業務的價值也是一種能力。至少這種能力是架構師必備的能力。我目前也在業務中修煉，在深入理解公司的業務的同時，也在考慮如何設計架構，爲什麼要這樣設計，有沒有更好的設計？我不能說我之後必定會成爲架構師，可是至少我認爲我在朝着架構師的方向努力着。

3. 技術分工的不一樣和統一

筆者今年前端和後端都有涉及。前端算是離用戶最近的一端。並且如今處於大前端時代，你們可能會發現前端能幹的活愈來愈多了，往前，能夠涉及到客戶端，日後能夠涉及到 Nginx。前端工程師的技術棧也變得很是廣闊。後端工程師反而會顯得沒有前端那麼忙碌了。

前端的數據來源來自後端，前端更加偏重 UI，交互，設計。後端更加偏重接口性能，數據的正確性。可是隨着雲基礎設施的逐漸完善，後端的基礎設施都挪到雲上了，這部分的配置和管理都變得異常的輕鬆，這一切都交給雲了。

如今前端框架和瀏覽器發展的日新月異，業務上一部分邏輯都直接在前端作掉了，即便如今先後端分離，前端在公司中承擔了愈來愈多的角色了。有這樣一個笑話：大前端工程師對後端工程師說，大家後端不就是一個寫接口的嘛，吐吐字符串。後端工程師對大前端的工程師說，大家前端不就是搭搭頁面嘛，前端就是一段漂亮的字符串。雖然他們說的都不許確，可是也從側面抽象了他們工做的內容。

因此前端和後端分工不一樣，可是他們仍是合做的關係，缺一不可。

在 Airbnb 女博士朱贇的小密圈裏看到一個問答

提問：做爲一個後端開發，想請教安姐，如何去提升本身的駕馭複雜業務邏輯的能力、設計能力和抽象能力？若是接手一個穩定性不夠好的系統，如何收斂複雜度，逐步提升穩定性？

朱贇老師很是幹練和漂亮的給出了這個答案:

駕馭首先要作到通曉。瞭解全部業務邏輯的前因後果，知道一些典型系統設計方案以及其針對的問題，還有優劣比較。接觸過一些實際的系統。在此之上，纔有可能把合適的設計套用到當前的業務邏輯上，把現有的業務邏輯抽象成一個已經存在（部分）解決方案，或更經典的方式。

接手一個穩定性很差的系統，若是沒有足夠的時間從頭設計、徹底重構。那麼至少要知道影響穩定性的幾個關鍵要素，而後根據重要性、緊急性和解決問題須要的資源（時間、技能集、人等）進行優先級排序，逐個擊破。對於全部的改善型動做，確保有適合的評測和監控，這樣可以知道不一樣的措施效果究竟是怎麼樣的。

結合以前咱們討論的架構和業務的關係，一樣也是統一的。無論是前端仍是後端，無論是業務仍是架構，這些分工的最終目標都是同一個：讓技術推進業務增加，實現公司盈利翻倍。寫框架或者工具的同窗寫出更好的框架和工具提升開發效率，寫業務的同窗利用技術讓業務穩定性和邏輯更加穩定可靠。最終的目的都是爲了推進公司的業務增加。我認爲看到了這一點，就能認清本身在公司裏的價值。在找到自我價值和實現公司價值的時候，就不太容易迷茫，成就感的得到會更加容易。

4. 高效的學習方法

講到此，我就用我今年一年的經從來談談我認爲高效的學習方法是怎麼樣的。順帶也總結一下今年一年個人工做內容和收穫。大概爲了3個階段。

第一階段，iOS 階段

我是今年2月份，年後來到這裏的。來到公司之後交給我第一個的任務就是解決項目中和內存泄露相關的問題。由於項目裏面都是用的 RAC ，這塊組裏的同窗對它裏面原理理解不夠深入，很容易寫出內存泄露的代碼。我來了之後就把組裏的全部和內存泄露相關的問題都找出來。以後組裏又開始了組件化的工做，因而我又開始了研究並實現適合組內使用的路由方案。

後來公司內部在推跨平臺方案——Weex。我也很榮幸的被指派了研究這塊內容。從閱讀源碼中，我也學到了不少不少。到這裏就到今年5月份了。

第二階段，前端階段

6月份之後，組裏接了一個新活，我也主動申請了去寫這個活的前端頁面。因爲在瞭解了 Weex 之後，順水推舟的就選擇了 Vue 這個框架。因而開始寫 Vue 相關的項目了。

在短短2個多月的項目迭代中，我學到了不少東西。公司內部的各類腳手架用法，前端開發流程，前端頁面埋點，前端發佈流程，前端的項目持續集成，頁面性能監控 APM ，前端工程化，組件化... 這些在 iOS 中一樣都是存在的，可是我就用了幾個迭代就都接觸了。同期的相比其餘同窗開始說學習前端，個人進度是比較「神速」的，至少我在整套都學習完成之後，他還在摸索 JS 過程當中。

雖然我如今前端的資歷還很淺，可是當個 P4 寫寫基本的業務迭代仍是能夠勝任的。我也深深的知道，前端的內容很是多，僅僅幾個月只是一個皮毛中的皮毛。可是至少讓我體驗了一把前端開發中的平常。

我認爲我前端這塊學習是高效的。爲什麼高效？由於我是在實踐中學習的。利用公司真實的項目鍛鍊本身，真的學習特別高效。天天項目中遇到的問題，上下班在地鐵上都會頗有目的的在網上查詢解決辦法。學習目的很是明確。我比天天看語法的不實踐的同窗進步要快不少。

關於前端入門，我能夠提供一下個人路線。

首先固然是瞭解 JavaScript 和 Css。入門方法仍是看書。我看了一下這些書：

《JavaScript 權威指南(第6版)》
《JavaScript 高級程序設計（第3版）》
《JavaScript DOM 編程藝術第二版》
《ES6標準入門（第二版）》
《Effective JavaScript 編寫高質量 JavaScript 代碼的 68 個有效方法》
《Speaking JavaScript》
《你不知道的 JavaScript 上卷》
《你不知道的 JavaScript 中卷》

以後就是大量的實戰項目訓練了。參與公司業務迭代的「蹂躪」，很快能學會不少東西。幾個迭代下來就能玩通整個流程。

固然我爲了增強訓練的搶斷，本身在 Github 上也練習。當時對 Electron 框架也很是感興趣，就寫了這個開源項目Vue 全家桶 + Electron 開發的一個跨三端的應用。

除此以外在公司內部還認了3個師父，把我前端技術帶着飛。一個是知乎前端大V，@敖天羽，這個妹子的 title 很是多，餓了麼前端吉祥物，天哥，天尊……數不清，她一畢業就在前端的架構組工做，能力很是強。再次我也感謝一下她對我這種入門級小白的問題耐心的解答。在成長的路上解答了不少問題。（這裏也能夠安利一波妹子在知乎上開了 Live ，對前端前進路線迷茫的同窗能夠去聽聽，必定能解答你的一些疑惑）

另一個師父是和我同一天入職的朋朋，他也是前端開發，技術很是強。我和他關係也很是好。平時有前端的問題也會問他。

最後一個師父是我大學同寢室的，前端也很厲害，不懂的問題也會向他請教。

在此也感謝上面3個師父的答疑解惑，把前端未入門的小白 carry fly 了。

小結一下這段前端學習，大量的項目實踐 + 主動有目的的看書學習 + 有大神指點 = 高效的學習。

第三階段，Go 階段

7月份跟着組長一塊兒轉寫後端業務了。短短几個月，成長也很是迅速。Go 的基本用法都很瞭解了。個人 Go 的學習成長路線也總結記錄了，感興趣的同窗能夠看這篇文章《Go 初學者的成長之路》，這裏就再也不贅述了。

轉寫後端業務之後，語言關不是多大問題，感受比較頭疼的就是後端的整個生態體系。東西多的如潮水般將我淹沒。

咱們組負責的業務都和地理位置有關。因此我把空間搜索這塊進行了深入的研究。全部的研究成果也寫成了文章放在了這裏《空間搜索文章集合》。

參與的項目迭代至今，全部的後端開發流程，Thrift RPC 框架 nex，Docker，k8s，ELK日誌，Redis，Huskar SOA 配置，GoProxy 配置，ETrace 監控，MaxQ 延遲消息隊列，Eless 發佈，Workflow 工做流，PostgreSQL 使用，Google S2……這些基本使用都掌握了。眼看着本身開發的服務 QPS 逐漸成長，內心就比較有成就感。這個項目就像本身的孩子同樣，疼愛有佳。

除了本身看書學習之外，項目中遇到各類技術問題也都是組長和組員替我答疑。也是帶我飛的節奏。若是本身學習，本身摸索，要想掌握上面的這麼多東西，不知道要多久才能弄懂。

小結一下這段後端學習，一樣也是，大量的項目實踐 + 主動有目的的看書學習 + 有大神指點 = 高效的學習。

以上的這些經歷就是比較成功的經歷，相比 Haskell 的學習，明顯進步「神速」，在解決公司項目痛點的同時，也快速學習提升了大量的知識。回想起組長以前說的，在公司的項目裏面去實踐是成長最快的。我也利用了一年的時間驗證了這句話真實性。

5. 總結

程序員如何在技術浪潮的更迭中保持較高的成長速度？個人答案就是在公司的項目裏面去實踐是成長最快的。首先業務的迭代排期會讓你的學習不拖拉，在排期中必需要完成指定的任務，這對學習進度有了很是好的保證。其次，實際項目中的實踐能讓你對語言的熟練程度，語言的生態環境，開發過程，查找 bug 流程，監控各個方面都有實踐經驗。並且實際項目中還能讓你遇到各式各樣的坑，坑踩多了就成長了。正確的學習方式也應該是將學習與具體業務場景結合起來，幫助公司利用本身掌握的技術開展業務服務而創造價值。如此看來，這樣的成長必定是最快的。

有一位計算機的大神建議程序員每一年成長的速度至少是一年多學習一門陌生的語言。從今年的結果來看，我是完成了。

程序員在從業幾年之後，視野不該該僅僅侷限在本身的開發語言中。能夠超脫開發語言，放開視野，從更高層次去想一想問題。固然筆者以上的這些思考在水平更高的人看來也許水平通常。水平更高的人也必定是這樣一步步的走過來，直到最後能指點江山，他們的想法能對整個行業產生影響。以上就是我今年一年技術之外的一些認知。所有都來自我本身親身實踐的「寶貴經驗」。但願讀者看到這裏能有一些收穫。

固然每一個人成長的方式都會有所不一樣，我只是提供了一種我通過實踐驗證了之後發現可行的方法，若是讀者自身就有更好的方法，歡迎讀者也分享出本身更好的方法，這篇文章就當是看個人年終總結。若是讀者自身也對成長缺乏一些方法，那能夠考慮試試這篇文章裏面提升的方法，共勉。

6. 將來

組裏業務上又開始用 Python 了。這門在今年火透半邊天的語言，明年我也好好學學。除此以外再把 Go 再精進精進。

最後

一年前有一個 P9 的阿里大佬問過我這樣一個比較哲學的問題：「你做爲程序員已經開發了這麼多年，你是如何看待軟件開發的？」，當時我回答說，「你想問前端開發仍是 iOS 開發？」，答曰：「你能不侷限在開發語言之中麼？從宏觀的角度來談談你對開發的定義，流程這些方面本身的看法」。當時我一會兒回答不上來，並非說不出來，而是以爲這個問題太寬泛了，很差回答。直到如今接觸了不一樣語言，不一樣職位的開發任務之後，我就對這個問題有了本身的答案了。問這種問題，從答案的深淺也許就能看出一我的的水平深淺了。若是對軟件開發沒有幾年的磨鍊，沒有足夠寬的知識面和深度，這種問題答出來的答案一答出來確定是比較淺顯的。這就比如你已經精通了高數之後，考一個小學生解一元一次方程。無論他如何解這個方程，用什麼方式，你一眼也能看出來他的水平。同理，上面的問題也是一個站在高處的大神，無論你回答什麼答案，在他的資歷看來，你的答案的深淺就能大概看出你的資歷有幾斤幾兩。

不知道讀者看到這裏是否內心已經有比較完美的答案了呢？這個問題筆者打算留到明年，做爲 2018 年【星霜荏苒】的話題。

最後的最後，說一點最近的體會。有一本神書，《Clean Code》，中文翻譯是代碼整潔之道。這本書筆者最近有意無心的又拿出來翻了翻。再讀第二遍，第三遍或者甚至第四遍的時候，每次閱讀的體驗都不一樣。讀第一遍可能因爲本身資歷不夠，能和書做者產生共鳴的地方並很少。更多的是在閱讀書中的文字和代碼，體會做者的意圖。固然這也是最基本的。可是我最近發現讀第二遍或者第三遍的時候，和書做者能產生更多的共鳴了，共鳴就來自於平時本身的開發過程當中，書中的舉出了一些例子就是本身親身經歷的，或來自於重構一個功能，或來自於絞盡腦汁的設計一個架構，或來自於某個特殊需求，種種親身經歷都會從新浮如今腦海中。一部分書中的內容我以爲我已經內化爲本身的東西了。固然還有一個部分沒有共鳴。

一遍遍的讀一本書，在程序員成長的各類階段都會有不一樣體會。開始會以爲書好厚，內容很枯燥，可是直到你經歷了不少之後，會發現這本書其實很薄，回過頭來看這本書就像本身的不一樣階段的回憶錄，裏面的不少內容你都親生經歷過了。這也許就是自身水平的成長之路。這也算是自身成長最直接的物質體現。

好了，2017 年的【星霜荏苒】就到這裏了。若有任何異議或者想討論的地方，歡迎和我交流。