技术产品化运营

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

1d

中大型组织 DevOps 成熟度模型

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

1d

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

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

2w

云端开发时：构建快速交付的开发体验

上个月，我与诸多同行们又讨论起了云 IDE 的事情。期间，我一直在想为什么云 IDE 不受开发者的欢迎？我回想了一下，为什么我不使用云 IDE？ 云 IDE 不智能。我使用的是 IDEA 全家桶。云 IDE 都是基于 VSCode / Eclipse Theia，重构功能不够强大。 云 IDE 性能差。云 IDE 大量的智能感知、编程语言分析（LSP）依赖于远程机器，在这方面的性能受限于虚拟环境。 所以，我重新思考了一下，在云研发体系未落地之前，我们应该如何进行过渡。后来，在整理 DSL 想着的材料，联想到了在构建云研发架构时，定义的开发即部署。云端开发时，这大概就是我想要的答案，最初的灵感来源： Nocalhost。 它并非是一个新的概念，只是我做了一个总结。 云端开发时...

4w

Guarding：开源的多语言架构守护工具

这是一篇姗姗来迟的文章 ，我本应该紧接着在《架构守护代码化：架构文档即测试》一文之后，详细介绍我们在 Uncode 中引入的『架构守护代码化』工具 Guarding。不过呢，从时间点上来看，现在也不算太晚，笑。 Guarding 简介 Guarding 是一个可以用于 Java、JavaScript、Rust、Golang 等语言的架构守护工具。受 ArchUnit 的启发，借助于易于理解的 DSL，来编写守护规则。支持 Windows、macOS、GNU/Linux 系统。 使用 简单来说，就是我们可以使用一个易于阅读的 DSL 来编写架构规则。而这些个架构规则，可以用于主流的语言。如下是使用 Guarding 编写的规则示例： ```guarding package(".")::file.len...

Jun 2021

30 岁，还好，还在 Coding，不卷了

进入 30 岁我，本不该写一篇关于这个话题的文章，我从来没有这样的焦虑。 只是呢，人们似乎『热衷』于讨论 30 岁的出路。所以呢，我觉得我应该分享一下我在这方面的一些观点： 别担心，路还长着 正视自己 剩下的都放在文章的标题里了。 30 岁，是一个媒体概念 30 岁作为一个门槛是非常奇怪的。有的人 23 岁本科毕业，工作了 7 年。有的人 26 岁研究生毕业，工作了 4 年。如此一来，依年龄而论是颇不合理、不恰当的，且缺乏理性的。 过去，@花仲马 在新媒体公司的工作，让我理解了月薪 3,000 人写月薪 30,000 人的故事时，应该编织以及再加工的：当有一家媒体写了一篇『没有一个 90 后编程员，活过 35 岁』达到“10万+”时，就会有更多的媒体编造类似的话题。如此的，我也懒得再找案例了。...

Jun 2021

架构守护代码化：架构文档即测试

架构守护代码化，即使用易于阅读和维护的领域特定语言，来描述软件架构守护的规则，对诸如于分层架构、包访问规则、包数量、继承命名等进行限制。 PS：我们这里所说的代码化，所指的是与领域特定语言的方式进行描述。 早先呢，我只是因为使用 Java 编写的 ArchUnit 不支持其它语言，而在其它语言的生态里呢，也没有这样的合适的工具。所以呢，我就想着在 Uncode 里设计一个全新的架构守护工具，也就是 Inherd 开源小组里的 Guarding： https://github.com/inherd/guarding/，一个多语言的架构守护工具 —— 基于 Tree Sitter 解析各类编程语言。它设计了一套外部 DSL，其借鉴于 ArchUnit 设计的内部 DSL 语法。 架构的腐化：为什么我们需要架构守护？...

Jun 2021

领域特定语言设计技巧

在过去的几年里，我一直从事于各种领域定义语言的设计，包含 unflow、guarding、datum、forming 等。在我刚入门这个领域的时候，我从《领域特定语言》、《编程语言实现模式》 等，一直研究到龙书等。我渐渐掌握了领域特定语言设计的一些技巧，也能快速（相对于过去）设计出一个领域特定语言。 所以，我在想我应该总结一下相关的套路。这样一来，也可以在未来验证现在的思路是否正确： 定义呈现模式。 提炼领域特定名词。 设计关联关系与语法。 实现语法解析。 演进语言的设计。 领域特定语言 领域特定语言（英語：domain-specific language、DSL）指的是专注于某个应用程序领域的计算机语言。 本文所写的皆是外部 DSL，即『不同于应用系统主要使用语言』的语言。创建外部...

Jun 2021

UI 设计代码化：低代码式设计语言 —— Unflow

UI 设计代码化，即将软件的 UI 设计与 UI 交互转换为特定的领域语言，并使用代码的方式来进行管理。它可以直接将需求转换为 UI 原型，让设计人员基于此进行设计；还负责将其转换对应的 UI 代码，方便开发人员进行编写。 在 Uncode IDE 里，设计代码化是由两部分组成：架构设计（代码设计）代码化与 UI 设计代码化，这是一个相当复杂的领域。作为一个在前端领域的专家，我是在去年完成了 UI 设计代码的第一个版本的设计；作为半个架构专家，我则是在最近完成了部分架构设计代码化的工作。 在最近 ，我刚使用 Rust 将去年设计的 UI DSL 重写，于是重新命名为 Unflow。想不到一个更好的名字，于是将它与 Uncode 进行了一个简单的对应。你可以在 GitHub 上看到 Unflow...

May 2021

研发工具一体化：效能演进

我对于无代码编程的研究也有些年头了，从国内最早的『无代码编程』相关的文章，到最近的『流程即代码：云研发 IDE Uncode』，我大抵是有资格再聊聊这个行业。 最近，我们 Inherd 开源小组推出了『云研发 IDE：Uncode』的预览版，然后便与不同企业的人进行了一波的交流。在这些观点的驱动之下，我觉得我们有必要再写一些文章：好好介绍一下一些相关的理念。这些理念用于帮助这些企业，好好思考一下研发平台的下一站。 再谈云开发平台 对于开发平台来说，转身为一个云开发的平台，是行业内的一个大趋势。这也就是为什么国内的各大云厂商都在兜售它们的平台。从我与他们的交流情况来看，尽管它们自称有一个“完整”的平台，但是客户只买单其中的一两个。其中的原因颇多，其中的一些主要原因是： 企业自身已经开发/采购一部分环节的工具、产品。...

May 2021