前言

大家好，我是光源。

我算是一个倾诉欲比较强的人，我的一些感悟、我学习到的东西、我碰到的开心或丧气的事 我都喜欢向朋友倾诉或者写成文字。

只是写成博客的话，不免需要照顾读者体验成本较高，因此现阶段更喜欢偶尔发在朋友圈或记录在私密的日记里。

但今天，此时此刻我坐在浦东图书馆的安静的人群中，忽然觉得想写点什么，于是便有此文。

一、追寻最（学）佳（会）实（偷）践（懒）

前阵子跟组内同学 one on one 的时候，同学问我，是不是一个希望一切都在轨道上、追求严格的纪律性的人，因为我日常会把事情说得很结构化、时间节点会给得特别严谨。

我的回答是，不是，我是在追求最佳实践，如果知道怎么做事最优，那么就没必要留下可能会发生误会、可能会留风险的空间。换言之，我在偷懒，我不愿为不该发生的事情花费精力。

先谈谈偷懒。

假如我们将事务划分为「短期」和「长期」两种分类的话，那么短期的事务往往需要的是敏捷高效，干就完了；而对长期事务来说，维护成本可能会远大于执行成本。

那么如何降低维护成本呢？显然，一个井然有序的系统的维护成本是远小于一个杂乱无章的混乱的系统的。

同样做一件事，有秩序的体系里你只需要花费 1% 的精力，但在一个混乱的系统里可能花 10% 的精力还不一定能把事情做好。

所以不管是生活还是工作，让自己的环境尽量有序是一种「节能」方式。

但这样的话说出去难免会有点冰冷，仿佛像没有感情的机器。过于强调纪律性会给人一种纪律性高于一切的误读。

是的，不管多木讷的人，人本质上是追求轻松自由的，它先天与秩序相悖。如果周遭都是刚性的各种条例束缚，没有人能受得了。就我自己而言，我希望团队氛围是「轻松自由但不散漫」，即保住基本盘是有序的，细节保持弹性。

如何理解基本盘？举个例子，我们提倡弹性工作制，但弹性工作制的 baseline 是跟你协作的同事的日常节奏，比如有晨会至少要参加下晨会。（有一些特例，某些公司比较内卷会比较加班时长，这种就别参考同事的节奏了，赶紧投递简历给我来我们这边吧）

如何理解基本盘之上的弹性？比如做一件事，事前有计划、事中阶段性反馈把控风险、事后能落地有产出 —— 这些足以把事情做好。至于做事过程中，你是早来早走还是晚来晚走、你是线上参会还是线下参会…… 只要不违反公司条例，都不太紧要。适当得留有一些弹性或者说人性化，是能够让人觉得舒服继而发挥出更好的战斗力的。

当然，保证合理的有序只是「团队管理」这块的偷懒心得，日常做事这块还有很多小技巧。

大家好，我是光源。

偶然在微信读书里瞥到这个书名不禁有一些好奇，尝试看了几页发现还蛮有趣的。

作为非游戏从业人员，对于游戏开发本身就有一些好奇，又是一本讲编程模式的书 —— 不会太钻技术细节，一些思想还可以触类旁通沿用到非游戏程序设计中。

书籍开篇是介绍了作者自身对于游戏开发的经历和思考，非常赞同作者的一个观点是讲设计模式的书有很多，讲游戏开发引擎设计、渲染等技术方向的书也不少，唯独讲怎么好好做（游戏的）程序设计的书特别少。

我的共鸣在于之前看过的设计模式相关书籍都执着于设计模式本身，致力于将设计模式的细节讲得形象具体，而相关的使用场景、例子只是一点附赠品 —— 这样的叙述方式没错，但写出来的书很容易变成《代码大全》之类的工具书，缺乏了一些联系实际的感染力。

本书的可贵之处在于不仅联系实际、用实际问题引入对应的设计模式将设计模式本身说得明明白白，同时作者也是一个非常资深的专家级别开发者，介绍了设计模式的概念后，会去探索和扩展使用了设计模式之后的程序设计问题。

比如我们熟悉的观察者模式，作者先从「解耦」的角度阐述我们为什么需要观察者模式，然后又从实际应用的角度提出「维护观察者列表时如何处理线程安全问题」和「大量的内容动态分配要如何规避」。

又比如单例模式，对于单例模式作者从章节开头就表明，我们学习单例模式最需要学习的是「如何避免滥用单例模式」—— 稍有经验的开发者应该理解这个才是正确的态度。

还有状态模式。虽然以前也有在实际开发中用有限自动机去处理复杂业务，但在本书中，作者会一步一步拆解有限自动机的构建和思考过程，同时提出用于解决「多状态场景」的并发状态机、解决「状态复用」的层次状态机和解决「状态回溯」的下推状态机 —— 对于未接触过游戏编程的程序员来说，这些经验还是非常宝贵的。

从实际问题出发引出设计模式的，又基于实际问题提出专业从业者如何优化和解决，这些经验可以直接复用到日常开发中，对于初级到资深开发都非常有启发和参考价值。下面是读后感和读书笔记。

大家好，我是光源。

不知不觉已经 6 月份，计划年初要完成的事还未完成「年初」就已过去。自年后以来工作上投入度非常高，失去了几乎所有业余时间但也收获了一些认可，算是在新环境新工作里稳定下来（距离去年入职时间也过去半年多了，谈不上「新」工作了，哈哈）。

在这段时间里有一些新的思考，记录成此文。

一

最近正是高考。我们年少时应该都有过这样的幻想：假如我们当初有 xx 那么勤奋我们肯定能考上更好的大学、假如我们在高中时不贪玩一定能考得更好…… 但年岁渐长，我们渐渐懂得很多事重来多少次都是一样，我们的认知、我们的习惯、我们的性格、我们处理事情的方式决定了我们那一刻只会做出同一种选择。

内向者很难变得口若悬河活跃外放，好动者很难学会心无旁骛地应对枯燥的练习，怯懦者很难从容应对各种挑战。

时间给我们以智慧，让我们渐渐懂得自己能做什么和不能做什么。当然，有大毅力者绝对可以通过科学的方法和大量的练习突破自身的桎梏，但对于普通人而言，认清自己能力范围、与自己的优势劣势和谐相处并非是坏事。

回到我自身，因为去年 10 月底更换了工作平台，这半年来一直在调整使用时间和精力的方式期望能符合我自己的生活节奏。所得的收获是，在没有保证足够休息时间的前提下，我的精力并不足以在工作之余做其他事。

以前给自己定计划时总把工作之外的时间排得满满的，虽然「仁慈地」排了半个小时中途休息时间，但实践下来，工作之后就算有时间也无剩余的精力去使用起来。

接受自己不是超人吧，我对自己说。

抱怨并没有什么用，当初接受这个 offer 时就已经做好足够的心理建设，且工作是真的忙并不是磨洋工。

我可以做的是如何是适应环境并超脱这个环境。（说起来还有点小兴奋？）

可以从两个方向做优化，时间和精力。

大家好，我是光源。

不知道何时起「幸福」和「快乐」这些美好的词汇逐渐离我们远去，生活的周遭充斥着各种各样负面的信息：房价高负担好重、某某公司又裁员了、每天工作好久好累、养孩子压力大每天都好焦虑…… 当我们打开脉脉、打开微博、打开论坛，各种焦虑简直要把我们吞没。

人无远虑必有近忧，为当下和未来担忧固然是没错，但生活不能这样下去，在阳光灿烂的日子里还是希望能露出笑容。

就在我思索如何去改变时，突然想起好几年前看过的一个公开课《哈佛大学公开课：幸福课》，尽管细节已经忘记，但是看视频时的那种内心平静感却记忆下来。我想，是时候再刷一遍了。

这门公开课是讲什么的？

顾名思义，它主要围绕着「幸福」这个词展开。

我们来到这个世上，到底追求什么才是最重要的？塔尔博士（教授这门课的讲师）认为幸福感是衡量人生的唯一标准，是所有目标的最终目标。

「幸福」并不玄乎，它属于积极心理学的范畴，可以用科学的方式去研究。公开课中塔尔博士像一个老朋友一样将自己的经历和观点娓娓道来，引用的资料都有权威的研究和论文作为依据。

那么它是用来给我们加油打气的鸡汤么？当然不是。鸡汤之所以被称之为鸡汤，是因为鸡汤只有鼓舞士气的作用而无具体实操的指导，只能给我们在心理上做一次短暂的按摩其实没有卵用。

而幸福课是可以实操的。它告诉我们睡眠和爱情的重要性、如何去解决负面情绪、如何面对压力、如何让爱情天长地久等等 —— 我觉得是在教我们如何好好地生活。

我特别喜欢这门课的场景布置，很像 TED 的演讲会场，黑暗的背景下一个不刺眼的舞台，讲师像冥想老师一样给你安静的力量，你会不知不觉放松下来听他讲述。

有几点让我特别有共鸣（以至于让我在几年后的现在还记得）。

第一是运动对情绪的重要性。当身边有朋友情绪不好或身体不好时我总会建议他们去运动下，特别是互联网行业，有时候运动对坐了一天椅子的身体也是一种释放。对于我个人而言，运动更是一种良药，不管生理上还有心理上都给我很多力量。当然我的感悟不够有依据，公开课中讲师是分享了相当多的资料并给出如何运动的建议。

第二是冥想。几年前看完公开课后我曾经一度迷上冥想，各种找冥想的书看。而大家熟知的乔布斯也是冥想的爱好者。虽然我始终不得要领最后放弃，但冥想的益处我是想当认可的。

第三是触摸、爱情和睡眠的重要性。脱离「触摸皮肤」这个限定，简单的拥抱、握手都是有益的，都能给我们力量。而睡眠则不必多说，身体和精神并不是分离的两个东西，身体不好会导致精神萎靡，精神差则身体也会出现各种病痛。

第四是完美主义。「完美主义」这点感触太深了。曾经很多次我尝试自己去做一个应用，结果在设计交互和视觉时就各种万般纠结最后甚至开始怀疑 idea 本身是否值得去做 —— 每每如此我总是叹息，「该死的完美主义」！

还有其他东西已然忘却。

写到这里，我忽然有一个念头，那就是虽然我不记得幸福课的一些细节，但它对我却影响至今。比如对运动、睡眠、爱情的看法（惭愧的是明知晚睡不好却没能坚持早睡早起）。

毕业后的几年，明显感觉压力大了焦虑多了，幸好我还有这剂良药。

这也是我推荐给大家的目的吧。

准备再刷一遍哈佛幸福课，为了防止忘记细节，这次可能会边看边记录一些笔记。《哈佛大学公开课：幸福课》在网易公开课里可以看到，每一集都非常长，假如有朋友看不下去视频的，可以后面直接看我的笔记。

非常欢迎有同好可以交流下。

大家好，我是光源。

近来关于 Kotlin 的文章着实不少，Google 官方的支持让越来越多的开发者开始关注 Kotlin。不久前加入的项目用的是 Kotlin 与 Java 混合开发的模式，纸上得来终觉浅，终于可以实践一把新语言。本文就来小谈一下 Kotlin 中的空处理。

一、上手的确容易

先扯一扯 Kotlin 学习本身。

之前各种听人说上手容易，但真要切换到另一门语言，难免还是会踌躇是否有这个必要。现在因为工作关系直接上手 Kotlin，感受是 真香（上手的确容易）。

首先在代码阅读层面，对于有 Java 基础的程序员来说阅读 Kotlin 代码基本无障碍，除去一些操作符、一些顺序上的变化，整体上可以直接阅读。

其次在代码编写层面，仅需要改变一些编码习惯。主要是：语句不要写分号、变量需要用 var 或 val 声明、类型写在变量之后、实例化一个对象时不用 “new” …… 习惯层面的改变只需要多写代码，自然而然就适应了。

最后在学习方式层面，由于 Kotlin 最终都会被编译成字节码跑在 JVM 上，所以初入手时完全可以用 Java 作为对比。比如你可能不知道 Kotlin 里 companion object 是什么意思，但你知道既然 Kotlin 最终会转成 jvm 可以跑的字节码，那 Java 里必然可以找到与之对应的东西。

Android Studio 也提供了很方便的工具。选择菜单 Tools -> Kotlin -> Show Kotlin Bytecode 即可看到 Kotlin 编译成的字节码，点击窗口上方的 “Decompile” 即可看到这份字节码对应的 Java 代码。 —— 这个工具特别重要，假如一段 Kotlin 代码让你看得云里雾里，看一下它对应的 Java 代码你就能知道它的含义。

当然这里仅仅是说上手或入门（仅入门的话可以忽略诸如协程等高级特性），真正熟练应用乃至完全掌握肯定需要一定时间。

二、针对 NPE 的强规则

有些文章说 Kotlin 帮开发者解决了 NPE（NullPointerException），这个说法是不对的。在我看来，Kotlin 没有帮开发者解决了 NPE （Kotlin: 臣妾真的做不到啊），而是通过在语言层面增加各种强规则，强制开发者去自己处理可能的空指针问题，达到尽量减少（只能减少而无法完全避免）出现 NPE 的目的。

那么 Kotlin 具体是怎么做的呢？别着急，我们可以先回顾一下在 Java 中我们是怎么处理空指针问题的。

Java 中对于空指针的处理总体来说可以分为“防御式编程”和“契约式编程”两种方案。