在架构治理平台 ArchGuard 中，为了实现对架构的治理，我们需要代码 + 模型描述所要处理的内容和数据。所以，在 ArchGuard 中，我们有了代码的模型、依赖的模型、变更的模型等，剩下的两个核心的部分就是架构的模型、架构的治理模型，其它的还有诸如构建的模型等，会在后续的过程中持续引入到系统中。

过去的 10 年间，软件的架构发生了巨大的变化，从早先流行的单体 MVC 架构，变成了所谓的 5：5 开，即分布式 vs 单体。只是呢，有大量的软件开发人员，无法看到系统的全貌，又或者是从单体的思维转变过来。于是，哪怕是在使用了微服务的情况下，但是实现的却又是一个一个的单体，只是它们变成了“分布式的单体”。

我，也许擅长 IDE 的插件开发，还有阅读了大量 Intellij IDEA Community 的源码，但也说不上擅长 IDE 的设计 —— 有太多的坑值得去探。特别是在五一之前，我尝试用 Druid 去构建一个编辑器，便发现这并不是容易的事情。所以，我走回了 WebView + Monaco 的路线，然后用 Rust 作为系统的核心：

这是一篇迟来的文章，我本应该在很早之前写完，但是一直都发现时机不够成熟。去年，在经历了多个低代码前端项目的售前，以及一个低代码项目的技术实践强化，国内的 IT 企业缺乏对于『开发者体验』缺乏系统性的思考。

2020 年，庚子年，注定是不平凡的一年，所以就平凡的过去了。年初，疫情让我在家办公了几个月，年中开始了忙碌的几个月，年底又归于平凡。也因为疫情，多了一些 beach 的时间，不得不休完 20 天的看似，还有没机会用上的婚假，所以我有机会尝试一些新的想法。

去年，和公司的大佬讨论了一系列关于代码的代码化，还记录了一些笔记。在那之后，我开始了各种尝试：如何将代码转变化代码。原先有一些思路，而后过了一年之后，慢慢地练习，又有了一些新的收获。

文档代码化，将文档以类代码的领域特定语言的方式编写，并借鉴软件开发的方式（如源码管理、部署）进行管理。它可以借助于特定的工具进行编辑、预览、查看，又或者是通过专属的系统部署到服务器上。面向非技术人员的文档代码化的一种常见架构模式是：编辑-发布-开发分离』，

过去的三星期里，因为疫情 + 种种不可告人的原因，我开始建设一个 DevOps 知识平台。 GitHub：[链接] 在线使用：[链接] 在这个知识平台里， 它包含了这么一些内容： DevOps 工具元素周期表。帮助您进行数字化时代的 DevOps 工具选型。 DevOps 设计工具。帮助您设计组织内的 DevOps 流程，涵盖了流程、人、工具、制品等等...

12 月初，ThoughtWorks 开始了 Annual Review 的 Kick Off，我开始总结这一年的工作，与此同时，我也开始总结我的 2019 节点。今年仍然是『平淡无奇』也过完了重要的一年。

如我在先前的文章所说，我最近的工作主要是在做架构重构、代码重构。所以，一如既往地，我又写了个工具来帮助我完成相关的工作。这样一来，下次我可以更快速地完成相关的工作。

软件架构，是一种为了解决复杂问题的通用模式。软件架构，是关于软件系统的一系列有层次的技术决策的集合。换句话来说，当我们讨论架构的时候，不能只讨论某某架构，而是要包含其实施，以及后期的维护。

在过去的几星期里，随着 Martin Fowler 博客上，那篇 Cam Jackson 写的微前端的文章发布，到处都在讨论 Microfrontend。作为一个微前端 “专家”，我也分享一下：如何去落地微前端。

规模化的组织，经常要面临这样的挑战：每个应用的基础设施是相同的，部分的代码也是相同的，甚至于它们可能只是数据模型不同而已。结果却导致了，他/她们要一次又一次地重新编写一个应用。

微前端架构是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。

过去，我一直有一个疑惑，人们是否真的需要微服务，是否真的需要微前端。毕竟，没有银弹。当人们考虑是否采用一种新的架构，除了考虑它带来好处之外，仍然也考量着存在的大量的风险和技术挑战。

刷新页面？路由拆分？No，动态加载组件。 本文分为以下四部分： 前端微服务化思想介绍 微前端的设计理念 实战微前端架构设计 基于 Mooa 进行前端微服务化 前端微服化 对于前端微服化来说，有这么一些方案： Web Component 显然可以一个很优秀的基础架构。然而，我们并不可能去大量地复写已有的应用。 iFrame。你是说真的...

软件开发不是一份稳定的工作：每年都会涌现一个又一个新的技术，每隔几年都会出现一些革命性的技术。尽管从代码、表现及差异上来看，新技术和旧的技术有一些概念上的相似，但是在使用的过程中，仍然是需要花费时间去学习的。

在我使用 Serverless Framework 开发 AWS Serverless 应用的过程中，最方便的莫过于，第一次部署和第二次、第三次部署没有什么区别。只需要执行 serverless deploy，几分钟后，我们代码就运行在线上。如果是一个传统的 AWS 应用，我需要 SSH 到我的服务器上部署，这样才能写好我的自动部署脚本。除此，我还需要担忧这个...

大部分的请求都是在 200ms 内完成的，而在最开始的请求潮里（刚发推送的时候，十分钟里近 1500 个请求），平均的响应时间都在 50ms 内。

Growth 1.0~2.0 已经有 2101 次提交，而 Growth 3.0 则已经拥有了 900+ 提交。这意味着 Growth 整个项目有多达 3000 次提交，感谢每一个为 Growth 项目作为贡献的开源先锋。

在我所经历的项目以及我所看到的Web应用里，它们都有相同的很有意思的生命周期。我们经常在网上看到某个知名的网站使用某个新的技术、语言来替换旧的系统，某个APP使用开发新的框架来替换现有的APP。我们所看到的都只是这些公司正在重构现有的系统，这实际上是一个周期的结束，以及一个新的周期的开始。其过程如下图所示：

一周前，参加了公司的一个架构设计与建模的工作坊——『事件风暴』。从某种意义上来说，这是一个关于架构设计与软件建模的工作坊。于是便闪现了一个灵感，便有了 Stepping.js。

本文对联纯属虚构，如有雷同关我屁事。 辛酸版 横批：谁能懂我 上联：敲一夜代码，流下两三行泪水，掏空四肢五体，六杯咖啡七桶泡面，还有八个测试九层审批，可谓十分艰难； 下联：经十年苦读，面过九八家公司，渐忘七情六欲，五年相亲四个对象，乃知三番加班两次约会，新年一鸣惊人。 祈福版 横批：鞠躬尽瘁 上联：文档...

时间过得很快很短，十二个月前在准备回南方的机票；八个月前在西安忍受着雾霾；四个月前在陪 @花仲马 吐槽桂林山水；今天我在这里，码下了这一行行的字。

新一期的ThoughtWorks技术雷达有点出乎意料，使用new标签的框架、工具、技术、语言等等超过了一半——Vue.js、ES2017上榜，Three.js凭着VR的火又上榜了，还有熟悉的Electron，以及微前端的概念。

这本书有一个很长的故事，到今天算是走到了一个意想中的结局。从审阅这本书开始、英文版出版、翻译成中文就这样走了两年的时间，这是一本值得纪念的书籍。

「微信小程序」的开发框架体验起来，还不错——自带了UI框架。但是问题是他的IDE，表现起来相当的糟糕——其实主要是因为，我当时买WebStorm License买了好多年。所以，我觉得他的IDE真不如我这个付费好用。

凡是能用JavaScript写出来的，最终都会用JavaScript写出来。 —— Atwood定律 在那篇《最流行的编程语言JavaScript能做什么？》里，我们列举了JavaScript在不同领域的使用情况，今天让我们来详解一下JavaScript在物联网中的应用。 基础：物联网的三个层级 开始之前， 先让我们简单地介绍点物联网的基础知识。如果你有点Web...

终于等来了Growth 2.0从APP Store审核通过了，想想觉得这个过程也蛮不容易的——从最早的一篇文章开始，然后变成了一个APP，它还衍生出了两本电子书。今天它仍然再前进着，也希望它能带领大家一起前进。

从实习后的那些年里，我就开始经常总结一下自己的学习路线，成长路线等等。今天，就重新把这些资料再放出来啦啦。 当然，这些资料也都是在我的GitHub上有的啦。 Developer成长路线图 最开始的时间，我并没有想到这张大图可以如此的受欢迎。在最开始的时候，我只想整理一下，我学习了什么东西、觉得什么东西不错。。 GitH...