标题原来意指 TDD，即 Test Driven Development，用 TDD 来进行碎片化时间的粘合。只是呢，Tasking 才是 TDD 的核心，于是在新的思考之下，我重构了本文的大纲。这篇文章的构成也非常有意思 —— 以致于我都没想清楚，为什么会写成这样。它只是由一个个的思考，所构成的文章，有些杂乱。
年初，总结了过去在平台与开源软件的一些经验，编写了那篇《开发者体验》。在那之后，陆陆续续地与不同公司、不同行业的人，一起讨论了起了开发者体验。有的是来自于内部平台的开发者，有的是源自于技术社区的相关负责人，还有的则是开源软件的贡献者。
软件开发总成本 = 开发成本 + 维护成本；软件维护成本 = 理解成本 + 修改成本 + 测试成本 + 部署成本。—— Ken Beck
在年初的那一篇《开发者体验 —— 内部工具的“最后一公里”》里，我们讨论了什么是用户体验？如何进行用户体验的设计？还有开发者体验的六要素？在先前的文章里， 我们已经介绍了文档体验的设计，结合最近学习某技术的不好的开发体验，所以重新思考了一下好的错误呈现应该是怎样的。
最近在构筑架构能力体系的时候，刚好看到了 O'reilly 出版社的《Cloud Native Transformation》（英文影印版） —— 一本关于云原生转型的书，结合了云原生迁移 + 组织文化转型两个维度。书中花了四个章节在介绍云原生转型的相关模式，书中的模式的类型为：策略和降低风险、组织和文化、开发和流程、基础设施和云。而作为半个转型“砖家”，我大抵对其中的一些模式比较熟悉，过去也想着编写相关的模式，只是一直没有时间编写。
最近，一边在思考如何进行开发者体验优化，一边在设计新的文档体系，以确保文档和代码的一致性。于是，便结合我先前对于文档代码化的理解和实践，并展开对于 Rust、Julia、Dart、Kotlin、Swift 等语言的文档研究（详细见：《API 库的文档体系支持：主流编程语言的文档设计》），重新思考了如何做了文档工程的开发者体验设计。
去年，我们在那篇《编程语言的 IDE 支持》详细讨论了在不同 IDE、编辑器里，它们是如何提供对于编程语言的支持。在这一篇文章里，我们将不那么详细地讨论一下：不同的编程语言如何提供文档支持？如此一来，也能在未来为 Datum Lang 提供相关的理论体系支持。这里所指的编程语言的文档体系，主要是指语言标准库中的文档。
先说一下对于结论的定义：
今年推荐的书籍里，一部分是技术书籍，一部分是 20~50% 的技术书籍，也就是说和技术相关。我本想推荐一些不错的非技术书籍，但是呢，看得少，所以也推荐不了几本。
或是项目的原因，或是写作的原因，一直在思考『如何在云原生时代设计团队的协作？』以及『如何在云原生时代，重新定位开发人员的位置？』。起初，我只有一些细碎、不成体系的定义，直到这周公司大佬在内部分享了团队拓扑的理念之后。我终于找到一种合适的方式（基于这个体系），建立起有理论支撑的协作设计、体系化的开发者定位。