最近，一边在思考如何进行开发者体验优化，一边在设计新的文档体系，以确保文档和代码的一致性。于是，便结合我先前对于文档代码化的理解和实践，并展开对于 Rust、Julia、Dart、Kotlin、Swift 等语言的文档研究（详细见：《API 库的文档体系支持：主流编程语言的文档设计》），重新思考了如何做了文档工程的开发者体验设计。
去年，我们在那篇《编程语言的 IDE 支持》详细讨论了在不同 IDE、编辑器里，它们是如何提供对于编程语言的支持。在这一篇文章里，我们将不那么详细地讨论一下：不同的编程语言如何提供文档支持？如此一来，也能在未来为 Datum Lang 提供相关的理论体系支持。这里所指的编程语言的文档体系，主要是指语言标准库中的文档。
先说一下对于结论的定义：
今年推荐的书籍里，一部分是技术书籍，一部分是 20~50% 的技术书籍，也就是说和技术相关。我本想推荐一些不错的非技术书籍，但是呢，看得少，所以也推荐不了几本。
或是项目的原因，或是写作的原因，一直在思考『如何在云原生时代设计团队的协作？』以及『如何在云原生时代，重新定位开发人员的位置？』。起初，我只有一些细碎、不成体系的定义，直到这周公司大佬在内部分享了团队拓扑的理念之后。我终于找到一种合适的方式（基于这个体系），建立起有理论支撑的协作设计、体系化的开发者定位。
上周末，我在思考『大型组织如何进行 DevOps 的成熟度模型设计』时，便开始在思索，为什么 DevOps 是一种转型？敏捷也可以是一种转型？它们有着足够大的复杂度，需要改变一系列的组织文化，还有技术实践上的改变。所以，我尝试着继续去探索转型的领域。
技术产品化运营，是将技术产品（如开放 API、开源软件、开放平台、SDK、工具等）视为产品，在组织内部或者外部进行推广，以吸引更多的用户、开发者等参与到其中，加入到技术产品开发中，或者是采用该技术产品在其应用域构建解决方案。
传统的 DevOps 成熟度模型过于撕裂与分散，无法适用于大型组织。DevOps 厂商与云厂商的 DevOps 成熟度模型过于关注如何卖云基础设施，无助于企业进行高效的协作。
两年前，我已经工作 5 年了，我构思了一个从 2019 ~ 2014 年的工作上的计划。如今，两年过去了，我又得拿出这个计划来做一些回顾。
上个月，我与诸多同行们又讨论起了云 IDE 的事情。期间，我一直在想为什么云 IDE 不受开发者的欢迎？我回想了一下，为什么我不使用云 IDE？