Blog
Blog
PHODAL

最近在构筑架构能力体系的时候,刚好看到了 O'reilly 出版社的《Cloud Native Transformation》(英文影印版) —— 一本关于云原生转型的书,结合了云原生迁移 + 组织文化转型两个维度。书中花了四个章节在介绍云原生转型的相关模式,书中的模式的类型为:策略和降低风险、组织和文化、开发和流程、基础设施和云。而作为半个转型“砖家”,我大抵对其中的一些模式比较熟悉,过去也想着编写相关的模式,只是一直没有时间编写。

最近,一边在思考如何进行开发者体验优化,一边在设计新的文档体系,以确保文档和代码的一致性。于是,便结合我先前对于文档代码化的理解和实践,并展开对于 Rust、Julia、Dart、Kotlin、Swift 等语言的文档研究(详细见:《API 库的文档体系支持:主流编程语言的文档设计》),重新思考了如何做了文档工程的开发者体验设计。

去年,我们在那篇《编程语言的 IDE 支持》详细讨论了在不同 IDE、编辑器里,它们是如何提供对于编程语言的支持。在这一篇文章里,我们将不那么详细地讨论一下:不同的编程语言如何提供文档支持?如此一来,也能在未来为 Datum Lang 提供相关的理论体系支持。这里所指的编程语言的文档体系,主要是指语言标准库中的文档。

先说一下对于结论的定义:

今年推荐的书籍里,一部分是技术书籍,一部分是 20~50% 的技术书籍,也就是说和技术相关。我本想推荐一些不错的非技术书籍,但是呢,看得少,所以也推荐不了几本。

或是项目的原因,或是写作的原因,一直在思考『如何在云原生时代设计团队的协作?』以及『如何在云原生时代,重新定位开发人员的位置?』。起初,我只有一些细碎、不成体系的定义,直到这周公司大佬在内部分享了团队拓扑的理念之后。我终于找到一种合适的方式(基于这个体系),建立起有理论支撑的协作设计、体系化的开发者定位。

上周末,我在思考『大型组织如何进行 DevOps 的成熟度模型设计』时,便开始在思索,为什么 DevOps 是一种转型?敏捷也可以是一种转型?它们有着足够大的复杂度,需要改变一系列的组织文化,还有技术实践上的改变。所以,我尝试着继续去探索转型的领域。

技术产品化运营,是将技术产品(如开放 API、开源软件、开放平台、SDK、工具等)视为产品,在组织内部或者外部进行推广,以吸引更多的用户、开发者等参与到其中,加入到技术产品开发中,或者是采用该技术产品在其应用域构建解决方案。

传统的 DevOps 成熟度模型过于撕裂与分散,无法适用于大型组织。DevOps 厂商与云厂商的 DevOps 成熟度模型过于关注如何卖云基础设施,无助于企业进行高效的协作。

两年前,我已经工作 5 年了,我构思了一个从 2019 ~ 2014 年的工作上的计划。如今,两年过去了,我又得拿出这个计划来做一些回顾。

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

存档

分类

标签

作者