碎片粘合：Tasking DD 启发的思考

Posted by: Phodal Huang Nov. 8, 2021, 8:05 p.m.

标题原来意指 TDD，即 Test Driven Development，用 TDD 来进行碎片化时间的粘合。只是呢，Tasking 才是 TDD 的核心，于是在新的思考之下，我重构了本文的大纲。这篇文章的构成也非常有意思 —— 以致于我都没想清楚，为什么会写成这样。它只是由一个个的思考，所构成的文章，有些杂乱。

引子 0：长长的 To Do

昨天打开我的 To Do 时，发现待写的“文章 idea”有近一百篇，大概率是写不完了。所以需要清理一下 Todo 了，本文也是其中的项。在日常工作中，总会突然领悟到一些东西（aha 时刻），便会简单地写个标题或者一句话记录一下。在周末的时候，寻找相关的资料，编写文章，以深入相关领域的思考。

在这里，我们的第一个关键点便是：随时可记录 idea。其次，便是寻找时间完善它。只要时间不长，就不会像我一样，有一个长长的 todo —— 够我再写一年了。

引子 1：成就感 ox Game

文章的另外一个起源非常有意思。源于如何在非工作时间摸鱼，如早、中、晚过度碎片的时候，如何有效地组织起来，~~以更好地玩游戏~~。我的意思是：写会代码，看点资料，补充技术。

当你的时间被切割得支离破碎，比如参加各种会议时，要再挤出时间来写点代码，并不是一件容易的事。想法被打断了，在刚找到感觉的时候，可能又一个新的会议，又或者是讨论。这大抵就是作为一个技术负责人的生活，能寻找稳定的编码时间非常不易。

接着，离开这个悲伤的故事。回想一下，每天茶余饭后，总会拿起手机，玩会游戏。游戏里有每日任务、每周任务、每月任务，休息的时候拣起来，在领导来的时候关上。

除了游戏会带来一系列的成就感之后，它还有一个明确地任务，让你知道你完成了没有，你可以看到与目标的差距。比如，你有一个 51 级的英雄，而这个游戏的上限是 60，所以很进步一点，就能看到明显地成长。也因此，与花时间成长来说，花时间玩游戏更有成就感。

引子 2：从 Test Driven 向上到 Tasking Driven

多年过去，我一直在努力地保持着早上、中午、下午编写代码。为了保证细粒度（10 ~ 20 分钟内）时间下，能提交一次代码。需要有更细粒度的需求/任务，才能达成这样的目标。

从实践的模式来看，TDD（Test Driven Development）是最适合于业余开源项目的实践 —— “随时”可以中断手头的工作，一旦另外的再优先级的任务完成之后，可以继续找到当前的任务（即测试），完成这部分的工作。尽管，依然会存在一定的状态丢失，但是都能尽量地回到上下文中。

在缺乏“周期性练习” + “刻意训练”的情况下，TDD 便是一件相当难的事情。它的难点不在于，是否先写测试，而在于 Tasking。你并不一定需要 Test First，而是需要 Tasking First（即先进行任务拆解）。依此往下类推，用于支撑我们改善碎片时间的一个关键是：Tasking Driven。

粘合碎片时间：动机 + 举措 + 拆解

从理论上，粘合起碎片时间，并不是一件复杂的事情。诸如于，日常工作时，通常在显示器前、电脑上粘贴各种便利贴，来提醒我们：今天需要做哪些事情？在解决了一个个的问题之后，便会干掉一个个的便利贴。与编码相比，这种粒度会更为相比。不过呢，它没有突然任务拆解的重要性。

所以，对于我们来说，会粘合起碎片化的时间，需要：

• 动机。强烈的动机，以实现某一愿景。
• 举措。实现愿景所需要做的举措
• 拆解。拆解完的任务的子任务

我们可以将它对比到软件开发中的看板与故事卡的故事，又或者是更高维度的精益价值树（LVT）。只是呢，上述的三者都具备一点的难度。

1. 如何有强烈的动机？假设我们想保护改善颈椎、腰椎的情况，那么正确的方式，应该是在工作的时候，多次起身做做动作。但是，什么时候才会让你有强烈的去攺它的欲望呢，当你的腰开始疼的时候……。
2. 怎样的举措才是合适的？再回到程序员健康这个问题，我怎么知道这个举措真的是有效的？我又从哪里获取对应的尝试性方案呢？来自社区网站（如知乎），又或者是朋友的建议？
3. 如何有效地拆解任务？采用 SMART 原则？我怎么验证拆解确实是有效的？

这部分的坑就暂时挖到了这里，等我回头再想想。而粘合起碎片时间，我觉得它的一个核心要素在于：状态回溯。

核心原则：状态回溯的机制

再回过来看，从 TDD 的例子里，我们有一个非常好的原则：IDE + Git 可以为我们提供一个非常好的状态记录。在我们离开 IDE 的时候，它记录下了当时的状态。只要你们的猫不会同时按下 Ctrl/Command + Z，再按一下其它的按钮，那么我们就可以回放到当时的状态。这一点点小的 IDE 功能，是人类的大脑无法提供的，它可以帮我们回溯时间线上记忆的瞬间。

所以，在我继续填碎片化时间的这个坑时，应该思考是否要做的其它事情，都有相应的回溯机制？

一个没有把握的例子，我们在读书的时候，往往是需要由几个连续的时间段组合而成。所以，每当我们再次拿起书本的时候，需要往前看看，以回到当时的状态。而如果我们在今天看完书里，能记录一下书上的内容，就能 GET 到当时的状态，它相当于是我们对于书的一种快照。这种快照的形态是多种多样的，如书的脑图，又或者是书的书评。

我一直在佛性管理时间，从来没有好好计划过，什么时间做什么。只在状态的时候干活，不想干的时候就不干，或者瞎干。

所以，这里这是一点儿思考 —— 为了记录那些高优先级的思考，以及便于未来再拾起来看看。