文章

Nop Platform 2.0是基于可逆计算原理从零开始构建的新一代开源低代码平台，它致力于克服低代码平台无法摆脱穷举法的困境，从理论层面超越组件技术，有效的解决粗粒度软件复用的问题。借助于DSL，Nop平台可以直接与GPT对话，成为AI驱动的低代码平台。本视频介绍了可逆计算的基本原理和Nop平台基本操作演示，最后演示了通过Nop平台内置的DSL与GPT进行交互直接驱动生成应用的过程。

本文来说说在企业中让知识流动起来的大体思路。

列举日常工作中的常见问题，卖个关子先～

列举日常工作中的常见问题，卖个关子先～

本文要谈的不是软件产品的生存策略，而是作为软件开发人员在团队中的生存问题——按理来说，这也像前两篇所讲的一样属于「人为因素」问题。

在《反思软件开发：人为因素（上）》中，我简单阐述了个人的局限性以及组织该有的意识形态中的主要方面。正所谓「思想决定行为」，组织在运作时成员的实际行为受那篇文章所述意识形态影响。

本文内容（分上、下篇）实际上跟软件生产没什么关系，虽然在生产中方法论、工具等很重要，但更重要的是组织和人的问题，然而这类问题并不局限于软件生产。工具带来的提效只适用于无需智慧的机械性低价值重复劳动上，工具带来的效率提升是次要的，最先应该解决的是组织和人的效率问题——这是件非常难的事情。

用人话说，「生产」是从无到有创造人们所需要的物品，可以是实物，也可以是虚拟的；软件就是那个被创造的「物品」，从无到有去创造软件就是「软件生产」。先提了个问——软件生产是体力密集型劳动还是脑力密集型劳动？

作为软件开发人员，常会听到「技术服务于业务」这句话，也常被问到「你做的事情有什么业务价值」这类问题。听得多了，被问得多了，自然就会想要给自己做的技术工作找点「合理性」，否则在阶段考评或晋升答辩时都不知如何表达自己做的事情是「有价值的」。然而，就像很多道理一样，「知道」与「理解」之间有着巨大鸿沟，仅有其形的话很容易就被戳穿。本文是我对「软件」重新思考后的理解，有了相对正确的认知后才能做出更好、更实用的软件——软件从来不是单纯的技术成果，技术也不是软件最核心的部分。

前几天和朋友聊起国内做低代码/无代码的几个头部互联网公司，虽然大家的商业切入方式不同——有的是和 CRM 等厂商合作，技术赋能；有的是直接切入常用 OA 场景——但有一点共识是通用型的低代码/无代码的价值更大，基本都在往这个方向前进。这篇文章记录了几个相关问答。

大部分介绍设计模式的文章，倾向于从实现角度介绍模式，这是没有问题的。但是，一篇文章一旦被写出来，就不得不为其写作目的服务，要想鲜明的表达观点，就必须有所强调，所以，注重模式内在表现的文章，对于外在表现的阐述就不够了。本文就试着消除这一盲区，从外在角度介绍一下设计模式。

本文联系了物理学、哲学、逻辑学三个学科，讨论了模型方法的意义，把领域模型理解为，对领域知识的一种本体建模结果。模型方法可以看做是一种人类创造的心智手段，通过解释映射，建立起理论与待研究对象之间的同构关系。从而我们可以间接的找出理论的推论，来预测研究对象所应当满足的性质。

很多开发者都有一个迷思，认为项目里的代码质量和可维护性的持续下降，主要根源在于时间紧迫、需求变动频繁。如果产品需求更加明确，并给予足够的开发时间，开发团队可以长期保证代码质量和可维护性。今天介绍的DDD(领域驱动设计)和ADT(代数数据类型)的模型，给出了另一部分的答案：代码质量持续下降，开发团队也要负主要责任。

最近读了很多低代码/无代码的分析文章，发现普遍存在的两个问题：从概念、市场来谈的文章大部分只是信息的汇总，对背后的逻辑停留在“数字化转型、效率提升”等泛泛的概念上。实际上低代码/无代码针对不同的市场，有着不同的策略、技术细分，泛泛而谈没有意义。同时空洞的数字也难以让人产生有体感的认知。从具体技术角度出发的文章又太偏向于技术实现，作为技术分享是好的，但缺乏了对市场及技术发展历史的更全面的思考。这篇文章要解决这两个问题，既讲清楚低代码/无代码的整体大背景和背后的逻辑。也会从更长的软件发展的角度来看价值和趋势。

简单说说我对「产研一体化」的理解。

分享内容主要分为 3 块：首先会介绍，在阿里纷繁复杂的业务背景下，用户角色繁多，技术栈各异，我们是如何思考低代码技术体系架构的；然后，我会介绍低代码技术体系的架构实战，重点介绍过程中沉淀的两个技术产品；最后，我会跟大家分享阿里的几个具体的低代码场景以及平台建设。

领域驱动设计包含三层含义：协作层；架构层；实现层。

2022 年已经到来，我们是时候反思 Web 开发中的种种过时软件、炒作歪曲和荒谬趋势了。把握这一年，我们也该重新专注于性能与技术运用，把手段和目的重新统一起来。当然，我不是劝大家用汇编或者 C 语言搞 Web 开发，但关于 JavaScript、Ruby on Rails、Python、Django 以及 PHP 框架的疯狂观点也该消停一下了。

昨天同事问我的一个使用 Handie 做业务需求遇到的问题，作为 case 记录下。

吴多益在《从实现原理看低代码》这篇文章中谈到了对LowCode的一些观点。我总体上赞同他的看法，但是关于可视化编辑与LowCode之间的关系，以及代码生成的适用范围，我也有一些不同的意见。

我们在低代码领域探索了很多年，从 2015 开始研发低代码前端渲染（amis），从 2018 年开研发后端低代码数据模型，发布了爱速搭低代码平台，这些年调研过了几乎所有市面上的相关技术和产品，发现虽然每家产品细节都不太一样，但在底层技术上却只有少数几种方案，因此我们认为不同产品间的最大区别是实现原理，了解这些实现原理就能知道各个低代码平台的优缺点，所以本文将会介绍目前已知的各种低代码实现方案，从实现原理角度看低代码。

上篇Bruce分享了自己学习编程的心得，并在如何构建自己的核心竞争力方面给出诸多建议。本篇将待大家一起探究，编程的本质是什么？谷歌的首席Java架构师Joshua Bloch认为，“编程就像文学艺术，程序的可读性必须更好。如果你不擅长写作，就很难达到目标”。这和Bruce的观点不谋而合，希望本篇能带给你新的思考。

不熟悉计算机底层原理，我能走多远？30+ 了，会被裁吧？到底学哪门编程语言更有前（钱）途？裁员大潮，行业高度内卷带来的焦虑迫使我们总是重复面对以上问题，它们是否有可解的答案？如果你的答案是“没有”，那我建议你从阅读这篇文章开始。

本次分享会包含三个部分：什么是CR、曾经有过的尝试、遇到的困难&解决思路等。

阿里狼叔关于 2022 前端发展的看法。

任何解决方案都不能解决一切问题，一定要找到它适合的场景。不过，现阶段，状态机确实是我能看到的，解决复杂业务逻辑最好的工具。

一直以来，企业软件前端工程体系处于一个很尴尬的局面，无数前端对它有过各种吐槽：技术栈老旧、封闭，体验差，而项目和交付经理又会觉得开发效率太低。据我所见，大部分吐槽的人并没有理解造成这些状况的深层原因，或者说，当自己去构建这么一套体系的时候，并不理解在选型和技术集成过程中，存有哪些可能的决策点。

清理代码库就像打扫房子，每隔一段时间就应该打扫一次，但是即使坚持定期打扫，时间久了，房间还是会越来越乱。可以说大部分有点年份的项目里都有一些惨不忍睹的模块。

Google 是一家工程师文化浓郁的公司，而其中让我感触最深的环节有两点，代码审核 (Code Review) 以及设计文档审核 (Design Doc Review)。今天先说说 Code Review，简称 CR。

在远古的时候，人们对世界的认知有限，以为天圆地方，世界是平的。后来，随着科技进步，大家都知道了地球的形状，它不但不平，还有山川河流，沙漠海洋。这很大程度上说明了人所处的环境对认知带来的影响，我们看待一件事物，从不同的视角去看，所得到的结论未必是相同的。

让我们观察一下计算机领域的发展过程，从一百年前到今天，IT 领域的热点，其实一直在向上移动的，所谓向上移动，是指抽象的层级，而这个过程始终都指向一个目的，就是屏蔽更多的底层细节，让计算机的使用者/开发者能够花更多的时间在创造和享受上。

程序在机器上的执行不需要用到变量名，在人脑里的执行需要用到变量名。人脑执行程序，遵循心理学的认知规律，因而跟程序的机器执行特征不完全相同。同一任务，可以由不同编程语言解决，在同一编程语言里也可以用不同方式去解决。这是一个一对多的关系。然而，只有极少数的代码实现，遵循人的认知规律，从而表现为——可读性更好。

今天分享的标题包含了三个关键词：ESM，即 ES Module，当前浏览器标准的模块规范；Bundleless，对应传统的 Bundle，即强调更少的打包；低代码，近两年火热的前端命题，相信大家都听说过、使用过、甚至开发过一个低代码平台，低代码的核心是借助可视化/配置的方式来提升应用的研发效率，这也是我所在的团队「云凤蝶」在努力做的方向。

过去的几个月里，我陆陆续续和不同公司的人一起讨论了开发、研发的未来。光是发我写过的几篇文章的链接，已经不能很好地解决问题。所以我决定写一篇长长的文章，来帮助更多地人理解：研发的未来在哪里？

这是一种很好玩的前端架构模式，可以创造出无限的乐趣。你不一定需要知道它，但是它真的很好玩。我写这篇文章主要是因为好玩，也没有啥新东西。

对于大部分不了解开源的人来说，他们很难理解：为什么“内源”能解决中台没有解决的问题？内源不就是在内部建立起开源式的项目，它哪能比中台更好？

跨框架的 UI 库，即前端 UI 库可以不经任何修改，直接能运行在 React、Angular、Vue 等框架上。在开源电子书《微前端的那些事儿》 中，我们讨论到了 Web Components 技术，一种新的 Web 前端容器化技术。在电子书里，我们主要介绍的是：如何使用 Web Components 来构建微服务。而在这篇文章里，我们讨论的是 Web 组件的下半场：跨框架的 UI 库。【另附《我来聊聊面向组件的前端开发》》】

在工作中，不同开发者思维方式不同，低级开发者需要等到设计稿完成之后，才能启动开发，中级开发者会根据交互稿利用系统风格就可以启动开发，而高级开发者，从参与需求讨论开始，就可以开始启动开发了。是什么让开发者无需在视图界面的引导下，就可以完成部分编程呢？【另附《前端抽象模型》和《前端关键问题溯源》】

讲述如何用 TypeScript 中的类型做领域建模。建议在开始编码前先写类型。

新组件库的诞生与流行，存在两个大的背景：编程框架和编程范式的重大改变；设计体系的独有发展。所以，回头去看，可以发现当前最流行的几个组件库，都踩中了其中某些点。那么，现在还有没有机会再出现成功的组件库呢？我认为是非常有机会。

本文主要站在稳健性这个角度，试图阐述，在业务系统中，如何去安排或组织我们的（前端）代码，才能保证符合业务系统特征要求，且有利于长期可持续维护下去。由于谈系统过大，那么，本文只立足于一个业务模块来进行阐述。

Angular是最早声称基于MVVM架构的前端框架，但在我眼里，Angular根本没有M这一层，React和Vue也好不到哪里，目前最热的三大框架，都只是V层前端框架，和M层谈不上什么联系。不是我冒犯，包括我自己在内，如果满眼都是React和Vue之类的前端框架、库，那么可以说，对前端数据层几乎一无所知，就算把前端框架玩的贼溜，对前端架构的理解，也不过是井底蛙之王。

在分层理念中，一种通用的分层思想，是将应用分为“数据层”“逻辑层”“表现层”，在每层内，我们又可以细分。你可能会想，“分层？有必要吗？”就像我们接触毒药一样，离开了剂量谈毒是没有意义的，同样的道理，离开了具体的业务复杂度谈分层，也是没有意义的。

经过《聊聊中后台前端应用：模块相关的一些事》和《聊聊中后台前端应用：业务中的组件体系》这两篇文章的铺垫，终于可以单独写一篇文章来专门讲讲「上下文」相关的事情了。

在《聊聊中后台前端应用：目录结构划分模式》中讲述了「野生」、「分层」和「模块化」这三种划分目录结构的模式，本文就在假定项目中已经采用内聚性相对最高的「模块化」模式进行目录结构划分的基础上，聊聊模块相关的一些事儿。

目录结构实际就是模块拆分的体现，是架构的一部分，其划分方式应具有让开发者把文件放到正确位置的指导作用。

在本系列的上篇文章《聊聊前端 UI 组件：组件特征》中，通过从关注点分离的角度进行前端 UI 组件的构成分析，并以较为抽象的视角对 UI 组件分门别类，以及描述了让组件间可以表现复用的继承关系，从而建立出前端 UI 组件的特征模型。本文将以上篇文章中所得出的特征模型为基础，探讨下如何设计并建立一个前端 UI 组件体系。

本文从前端 UI 组件的构成、分类及组件间的继承关系等角度出发，通过分析组件的特征来探讨建立一个组件体系所需要关注的一些点。其中，UI 组件各构成元素的易变性是最应该被关注的，它会对组件体系的可复用性、可扩展性等产生很大影响。

在业务开发过程中，我们总是会期望某些功能一定程度的复用。很基础的那些元素，比如按钮，输入框，它们的使用方式都已经被大部分人熟知，但是一旦某块功能复杂起来，成为一种“业务组件”的时候，就会陷入一些很奇怪的境况，最初是期望抽出来的这块组件能有比较好的复用性，但是，可能当另外一个业务想要复用它的时候，往往遇到很多问题。【另附《聊聊中后台前端应用：业务中的组件体系》】

在广义的前端领域，模型驱动视图已经不是什么新鲜话题了，“低代码”和“搭建”也炙手可热，而这些概念都是以增强应用系统的可配置性为前提的。在这个大前提下，建立元数据驱动的前端架构就变得很重要了。本次分享的目标是希望从零开始，初步建立一个小小的元数据驱动的原型系统（暂时只包括前端部分），并以此介绍这套系统与业务领域的可能结合方式。【另附《我来聊聊模型驱动的前端开发》】

今天偶然听了 Kent Beck 讲解 Edward Yourdon 《Structured design : fundamentals of a discipline of computer program and systems design》关于什么是“耦合”，什么是“内聚”的定义。觉得有必要记录一下

近几年，随着 TypeScript 的逐步流行，类型系统逐渐被前端这个群体重视起来，也逐渐在一些组件库中被深度采用。但是，我们可以发现，如果从使用类型系统的几个层级去划分：类型不友好；类型友好；类型优先。几乎所有组件库都处于前两个层级，并未达到类型优先的程度。那么，什么是类型优先，它有什么好处，本文尝试结合一些具体案例，给出说明。

本文尝试从数据和逻辑的角度，对业务系统中的各种交互作一个归类，简单探索其中一些共性，并以此作为渐进式交互优化的一种依据。

建模是一件非常好玩的事情，我们总是在不断也抽象、抽象、抽象，还有定义、定义、定义。随着我们不断深入软件架构的设计里，我们也会不断也尝试着一系列不同的方法。在这篇文章里，我的意图是想寻找建模方法的一些共性。正好，结合一些最近对于模型与概念关系的一些思考。