題記
作為技術人，到年底都會進行一次自我反思或者總結，回過頭來看看這一年自己成長了多少。筆者也不例外，同樣打算從 2017 年開始記錄自己的年終總結。雖然這種總結的文章不算純技術文章，但是為了避免記流水賬，所以想盡腦汁想以一種新穎的方式展現在讀者面前。於是打算用一個大家比較關心的問題來貫穿全文。不出意外，以後每年的形式都會如此。一年一個巨集觀的問題。文章中的經歷保證都是筆者百分之百親生經歷的，有成功的案例也有失敗的案例，當然讀者自身的情況也會與筆者不同，各位讀者可以根據自身的情況來取長補短。文章中的一些觀點僅代表筆者個人的一些看法，如有不妥，歡迎提出來一起討論和批判。
筆者在網上的中文筆名是“一縷殤流化隱半邊冰霜”，常常被人簡稱為“冰霜”、“霜菜”、“霜”。這一年一篇的年度文章既然這麼特別，那麼就給這個系列文章取一個特別的名字吧。在中國的文化中，四個字的成語讀起來能更加有內涵，成語裡面也必須帶“霜”字和光陰意思，通過大量的搜尋以後，就定下了這個系列的標題的名字 —— 星霜荏苒。
【解釋】星霜：星辰運轉一年一次迴圈，每年秋季始降霜，因以批歲月。指歲月漸漸流逝。
【出處】唐·溫庭筠《寄崔先生》：“星霜荏苒無音信，煙水微茫變姓名。”
好了，本系列的文章該說明的地方都說明完了，以後每年就不做此說明了。正文正式開始。
技術更迭是有加速度的
從 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 年的【星霜荏苒】就到這裡了。如有任何異議或者想討論的地方，歡迎和我交流。
2017年12月30日，於悉尼 Sydney
Reference：
Vue 全家桶 + Electron 開發的一個跨三端的應用
Go 初學者的成長之路
空間搜尋文章合集
GitHub Repo：Halfrost-Field
Follow: halfrost · GitHub
Source: halfrost.com/halfrost_20…