箱猫日和

2020年初，个人开始尝试一种新的日常任务管理的方式：GTD（Getting Things Done）。对于我来说，GTD其实并不算一个新的事物，几年前就尝试过，当时还用了一个以GTD为卖点的软件，软件的名字有点忘记了，只记得使用GTD管理事务有种束手束脚的感觉，以致于最后放弃了。 重新拿起GTD，一方面是因为自己一直使用的RTM（Remember The Milk）在2019年有点荒废，毕竟自己花了钱的，不用有点浪费，另一方面，觉得自己平时管理任务的方式需要改进。个人之前就了解过与一些任务管理相关的方法论，比如说在做计划前把自己心里想的事情全部写出来，给自己减压之类。还有任务最好按照S.M.A.R.T原则进行细化、量化等。这些方法本来没有问题，但是只能算一部分的解决方案，没有成为一个系统的方法论。 于是乎找了GTD相关资料。GTD有书，比如说无压工作之类的。个人按照一篇日文的读写笔记学习了GTD的主要方法论。 个人认为GTD的一个核心，是写下任务之后，怎么处理这个任务。这里说的处理不是“完成”任务，而是怎么分类，怎么列出，怎么管理的问题。刚才提到做计划前把自己心里想的事情都写出来。在GTD中，这些事情都被写入一个叫做Inbox的任务列表中。Inbox类似邮箱，是一个任务第一个被放入的地方。不管你在做计划前，还是突发奇想，心血来潮，在你忘记之前，请写下你的任务。 把你心里所想的东西全部输出后，接下来逐个处理这些任务。如果你在处理过程中发现新的任务，原则上请加到Inbox最后，之后再处理。从Inbox中处理这些任务时，首先判断是否可以立刻行动，如果2分钟内能解决的任务，就立刻行动。你可以想象，假如大部分任务都是2分钟内能完成的话，那么你的Inbox的任务就是一个普通的任务列表，从上到下一件件处理。 如果不是2分钟内能解决的，你需要判断这个任务是不是比较复杂的任务。比较复杂的任务指的是需要多个步骤才能完成的任务，也就是判断是不是类似S.M.A.R.T里所说的足够小，可以实施的任务。比较复杂的任务被放到“项目”的列表中，不算复杂的任务被放到“待办任务”。把复杂任务和普通任务分开之后，你可以直接从待办任务列表中接着处理你要的任务，而不是卡在某个没有被分解的大任务上。 在分发任务的时候，除了待办任务列表和项目列表之外，还有直接丢弃，之后会做的任务列表以及委派给别人的多种方式。在处理Inbox里的任务时，实际上已经把任务进行了分类。我一开始是按照主题，或者说内容分类，比如学习，个人，工作等。这样有一个问题，就是你不知道哪些是接下来要做的任务。在GTD中，你直接有一个待办任务列表，你只需要关注这个任务列表就行了。 对于项目列表中的任务来说，你需要分解并把其中某个子任务加入待办列表中。如果你没法分解，这个任务就不是项目。如果你加入不了待办列表，说明你这个任务现在还不是时候，你应该放到之后会做的任务列表中。这个之后会做的任务列表，作用是把存放你暂时不想做，或者需要时间孵化的任务。那些某天你要做什么的事情，你需要使用日历，而不是任务列表。日历上精确了哪天你需要做什么事情，个人理解任务列表上的任务倾向于没有明显的执行日期。 在分类和分解任务之后，你不会有“我忘记了什么”，“接下来该做什么”的疑问，因为答案就在你的面前。当你有新的想法或者任务之后，把任务加入Inbox，然后按照上面的步骤再执行一次。如果你严格按照上面的步骤执行的话，你不会感觉有压力（记忆上的，工作上的等），因为你把接下来要做什么开始管理起来了。 为了更好地管理你的任务，你可以尝试给你的待办任务，加上tag，这些tag可以是表明任务执行的场景，或者某种关键字，然后可以进一步分类任务，并按照场景筛选任务，按部就班地完成任务。另一方面，你需要定期清理你的任务。比如说个人感觉待办任务不能太多，虽然可能没有结束时间，但是仍旧会给人一种压力。除了常见的优先级，场景分类之外，将任务数保持在一定数量可能更好。在之后再做的任务列表中的任务，如果自己多次判断不会做的话建议直接删除。 GTD的方法老实说，并没有特别依赖TODO工具的功能，你可以用一个纸质的笔记本完成上述的流程。当然，有功能更强大一些的TODO工具肯定更好。比如说，我在Remember The Milk里面，使用Smart List代替普通的List筛选待办列表的任务。筛选的条件如下 1.待办列表里的Action 2.项目列表中的任务的子任务，并且带有next-action这个tag 满足上面一个条件的任务即可显示在Smart List版的待办任务中。这样就不用从项目列表移动任务到待办列表，而且你点击子任务可以看到关联的项目任务。这种列表+tag的管理方式比单纯列表的方式要灵活一些。当然你不能忘记你的目的是完成这些任务，任务管理的目的是没有心理负担并且快速地列出你接下来要做的事情。 最后，虽然个人还调整自己管理任务的方式，但是核心的内容没有变化，并且GTD让我能够没有压力地Getting Things Done。如果你觉得自己被各种事情搞得焦头烂额的话，建议试一下GTD。

转眼之间2019年已经过去，2020年已经到来。在还未正式开始上班之前，个人想小结一下2019年自己技术相关的学习与感想。 2018年下半年的时候，突然奇想开始实现raft算法之后，个人感觉自己的技术视野一下子拓展了开来。特别是之后补充了学习自己不擅长的多核编程，逐渐看得懂Java并发库中的实现，并撰写了一些分析的文章。个人觉得并发算法如果你只是去看代码，你很难一下子理解代码在做什么，你需要循序渐进地分析和理解，在这其中自己尝试去实现最有效果。 因为觉得自己的这些文章，可以分享到自己一直看的《开发者头条》上，所以就尝试了放了几篇，比如说有关ReentrantLock的三篇实现分析。很幸运，几乎都出现在了次日的精选文章上。之后有图书编辑联系我是否有兴趣写书，于是我花了4个多月写了300多页的书。现在书还在编辑中，内容暂时不能公开。不过对于我来说，是一个很好的输出自己技术能力的一个机会。 写书的同时，其实我仍旧在寻找和尝试更好的实现raft算法的技术。这期间，学习了C++11下的多线程编码，以及尝试了Golang和Rust。从结论上来说，个人都不是很满意。C++的缺点比较明显，难。新版本的C++就是不断加新语法，而且是在没有简单易懂的依赖库机制下。写C++仍旧是必须从零开始的感觉，对个人开发来说很花时间。 相比C++，Rust要好很多，有crate，有标准的测试，有编译器保证你的代码不出现C/C++各种奇怪的问题。但是Rust的Lifecycle机制导致并发算法的代码很难写，越是复杂的代码越是容易编译不过。如果与编译器做斗争的话，我还不如退一步写C++，因为我知道我在做什么。个人知道Rust仍旧在发展，或许将来可以满足我的要求。 Golang是一个看起来不错，但是实际深入之后放弃的语言。我对Golang的协程很有兴趣，查了很多资料，也基本理解了协程的目的、做法以及长处短处。协程的短处是一方面，另一个让我放弃的原因是Golang在Memory Model的部分，文档第一句话是把程序员当笨蛋的赶脚（虽然Golang明显就是为那些入了Google但是不精通C++的人开发的），所谓的Memory Model也只是介绍了Golang提供的并发工具，给人的感觉就是C语言的翻版（你可以想想Google的C++ Guideline里尽量不用C++特有的功能，而是与C兼容的部分）。综合考虑了一下，个人项目里不是很想使用这种矫枉过正的语言。如果工作上要用，则是另外一回事情。 编程语言方面，2019年个人学的Kotlin可能是最好的了，在Java上做加法，特别是extension function，property的delegate等等（当然，也有协程）。个人觉得，比起解决语言痛点（C++对象生命周期）和大肆做减法（Golang对C++的做法），解决业务上的痛点和引入其他语言优秀的语法（C#的property delegate）可能更好。因为构建一个不太过严格但是又不是太过宽容的模型很难，Rust的生命周期管理难以处理复杂场景，Golang的全面协程化导致运行模型的不灵活。老实说，个人觉得这里面也有这两个都是命令语言的原因，如果是函数式语言，使用起来不会有这些问题。 说到函数式编程语言，不得不说现在编程语言不断在融入来自函数式语言的概念，从Scala到Java的lambda，从C++的lambda到Rust天生支持函数式。函数式编程语言的思维方式除了可以简化遍历，还有数据有无（Option/Some/None）和专注于正常流程的异常处理方式（Golang的C语言处理方式绝对是一个反例）。有空学习一些函数式语言的内容将来肯定会有一些收获，毕竟将来多范式编程语言会原来越多。 另一个和函数式编程语言相关的是ReactiveX，个人在2019年年末的时候花了两个星期的时间重新学习了一下（以前学过一次，太难放弃了）。个人觉得如ReactiveX所说，ReactiveX编程方式确实可以作为程序的主要处理方式，而不是命令式语言的从上到下的处理方式。这里面有ReactiveX所对应的异步编程的原因，也有命令式语言在复杂问题上的抽象不足（比如Golang的协程无法处理同时IO处理，必须退化为CSP编程方式）。顺便说一句，ReactiveX一开始来自C#，然后发展到多语言。这其实说明好的思路与语言以及背后的公司没有直接关系。 2019年另外一件事情是，与ReactiveX同时找到了一个框架Vert.x，综合考虑了一下，这可能是我想要的东西。当你把网络，文件，DNS等IO的部分全部异步化之后，基本上和协程没有区别了，而且作为类库形式比直接语言内置的感觉灵活性更好。2020年如果我有空的话想把xraft重写一下，至少把xgossip的核心部分尝试重写一次。 最后，2020年个人的目标，是继续学习一些个人比较重要的东西，比如说 SSTable MerkleTree STM（软件事务内存） 多核编程 等等。  

在去年实现我的Raft实现，考察过一些Raft算法的实现，包括Golang的一些实现。基于Golang的实现给人的第一感觉是，不知道有哪些协程是“持续”运行的，比如说监听网络请求，快照生成等等。而且由于CSP模型不关注发送者和接受者导致数据追踪比较困难，在没有IDE的情况下你可能几眼都看不出数据到了哪个模块的哪行代码。个人不确实是不是开发者的问题，导致这个网络程序架构那么松散，还是说CSP模型下的程序都那么松散。 由于个人长期在Web后端开发，对于MVC模型以及处理复杂业务逻辑的分层架构、组件化和依赖注入都比较熟悉，但是在开发一个传统意义上的网络程序时，还不确定什么是最佳架构。 假如用类似Web容器的做法，即每过来一个请求，开启一个thread或者使用线程池的话，程序逻辑可以采用分层架构。即使请求入口采用非阻塞IO的做法，比如说用Netty，程序逻辑也可以做在Netty的pipeline或者单独开线程处理复杂任务。但是，网络程序与很多没有额外线程的Web后端不同，会有定时任务，会有比较复杂的异步处理，所以可能一开始做成类似事件驱动模型可能更好。 个人在实现xraft时，用类似事件驱动的方式处理定时任务，各种外部的请求，把接受和发送等IO操作交给了Netty。整体上类似JavaScript，但是我把耗时的快照生成与应用发在主事件线程外，严格来说有一些区别。使用事件驱动除了理解起来简单之外，一些多线程下的数据访问问题利用单线程的线程封闭解决掉了。 如果问这种架构是否有改进空间，个人认为是有的。但是多线程下数据访问是一个难点，比起全局锁，个人更看好STM（软件事务内存）。除了数据访问，逻辑的封装也需要考虑，还有比较棘手的组件间双向访问问题。 在进一步找寻解决方案的时候，个人先找到了Cassandra所使用的SEGA，一种基于Stage驱动的架构模式。一个Stage绑定一个queue和相关处理逻辑。复杂逻辑被拆分成多个Stage，从第一个Stage执行到最后一个Stage。类似逻辑可以复用Stage。 老实说，这和Actor模型很像。Actor有一个Mailbox，Actor的内部根据收到的消息进行不同的处理。Actor同时其他一些特点，比如说树一样的管理结构，失败处理，热部署等等。类似组件间双向访问问题，Actor可以通过名字访问来解决。 整体来说，Actor符合我的要求。把Actor作为逻辑单位，有助于松耦合组件，但不是像我看到的CSP代码那么散。Actor除了“无法超过的前辈”Erlang之外（Actor+协程+函数式，理论上最好的并发编程语言），Scala和Java中可以使用Akka。BTW，Akka有针对STM的实现。 为了学习，个人选择了另一个Java下的Actor实现：Vert.x。严格来说，Vert.x并没有完全实现Actor模型，但是Vert.x作者把涉及到的绝大部分IO操作都异步化了，比如网络（基于Netty），文件，数据库（扩展形式）等等。之前个人也撰文分析过，协程的本质是异步编程，假如你把所有操作都异步化了，剩下的你可以用JavaScript的callback方式，或者更直观的ReactiveX。 Vert.x还有一个特点是把Actor的queue统一到一个eventBus中去，这样做的一个效果是用queue的名字代替了Actor。考虑到Actor在失败时以及多个Actor时的处理时，这么做并没有太大问题。 在使用过Vert.x+ReactiveX之后，个人觉得这可能是现代网络编程的一种比较好的组合。当然同时理解这两者会比较难，特别是ReactiveX。好在Vert.x不需要ReactiveX也可以使用，就像JavaScript没有async/await也可以使用。 个人不确定这是不是面向复杂网络程序的最佳架构方案，如果有更好的方案，欢迎留言。

上半年主要在忙写书的事情，下半年由于工作有点忙以及自己犯懒没有写博客。不过个人还是在持续学习，接下来是个人关于协程等的学习的一个小结。 严格来说协程不是一个新名词，但是因为Golang变得很火。很多博客从进程-线程-协程模型讲Golang如何高效，比那些没有协程的对手，比如Java好不知道到哪里去。先不管这种想法有点偏颇，个人想从协程想要解决什么问题开始，分析各种语言如何解决这些问题，来更深入地了解现代编程。 协程可以解决什么问题？首先三层调度模型（进程-线程-协程）中协程属于用户态任务调度，原先程序用线程来考虑问题，现在用任务粒度。程序怎么划分任务可以由程序员指定，也可以在特定的地方划分，比如IO操作。 IO操作相比计算型操作不怎么需要计算型资源，所以在等待IO操作返回时CPU资源是被“浪费”掉的。其次，非阻塞型IO的出现，使得编程方式发生了很大的变化。当你在考虑用额外的线程来处理IO阻塞时，非阻塞型IO可以少用额外的线程，只需要等待完成事件。 问题是“等待完成事件”对很多人来说个全新的东西，你可能需要一个轮询IO事件的selector（典型的reactor）以及相应的基于事件（event）编程的模式。你可以在JavaScript的运行时中看到这种模式。一般来说，语言层通过callback绑定后续操作。如果你有多个IO操作的话，你可能会写出callback嵌套callback的代码（或称callback hell）。JavaScript针对callback hell的解决方案是Promise，以及之后的aysnc/await。Promise允许链式callback，async/await允许用近似同步的方式编写异步的代码。 不管你是否感觉到，但是async/await确实做了类似协程的事情。 任务开始：IO操作开始，对应await开始 任务结束：IO操作结束，对应await结束 任务后续：callback，对应await之后的代码 注意，JavaScript由于是单线程模型，本身又有event loop，在实现async/await时并不需要对运行模型进行修改。其他语言想要实现async/await的话，除了语法层面，运行层也需要修改（在Erlang和Golang中，使用的协程运行时是一个“多线程版本的event loop”：work-stealing thread pool）。 小结一下，协程可以用于解决异步IO的callback hell问题。事实上，个人认为这是协程的优势。对于同样使用异步IO的程序来说，使不使用协程在性能上没有太大差距，但是用协程写法上会简单很多。至于Golang中使用go块开启协程的写法，个人认为是线程运行模式的补偿。比如你有一个非IO的长期计算任务，你没有IO操作的切入点和结束点，必须由程序员指明（用go关键字。BTW，因为这种任务的存在，协程运行时必须使用work stealing thread pool，否则被放到这个线程末尾的任务很长时间内不会被执行到）。 虽然协程可以简化异步IO调用，但是存在一些问题无法直接解决。比如说，我希望同时执行IO调用1，IO操作2并等待两个结果返回。如果你使用顺序IO操作1，IO操作2写的话，实际执行不会是并行的。在JavaScript下，你需要退回Promise并使用特定的API Promise.all。在Golang下，你需要主动开启两个go块执行IO操作，然后使用channel获取结果。 个人认为这其实显示了基于协程编程的脆弱性，一旦遇到不是简单的单次IO操作的场景，复杂性就会显现。又比如说，执行一个操作，你希望设置一个超时时间，在Golang中你必须同时使用channel/select，外加一个timer才能实现。相对的，同步编程下只需要在参数里加一个timeout。 可以看到，这里的复杂性其实是异步编程，或者说多线程编程的复杂性。JavaScript由于不是多线程，可以干脆放弃async/await的写法回归Promise+链式callback的做法。Golang使用了CSP编程的核心要素channel来处理多线程编程（BTW，Golang的channel可以与协程整合在一起）。 从个人角度来说，JavaScript的做法可能更好：假如你没法用协程了，那就退一步用不那么直接但是足够简单的方式，而不是退十步，用通用（即CSP）的方式。Golang很多人说简洁，但是由于其设计目标（比如工程化），只对基本的场景做了对应，剩下的场景就显得很简陋（C语言风格）。 除去Promise.all这种专用API之外，其他语言和框架中比较容易理解的，个人觉得是ReactiveX的zip，比如如下代码 Observable<Result1> source1 = operation1(); Observable<Result2> source2 = operation2(); Observable.zip(source1, source2, (r1, r2) -> { // do stuff }).subscribe(System.out::println); 这里没有暴露出任何和多线程相关的信息，但是可以达到同时执行的效果。进一步，假如你需要同时执行多个操作，只要有一个返回结果了就结束，在JavaScript、Golang和ReactiveX中你可以考虑下分别该怎么做（一个提示是，ReactiveX可以用amb替换zip）。 你可以把ReactiveX的subscribe当作JavaScript的callback，它会在获取到结果后被执行。和JavaScript的event loop不同，ReactiveX在多线程环境下执行时，subscribe的代码可能会在操作线程中执行。这对于Android开发来说可能会有问题（不能在GUI线程之外修改GUI元素），但是你可以通过简单增加一行observeOn(xxx)来解决这个问题。 注意，ReactiveX的数据流模型是一种PUSH模型，即数据流负责提交数据，触发下游操作。这某种程度和协程结束触发后续代码很像。其次ReactiveX允许你使用函数式语言的方式处理错误，集中精力在核心处理代码上。 当然ReactiveX不是万能的，在多线程编程方面，ReactiveX只能提供有限的帮助。更多的时候，你仍旧需要使用各种针对多线程处理的工具。以及，多种编程范式有助于你用各种高效的方法来解决问题，比如说Kotlin既有协程，也有async/await，也有ReactiveX的实现，当然你也可以用传统线程。个人认为这是现代编程对于愈来愈复杂的问题的解决方案，相应地这也需要程序员对语言使用对问题分析有足够的能力。 最后，以一句个人最近看到的话结尾“协程的本质是异步编程”。假如你能看到协程所要解决的问题，以及了解如何解决这些问题，那么相信你的学识会让你比其他人有更多手段和方法来更好地解决问题。