云原生转型模式：构筑云迁移的加速器

最近在构筑架构能力体系的时候，刚好看到了 O'reilly 出版社的《Cloud Native Transformation》（英文影印版） —— 一本关于云原生转型的书，结合了云原生迁移 + 组织文化转型两个维度。书中花了四个章节在介绍云原生转型的相关模式，书中的模式的类型为：策略和降低风险、组织和文化、开发和流程、基础设施和云。而作为半个转型“砖家”，我大抵对其中的一些模式比较熟悉，过去也想着编写相关的模式，只是一直没有时间编写。 如果你对于云原生转型缺乏相关的概念，可以参考我先前写的那篇《云原生转型：规模化演进与文化思考》。在那一篇文章里，介绍了企业的规模化云迁移为什么应该视为转型，以及中如何更好也进行云迁移。 所以，在这一篇文章里，我将结合云原生转型模式与开发者体验设计，重新构筑云原生转型模式体系。所以，我将其重新划为了五个维度，并且...

2d

文档工程体验设计：重塑开发者体验

最近，一边在思考如何进行开发者体验优化，一边在设计新的文档体系，以确保文档和代码的一致性。于是，便结合我先前对于文档代码化的理解和实践，并展开对于 Rust、Julia、Dart、Kotlin、Swift 等语言的文档研究（详细见：《API 库的文档体系支持：主流编程语言的文档设计》），重新思考了如何做了文档工程的开发者体验设计。 本文的面向编写文档的工程师，关注于他们如何能提高自身的开发体验。 文档工程师的痛点 我尝试性的去梳理过去在编写文档的一些痛点，诸如于： 文档代码不同步。即文档的 API 变化可能落后于代码，导致 API 与文档出现不一致。 频繁的 API 变更。API 变更时，文档需要手动进行更新，不能自动化同步。 概念不统一。对于同一个概念，文档的不同地方描述不一致。...

4w

API 库的文档体系支持：主流编程语言的文档设计

去年，我们在那篇《编程语言的 IDE 支持》详细讨论了在不同 IDE、编辑器里，它们是如何提供对于编程语言的支持。在这一篇文章里，我们将不那么详细地讨论一下：不同的编程语言如何提供文档支持？如此一来，也能在未来为 Datum Lang 提供相关的理论体系支持。这里所指的编程语言的文档体系，主要是指语言标准库中的文档。 新一代编程语言的文档体系 作为一个程序员，和诸多人一样，我并不热衷于在代码中写文档/注释。只是呢，诸多的情况下，我们依旧不得不写文档，如编程语言的标准库、API、SDK 等。在各个语言中，它们有各自不同的实践，有各自不同的特点。 起先，我只分析过 Rust 语言中的 rustdoc，分析它是如何自动化处理相关文档的。后来，联想到了其它语言的文档形式是不是也会类似。接着，便尝试性的整理自...

4w

文档同构：如何实现文档与代码的双向绑定？

先说一下对于结论的定义： 文档同构是一种将代码与文档保持一致的技术理念，它能读取格式化的文档，并将文档自动加入到代码中，如以注释的形式或者是只在 IDE 呈现；同时，还能将读取代码中的文档，自动更新到文档中，或是对文档进行测试和差异对比。 引子 1：文档与注释的痛点 最近，我边设计架构描述语言Forming，边围绕于这个概念体系编写新书。期间，在翻阅了一系列的架构书籍，如在《领域驱动设计》的 Highlighted Core 一节中提出了一个“精炼文档”的概念。 精炼文档是编写 一个非常简短的文档（3 ~ 7 页，每页内容不必太多），用于描述核心域和核心元素之间的主要交互过程 。 写文档的痛苦，我想大部分程序员是懂得的，它的痛苦主要体现在两方面：自己不想文档、自己想看文档的时候没有。而如书中所说，独立文档的常见风险主要是在两个方面：...

Sep 2021

2021 年技术书籍推荐 ——『Phodal 精选』

说来也奇怪，每次我想推荐一些书籍的时候，都是在奇数年，也都是在 9 月份。比如说，《2017 年的编程书籍推荐》、《2019 年的书籍推荐》。大概是到了秋、冬的时候，温度下降了，比较适合我进行一些思考和编程，所以我就不怎么在这个季节看书了。另外，从我的感知来看，我怀疑到了四季度新书也越来越少了。 今年推荐的书籍里，一部分是技术书籍，一部分是 20~50% 的技术书籍，也就是说和技术相关。我本想推荐一些不错的非技术书籍，但是呢，看得少，所以也推荐不了几本。 推荐的这些书籍，主要是我的兴趣和工作相关，主要是以兴趣为主，所以这 10 本书里主要会集中于： 编程语言设计：《C++ 语言的设计和演化》、《JavaScript 二十年》 数字化转型：《EDGE：价值驱动的数字化转型》、《数字化转型：企业破局的...

Sep 2021

团队拓扑：在云原生时代，如何定位自身与团队？

或是项目的原因，或是写作的原因，一直在思考『如何在云原生时代设计团队的协作？』以及『如何在云原生时代，重新定位开发人员的位置？』。起初，我只有一些细碎、不成体系的定义，直到这周公司大佬在内部分享了团队拓扑的理念之后。我终于找到一种合适的方式（基于这个体系），建立起有理论支撑的协作设计、体系化的开发者定位。 所以，在这篇文章里， 我们将： 介绍团队拓扑的基本概念 四个基本团队拓扑的能力模型 四种类型的开发者定位 四种类型的开发者的能力模型 从理念上看，本文可以帮助你寻找到自身的定位，并帮助团队更好演进。 团队拓扑 这个概念的来源是《高效能团队模式：支持软件快速交付的组织架构》，但是标题中没有体现核心『Team topologies』（团队拓扑），又是一个失败的标题。 直接进入正题，我们这里直接进入这本书的核心部分...

Aug 2021

云原生转型：规模化演进与文化思考

所谓转型，是指事物的结构形态、运转模型和人们观念的根本性转变过程。 PS：源于所见所闻所习所思总结而成，所代表的场景比较有限，可能不会适用于多数场景。 上周末，我在思考『大型组织如何进行 DevOps 的成熟度模型设计』时，便开始在思索，为什么 DevOps 是一种转型？敏捷也可以是一种转型？它们有着足够大的复杂度，需要改变一系列的组织文化，还有技术实践上的改变。所以，我尝试着继续去探索转型的领域。 如果一个领域，它需要大量的布道，需要进行大量的学习，以及架构（技术上、组织上或者是业务上）的变更，以转变人们的观念，那么它就可以称得上是一种转型。 所以，我重新思考了一下敏捷转型、DevOps 转型中的一些核心变革因素，诸如于： 观念的转换，引入新文化。 调整架构，改善协作。这里的架构包含了技术、组织、业务、团队。...

Aug 2021

技术产品化运营

技术产品化运营，是将技术产品（如开放 API、开源软件、开放平台、SDK、工具等）视为产品，在组织内部或者外部进行推广，以吸引更多的用户、开发者等参与到其中，加入到技术产品开发中，或者是采用该技术产品在其应用域构建解决方案。 过去的半年里，因为工作的缘故，我需要重复和人们讲述，如何去做好社区？如何去做技术运营？其中有一部分的内容，相当的相似与重复，诸如于： 《开发者体验 —— 内部工具的“最后一公里”》 《“内源”文化优于中台思想》 《开源游戏：开源会为企业带来什么》 内源、内部工具、开源等的推广，位于它们背后的便是：技术的产品化运营。所以，我想写一篇文章来总结一下模式。如此一来，在未来我就可以甩出本文即可。 技术产品化运营 与几年前相比，国内与技术产品化运营相关的岗位越来越多，诸如于布道师（Evangelist）、开发者关系（DevRel）、技术运营、开发者运营等。虽然，岗位职责稍有不同，也就是原文:技术产品化运营更多精彩内容，欢迎搜索并关注我的微信公众号:...

Aug 2021

中大型组织 DevOps 成熟度模型

DevOps 转型是一件颇有挑战性的工作。它并不是一个简单的工具或者平台的使用、运维能力提升。特别是在中大型组织中，它涉及到一系列的组织问题。 而传统的 DevOps 成熟度模型过于撕裂与分散，无法适用于大型组织。DevOps 厂商与云厂商的 DevOps 成熟度模型过于关注如何卖云基础设施，无助于企业进行高效的协作。 为此，我决定在 Ledge 的基础上，设计上开源的、面向大型组织的 DevOps 能力成熟度模型。它是基于我们所提炼的一系列研发效能模型，抽象而成的成熟度模型。 在设计与划分时，我们考虑的维度有两个： 规模化。对于中大型组织而言， DevOps 模型在设计时，要关注于流程化/标准化、工具化/平台化四个规模化因素。即选取合适的试点团队，构建组织的 DevOps...

Aug 2021

过去两年：回顾第二个 5 年的计划

两年前，我已经工作 5 年了，我构思了一个从 2019 ~ 2014 年的工作上的计划。如今，两年过去了，我又得拿出这个计划来做一些回顾。 PS：详细的计划内容，可以看《未来 5 年：构建第二个工作 5 年的计划》。 从总体来看，一切似乎是按目标进行的，但是依旧会有一些差异。我想着把这部分的内容写出来，做一次快速的回顾，希望对于大家能有所帮助。 一个小的总结 在制定计划的时候，时间在 2019 年 7 月 8 日。当时我还在 Thoughtworks 交付团队，恰逢组织结构变更，本来是归属于华南 unit，又来因为 rebase 的缘故划到了华东 unit。 后来，几个月后，“机缘巧合”之下，我正式从交付业务线转了咨询业务线，时间在 2019 年 10 月 18 日。 再回到第二个五年计划上来，在计划的初期，除了一个伟大的远景。基于这个远景，我还有了一些新的定位：...

Jul 2021