如何看待軟件開發 ？

題記

今年的總結主要想和讀者聊聊如何看待軟件開發，回答去年年終總結文末的問題。這個話題也比較大，每一個開發人員也都有本身的答案。筆者根據本身剛剛從業幾年的經驗說說本身的見解，做爲一個開發萌新，看法略短淺，可能會貽笑大方。歡迎你們指點。

軟件開發是什麼？

軟件開發是一個創造或者維護，應用，框架或者應用組件的過程當中涉及到的需求分析，設計，編碼實現，測試，bug 修復的過程。軟件開發是編寫代碼和維護代碼的過程。更廣義的來講， 軟件開發是一種人類思惟活動的體現 。

軟件開發與其說是搬磚，不如說是處理問題的能力，智商的體現。開發什麼並不重要，重要的是思考問題的角度和快速解決問題的能力。使用過的先後端和客戶端的編程語言以後，筆者感覺到會使用語言並無什麼，能用什麼語言解決多大的問題纔是關鍵。前端後端都有相應的職級，相同的職級，不一樣的開發崗薪資差距不大。職級的高低更多的展示的是一我的思惟活動能力強弱的體現。並且各個領域和方向，幹到高級開發都不容易，每一個領域都有各自的 roadmap，在一個領域深耕都須要靜下心來 2-3 年。誰能一直領先而且一直維持在金字塔頂端，都是很是不容易的事情。

廣義的來講，開發用什麼語言僅僅是一個進入這個行業的首秀，以後往下走，會接觸到不少其餘語言，如何修煉思惟能力纔是一個軟件開發技術人須要關注的東西。菜鳥和大神的差距在於有效時間的積累，常常有這種狀況，菜鳥和大神同時遇到一個同一個問題，哪怕是陌生的問題，大神也能夠很快的找到問題的本質。大神解決問題之後，說靠的是本身的「直覺」找到的突破口。但就是這種直覺就是寶貴的經驗，這就是菜鳥們須要用時間積累的東西。這種「直覺」並非玄學，是一種能力，經驗豐富之後帶來的快速解決問題的能力。

在筆者經歷過三端的開發迭代之後，綜合看客戶端，前端，後端，三端開發流程和工做內容都有相同的地方。開發流程三端都一致的。評審，排期，kickoff，站會，開發，肯定終版，提測，灰度，上線發佈。

各端都有 APM，都有監控性能的需求。不過架構實現方式不一樣。三端關注的點是不一樣的，客戶端和前端更加關注客戶爲主，用戶體驗，頁面打開速度等等。服務端關注點以服務爲主，服務性能，可用性，高併發，低延遲，io 讀寫速度，多活，跨機房等等。這裏可能會有讀者說鄙視鏈的問題，筆者認爲沒有必要對其餘端的鄙視。作純服務端的開發人員對圖形圖形和像素就不太敏感，讓他們來作一些前端動畫，可能比較難。作純前端的開發人員對後端的架構可能不太熟悉，讓他們設計一些大型的高併發系統，可能比較難。(考慮到讀者裏面有全棧開發，對三端都很是瞭解，因此這裏特地加了「純」字)讓作純服務端開發的寫前端，不必定寫的來；讓純客戶端開發寫服務端，也不必定寫的來。因此各端有各端的難處，能夠相互學習，可是不必鄙視。

綜上，軟件開發狹義的看，是實現需求到最終上線發佈的過程，廣義的看，是將人類的思惟活動固化凝結成軟件產品的過程。軟件開發的過程當中不斷的訓練人的思惟和發現問題解決問題的能力。

好了，至此我關於這個問題的答案都述說完了。接下來的行文邏輯和去年不一樣，筆者打算寫寫今年發生的一些「大事」，以及分享一些所見所聞所想和一些憋着也沒啥機會說只能放在總結裏面的話，有些是周圍朋友或者羣裏經常討論的問題，我對這些問題也都有本身的見解，寫成文字記錄下來。個人答案可能全錯，讀者看完若是能有收穫，這篇文章的目的也算達到了。

擁抱變化

過去一年被問的最多的就是「貴司被收購了，是否是要 XXX ？」，XXX 是周圍的朋友猜測的不少事情，例如，合併，裁人，N+1，離職……等等。從 2018 年 1 月到 2 月底宣佈被阿里收購，公司內部確實發生的很是多的事情，組織架構變化很大。被收購之後內部變化也很是大。固然這也都算是常規操做吧，畢竟收購之後有不少資源合併的流程。和筆者關係比較密切的一些人和一些事都發生了巨大的變化，也許由於年後正常人員流動吧，一個月內微信通信錄裏同事的公司備註更換了好多。一塊兒加班奮鬥到深夜的親密「戰友」離我而去，晚上大半夜還在公交車站一塊兒討論問題的戰友，次日醒來卻和你說要離開了。筆者是一個比較重感情的人，畢竟咱們是一個 team，一塊兒闖出來的「天下」，「出生入死」鍛造出來的鐵打的感情，說「分手」就「分手」了，內心確實很差受。當知道離開的緣由之後只能一聲嘆息，內心也只能祝福他在新的公司裏面大展宏圖。那段時間身邊的氣氛實在壓抑，因而筆者去了一趟日本，努力放下一切，一路沿着櫻花開放的方向，泡着溫泉。固然，越想忘記的事情反而越加記憶深入。如今 2018 年末了，回過頭來再看這段時光，對筆者影響只是朋友之間感情的影響，其餘影響基本沒有，組織架構的變化影響最大的是上層，工頭那一層，對咱們這些底層搬磚工和水泥工的影響不大，不老老實實搬磚，多想什麼呢？

關於自身技術上的變動也比較多。年頭的時候打算參與一我的工智能相關的項目。因而本身看了西瓜書和一些視頻，入門了一下人工智能。大多數入門知識還比較好理解，都是高等數學、線性代數、機率論的知識。筆者考研期間把這些知識都好好複習過，遺忘的很少，撿起來也快。後來由於一些組織架構的變動，沒能參與這個項目。2017 年比較火的技術是人工智能 AI 和區塊鏈，筆者在年初的時候也在 kindle 上看了 4 本區塊鏈入門的書，區塊鏈底層技術都不算全新的技術，只是它的設計和理念比較新穎。看完幾本區塊鏈入門的書之後，對底層加密技術比較感興趣，又去從新撿起了密碼學。看了 3 本密碼學相關的技術書籍。雖然筆者沒有投身區塊鏈行業，可是密碼學的知識做爲計算機的基礎知識，能擴展的領域也很是多。如今人們對安全的要求愈來愈高，網絡安全，信息安全，無一不和加密有關。到了 5 月份加入了新的項目組之後，定下了本身下半年的 KPI ，下半年的目標也比較一致和明確了。我參與了一個和網絡相關的項目，性能是重中之重，網絡耗時也是我優化的重點。HTTPS 若是慢，可能慢在哪裏？爲何會慢？和加密的密鑰套件選擇有什麼關係？TLS 1.3 爲何能使整個請求時間變短？QUIC 爲何在弱網環境下效果很好？蜂窩網絡是如何選擇基站的？蜂窩網絡中信號回落是怎麼一回事？這些問題我以前只有模模糊糊的答案，重度參與了這個項目，通過實踐之後，以上問題都有很是深入的答案了。通過幾輪優化，階段性的結果也獲得了業務方的確定。

2018 年一路學習和工做中的總結見博客博文 Archive 列表吧。回過頭來看，這一年收穫馬馬虎虎，在網絡相關的收穫很大。充滿變化的一年，我擁抱了變化。

職業生涯規劃和技術人的追求

關於職業生涯的問題，筆者曾經也迷茫過，也請教了很多大佬是如何規劃本身職業生涯的。筆者如今不迷茫了。

要想梳理清屬於本身的職業生涯規劃，須要先想明白做爲一個技術人的追求是什麼？知道本身心所向，目標明確之後，再指定職業生涯規劃就會很是簡單了。

一個剛剛畢業的應屆生，剛剛進入軟件開發的行業，不免會有一些迷茫，不知道本身想要什麼，將來的路怎麼走。有一位大師曾經這樣給我了建議，「畢業前 5 年(最長 5 年)，建議開發的各個方向都多多嘗試嘗試，找到本身真正感興趣方向，一旦找到這個方向之後，埋下頭來鑽進去 3-5 年」。這個作法對迷茫的同窗也許有效。對於剛剛畢業就打算進大公司的應屆生，筆者給的建議是，第一技能必定要專精。第一技能是進大公司的敲門磚，第一技能若是不夠專精，哪怕有 10 個附加技能也沒用。進大公司工做只是第一步，以後的發展都看我的規劃了，在作好本身本職工做的前提下，多餘時間努力鑽研感興趣的方向吧。

關於感興趣的定義：

若是隻是隨大流，學習最新的技術，這並非真的感興趣。筆者認爲真正感興趣的定義是，很是癡迷。有人打遊戲忘記了睡覺，這是對遊戲的癡迷。對技術的癡迷可能表現爲看書寫代碼通宵忘記了睡覺（固然不提倡不睡覺）。

找到本身真正感興趣的方向之後，就能夠開始努力是作到 TOP 。在本身精通的領域作到頂尖是重中之重。在大公司裏面，晉升是考察的你的專業性，技術面再寬，深度沒有到達下一級的要求，是沒法晉升的。以筆者爲例，移動端技能分數可能就是及格分多一點，前端和後端略懂，各打 30 分吧。這種狀況大公司可能都不會要吧，不要期望大公司招你進去一我的幹三我的的活，由於大公司徹底有能力招 3 個在各自領域都拿 90 分的人進來工做，這樣全棧就沒有多少優點了。大公司裏面晉升更多仍是靠專業性。

可是業餘的時候能夠看看其餘語言，吸取各自的優勢。在筆者沒有接觸 Go 語言以前，對協程徹底沒有多少感受，只是據說過，協程如何調度用戶態這方面幾乎一無所知。Go 語言爲何要這麼設計協程，爲了解決什麼問題？Go 是第一個實現協程的麼？誰是第一個實現協程的？Swift 能實現協程麼？若是不能，爲何呢？OC 能夠實現麼？如何實現？這些問題都是值得平時學習思考的。視野廣度能夠加深你對開發的理解，提高對行業的認知。

再談談技術人的追求，我做爲一個技術人的追求應該是一輩子修煉一個響徹江湖的"絕學"，做爲你的表明做，讓它成爲你行走江湖的名號。行走江湖，會耍的武器多，百般武藝，會使用的編程語言多，並非什麼傳奇，關鍵的是可否用你最擅長的武器一招致命。十年磨一劍，匠心獨運，就爲了給本身這技術一輩子一個交代。我也在以這個追求做爲我將來幾年的目標，努力去實現。

若是技術人的追求是快速賺錢，實現本身財富自由的夢想，還有一點必需要重視：站在風口的豬是真的會被吹起來的。快速抉擇風口的方向比努力更加劇要。筆者身邊在 2018 年發生了太多這樣的事情了，包括雷軍的創業回憶錄中也一樣提到了這一點。 努力向前當然重要，選擇有時候可能更加劇要 ！

有許多人問我相似的問題，「霜，你轉後端了，那以前寫客戶端的這 3 年的經驗不就浪費了？」「霜，你換方向之後，幾年都無法晉升，你介意麼？」「霜，你接觸後端的知識，後悔麼？」個人回答基本都是「不後悔」，如今還年輕，確實有不少試錯的機會，有些「錯」可能只有老了，回過頭來看，才知道。

年輕有的是大把時光，有的是機會，有的是方向，同時有的是試錯的成本，其實路根本沒有選擇，心是羅盤，處處重重迷霧，只能往前看。

關於技術換方向的問題，筆者以爲本身還比較有話語權，畢竟本身已經親身經歷過了。做爲過來人，給讀者們一些建議：

• 不到萬不得已，別換方向。新的方向上你是新人，一切都要重頭開始，換了方向之後，晉升和跳槽都比較麻煩，筆者已經深入的認識到了這個問題了！

• 若是爲了換方向而跳槽，那麼換工做不要降薪降職，薪水同樣的狀況下職級越低越好。這一條已經獲得了我周圍跳槽換方向同事的驗證了。

• 換方向之後，心態須要調整，你在原來方向上多是大爺，可是新的方向上，安心先作 2 年孫子吧。

• 在新的方向上，要給本身信心，信心比黃金更重要，寒冬也要堅持鍛鍊身體。更在新的方向上作好時間作規劃。

• 若是換了方向之後，職級還能提升了，請作好心理準備，牢記： 欲戴皇冠，必承其重 ！迎接挑戰吧。

• 順應趨勢可能比努力更重要。

2018 年行業現狀和所見所感

2018 年年初，阿里收購了餓了麼，年中，又將它與口碑合併了。2018 年年底，行業內一些小公司倒閉，大公司也開始按績效裁人，查考勤，實行 996 。下圖是網傳的一些裁人信息，固然真假不肯定，可是從側面能看出一下行業的趨勢。

當一個行業逐漸成熟起來，須要的人員應該是穩定的，不會再出現前幾年的一些泡沫了。程序員這一行招聘要會愈來愈高，由於須要在候選人中選擇最合適最優秀的人選來。技術人員如何提升本身的軟硬實力顯得特別重要。這一節想談談今年看到的一些現象和感想，下一節再聊聊技術如何提升。

今年筆者見到了很多公司被收購或者合併的狀況，如下內容並非針對某一個公司，請讀者勿對號入座。

A 公司被 B 公司收購了，B 公司須要對 A 公司資源進行整合，沒必要要的開發人員須要調整(裁人)。若是你是老闆，你怎麼裁人呢？最容易想到的就是績效差的先裁掉，末尾淘汰。那若是是資源整合呢？如何整合呢？最容易想到的是把重複的資源留下最好的一部分，其餘剩下的裁掉或者轉崗到其餘部門。若是中臺臃腫，那麼就先調整中臺。

小公司被大公司收購之後，影響最大的是小公司的基礎設施，小公司的基礎設施在本身的業務場景下使用的馬馬虎虎，可是一旦被收購之後，一些作的沒有大公司作的好的基礎設施都有被砍掉的風險。這裏並非否認小公司人員實力的問題，而是人員和資源配備上無法和大公司比。好比項目 C，大公司投入是 4 個專家，作 3 年。小公司作相同功能的項目可能就是一個開發作 1 年。從人員投入上就沒有任何可比性了。而後項目 C 在收購之後被砍掉了，把相關的開發人員安排到其餘項目，其餘項目若是是喜歡的還好，若是不是喜歡的項目，而且這位開發人員我的實力很強，可能就會考慮離職了。2018 年這種例子筆者見到了不少了。

收購影響最小的是業務團隊。大公司收購小公司，必定是由於大公司本身沒有覆蓋到被收購小公司的業務場景，或者沒有搶佔到大的市場份額。大公司想瞬間替換掉小公司的業務，短期內是不可能。哪怕是大公司把業務所有重寫，在徹底理解業務場景和需求的狀況下，也須要花大量的時間和人力物力。而且小公司這邊還在繼續業務迭代，大公司從 0 開始寫一套，還須要繼續追小公司這邊的新需求。徹底的顛覆性的重寫，這種作法的 OKR 是否夠高還須要評估。這樣看來，被收購的小公司的業務若是比較穩定，那麼對應的核心開發人員基本收購之後沒有什麼影響(注意是核心開發)。相比而言，基礎設施的核心開發人員，就須要面對轉崗到其餘「邊緣」部門或者不喜歡的部門，或者去業務團隊寫業務的選擇了。業務團隊核心開發的核心競爭力就是他對業務系統瞭解的比誰都清楚，業務場景早就瞭然於胸。

那麼結合如今行業的現狀，我分享一點本身的見解：

若是想成爲被大公司搶着「挖」的香餑餑，據我觀察主要有這麼 2 類人。一類是把一個領域作到極致，作到 95，甚至 99，100 分，一提到他就表明了這個領域或者方向，他是這個領域的領袖和領軍第一人，成爲這樣的人很不容易。這種人對應的 title 就是 XXX 高級技術專家。另外一類人是把某個產品作到極致。好比 APM，質量監控，容器調度，SOA，CI/CD，雲基礎設施等等。或者是公司某塊業務瞭然於胸，微信和釘釘的 IM 核心開發，淘寶天貓京東的交易系統核心開發等等。這些人也會被爭相被挖。乍一看後面一種人也許技術研究方面只有 85 分或者 90 分，可是業務熟練度上面分數更高。

以上 2 種人才都是當前大公司爭相挖人的香餑餑。固然，若是上面 2 點都沒有作到，也不能說你進不了大公司，好好準備面試，好好投簡歷仍是有不少機會的。

如何提升？

關於這個問題，周圍也有不少人問我，我自認爲本身並非好的榜樣，不少人執行力比我高不少。那我就談談我本身是如何在過去一年是怎麼提升的，和作的不足的地方給你們作反面教材。

過去一年我除了看技術書之外，還看的比較多的是極客時間的專欄。在上面買了幾個專欄。買的第一個專欄是陳皓老師的專欄(@左耳朵耗子)。這個專欄裏面的內容確實寫的很是豐富，而且很多內容是我自認爲沒有到達相應的層次無法產生共鳴的。陳皓老師創建了這個專欄的讀者羣，並提出了入羣要求，能堅持一年 ARTS 的人就能入羣。周圍朋友看了個人 github 上的 contribution 都會問，「怎麼這麼多 commit 啊？」 其實我就是想堅持一年 ARTS，人不逼本身永遠不知道本身的潛力有多大。

不過結果是我沒有堅持下來。給你們當了反面教材。ARTS 是 Algorithm、Review、Technique、Share 的簡稱，即每週至少作一個 leetcode 的算法題，閱讀並點評至少一篇英文技術文章，學習至少一個技術技巧，至少分享一篇有觀點和思考的技術文章。這樣至少堅持一年。在 2018 年下半年我基本作到了每週閱讀幾篇英文文章，學習並記錄技術技巧，分享多篇技術文章。可是 leetcode 算法題這塊沒有跟上。除去本身效率低下致使週末有加班，重要的緣由可能仍是本身「眼高手低」吧。leetcode 上的題按照難度劃分，easy 的題刷 1-2 道很快就 AC 了，一點成就感也沒有，medium 和 hard 等級的題目，提交了一下午所有都是 WA，挫敗感巨大，在自我否認中就逐漸放棄，再也不堅持了。2019 年準備繼續撿起來，但願到 2019 年年終總結的時候不會打臉。github 上的 repo 也創建好了，強行逼本身一下。但願讀者不是我這樣「眼高手低」。

若是讀者還在迷茫如何提升，不知所措的時候，那麼就別迷茫，先靜下心來按照 ARTS 的方法堅持一年吧，一年之後回過頭再來看看本身的收穫有多少。

若是有些讀者以爲提升到了瓶頸的時候，能夠看看本身的計算機基礎是否足夠紮實，足夠你繼續往上再建高樓。計算機基礎決定了上層建築的高度也進步的速度。

舉個例子，好比區塊鏈技術，若是計算機基礎很是紮實的人，掌握基本的區塊鏈技術會很是快，由於裏面的協議，加密技術都不是新的。設計理念是新的，看一遍很快也能學會。再好比換方向，一個 iOS 方向的開發者換到大前端方向，或者人工智能，或者後端方向，切換的成本有多大？若是基礎紮實，至少計算機基礎這塊的知識是無縫銜接的，都是通用的，零成本切換。再好比菜鳥和大神同時看一本技術書，大神用一上午就看完了，菜鳥看了一週。爲何會有這麼大的差距呢？由於大神看書，書中寫的大部分知識點早已經是本身內化的知識，看一眼就明白在講什麼，也不須要思考，直接看過去，遇到不會的再思考思考，一本書看下來可能就只有 2-3 處須要思考的地方，菜鳥看書就不一樣了，每一頁可能都有須要思考的地方，甚至每段話都須要思考，好比看算法導論這本書，書中會常常推算一些數學公式，而後寫「很顯然能夠得出」，這個結論對於菜鳥來講真的不顯然，菜鳥看到這一行的時候就會思考一上午，還不必定想的明白。大神以前推算過或者這個結論早就已經理解了，2 秒就過了這一行了。從看書快慢的例子裏很容易看出本身在知識點上欠缺的點，每一個人欠缺的知識點也不一樣。筆者建議 學習應該更注重的迴歸本源，計算機基礎真的很重要。

拿換方向來舉例說明，某同窗以前是 iOS 方向，如今切到了後端方向。如何在新的方向繼續提升？首先計算機基礎同樣要紮實，計算機組成原理，編譯原理，計算機網絡，算法和數據結構，操做系統，這些都必須很是熟。他們是你上層建築的基礎，基礎有多紮實，上層建築就能建的多高。

上圖中也說明了各個方向公共的一些技能，好比 Git 的使用，數據結構和算法，SOLID、KISS、YAGNI 設計原則，SSH，HTTP，HTTPS 協議，設計模式等等。這些基礎打紮實了之後，學習以後的路會走的更快一些，好比理解了跳錶的數據結構，看 Redis 源碼的時候，理解源碼會很是快，理解了圖論算法之後，再去看 PG 底層實現也很好理解。

上圖是後端的學習路線，最早須要熟練的是本身平常使用的語言，內存佈局，垃圾回收算法，語言特性等等。再是經常使用的包管理工具，經常使用的庫的源碼實現，以後再是瞭解數據庫，MySQL，PG，MongoDB。中間件，Redis、RabbitMQ、Kafka、ElasticSearch。Docker 和 K8s 的使用。Web 相關，Nginx，Caddy，GraphQL。熟悉上面這些之後就能夠往本身感興趣的領域繼續深度探索了。

至於其餘兩個方向，Front-End 和 DevOps 筆者沒有太深刻，就直接放圖吧。上圖是 Front-End 的 roadmap。

上圖是 DevOps 的 roadmap。

架構師的平常

這一年平時工做的時候有意觀察過架構師的工做內容。架構師的工做內容是對公司裏面每一個系統提出最適合最好的架構方案以及對系統各方面指標把控。架構師必需要對業務瞭如指掌，否則對系統設計不出量身打造的架構方案。這裏的架構方案必定是量身打造的，一個小公司的業務體量沒有大公司的體量大，若是用大公司上億的架構方案，明顯是浪費資源，因此架構方案會隨着業務體量發生巨大變化的時候產生變化。另外架構師對系統指標的掌握也必須瞭解，公司內每一個業務對系統組件的使用，對資源的使用，都是他們的工做範疇。筆者申請機器資源都須要通過架構師的審批，他們都會審覈是什麼業務，業務場景是什麼，是否合理。

架構師還具備技術前瞻性，一個好的架構是不斷隨着業務增加而不斷進化的。一個好的架構應該對當前業務有業務餘量的，對業務增加也有預判的，而不是當業務忽然增加了，架構適應不了，引發血崩式的崩潰。這方面的前瞻和預判也是一種能力！筆者今年就遇到幾回沒有前瞻性的技術改造，本身沒有作好預判，忽然到來的險情只能靠加班去緊急解決問題，若是作好了預判，能減小很多加班時間，系統運行的也更加穩定，演化的更加平穩。

筆者認爲架構師的工做要求比較高，視野也要求廣。若是沒有見過各個場景下比較比如較合理的架構設計，只靠本身沒有實踐的空想仍是不行的。畢竟在架構評審會上面須要他們對好的架構提出寶貴的建議。筆者嘗試對以前同事的系統架構設計「指手畫腳」，發現不少地方的設計是對業務場景的取捨，並不是是很差的設計。到最後也給出不了什麼好的建議。架構師確實很差當，對各類業務沒作到透徹的理解，對好的架構設計沒有實踐的經驗，基本就沒戲！

另外架構師關注點也比較高，並不是侷限在某一個技術點上，關注的更多的是收益。架構師的薪資爲何高，是由於他熟悉瀏覽器內核的每一句代碼麼？(這是舉個例子，固然不少架構師確實精通瀏覽器內核的每一行代碼)。其實並非，他們的價值在於幫公司解決了多大的問題。他們給公司創造的高價值對應了他們的高薪。他們更關注的收益，好的架構方案目的必定是能解決問題。而使用某個技術只是手段。使用這種技術能解決什麼問題，好在哪裏，收益是什麼，可否解決問題。筆者剛剛畢業那會更多的關注技術點上，視野比較窄。從只關注單一技術點到關注技術收益的轉變，算是程序員思惟認知的一個分水嶺吧。

架構師的看待問題和解決問題的思惟方式，很值得咱們去學習。

關於旅行

今年一共去了 5 個國家，日本、捷克、匈牙利、奧地利、斯洛伐克，十幾個城市，名古屋、大阪、奈良、京都、箱根、富士山、東京、布拉格、卡羅維瓦利、克魯姆洛夫、哈爾施塔特、薩爾茲堡、林茨、維也納、布達佩斯、布爾諾、庫特納霍拉、斯洛伐克，大城市，小城市都有。有人問我旅行對個人意義是什麼？首先固然是放鬆身心，釋放工做和生活上的壓力，其次是長長見識，看看世界。去發達國家看看有錢人的生活是怎麼樣的，探尋物質富有的人爲何還有這樣那樣的煩惱，去貧窮的國家看看窮人的生活是怎麼樣的，追尋物質貧窮的人是怎麼豐富精神生活的。有錢人有本身的煩惱，窮人卻也有生活的很開心的。人類的世界充滿了故事，充滿了有趣的事情。之後有人拿酒問我是否有故事的時候，我能夠和他聊聊世界上我見過有趣的見聞。最後是能夠結交一些旅友，來自各行各業的朋友，不一樣地方的人，你們有着不一樣的興趣愛好，各類膚色，懷着對世界的好奇之心，一塊兒探索着未知的世界。一家酒店的餐廳裏，坐着來自各個國家的人們，各類膚色，你們吃飯的方式都不一樣，有的直接用手抓，有的用刀叉，有的用筷子，有的用勺，說着各式各樣的語言。不一樣的信仰，基督，天主，伊斯蘭教，佛教。一個小小的空間裏面濃縮的是世界的縮影，在這個空間裏面將不一樣時區的人們包容在了一塊兒。凱撒大帝一輩子的名言也歸納了個人答案：i see，i come，i conquer。我用小小的腳步丈量着大大的世界。(今年旅行的見聞視頻都在本身 @halfrost 的抖音上了)

生活中偶爾和本身不熟悉的領域產生交集，也許能夠激發一些特殊的靈感。筆者也所以染上了在親近大天然的環境下去反思和總結一年的所做所爲。這兩年的年終總結也都是在旅行中完成的。逃離城市的喧囂，在一個陌生的夜晚裏，聽着蛙叫和雨聲，走進內心，去直視真我。

2019 年的夢想是去迪拜完成 15000 米跳傘，去沙漠坐駱駝。2019 年旅行計劃主要就是迪拜，歐洲和美國，去德法意瑞，看看歐洲列強們現在過的還好麼；去美國體驗體驗常青藤學校濃厚的學術氛圍；去迪拜看看白袍們有多麼奢侈的生活，撿一撿丟在馬路邊的「垃圾」，蘭博基尼，住一住七星級酒店。