如何看待软件开发 ？

题记

考虑到本系列文章有部分新的读者，所以关于本系列文章名字的起源就不再赘述了，见这里 《"星霜荏苒"名字诞生记》

今年的总结主要想和读者聊聊如何看待软件开发，回答去年年终总结文末的问题。这个话题也比较大，每个开发人员也都有自己的答案。笔者根据自己刚刚从业几年的经验说说自己的看法，作为一个开发萌新，见解略短浅，可能会贻笑大方。欢迎大家指点。

软件开发是什么？

软件开发是一个创造或者维护，应用，框架或者应用组件的过程中涉及到的需求分析，设计，编码实现，测试，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 年旅行计划主要就是迪拜，欧洲和美国，去德法意瑞，看看欧洲列强们如今过的还好么；去美国体验体验常青藤学校浓厚的学术氛围；去迪拜看看白袍们有多么奢侈的生活，捡一捡丢在马路边的“垃圾”，兰博基尼，住一住七星级酒店。

最后

好了，2018 年的【星霜荏苒】就到这里了。如有任何异议或者想讨论的地方，欢迎和我交流。

2018年4月1日，于日本 Japan

2018年12月5日，于布拉格 Praha

GitHub Repo： Halfrost-Field

Follow: halfrost · GitHub

Source: https://halfrost.com/halfrost_2018/