作者: Phodal Huang 2020年5月25日 20:24

不同的微前端框架都源于它们的使用场景，也受限了它们不能满足于其它场景。受限于使用场景，这些微前端框架都需要不同程度的改造，才能满足各自的需要。

作者: Phodal Huang 2020年5月19日 13:26

随着持续部署、DevOps 在各个企业的推进，越来越多的企业已经有完善的基础设施，软件开发团队只需要一个在线的 IDE，就可以完成开发工作，这就进入了云开发时代。

作者: Phodal Huang 2020年5月17日 21:25

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

作者: Phodal Huang 2020年5月11日 20:31

这个故事很长，不过我并不想讲得太长。原先，关于这个问题的答案只有一个。只是我在写 Ledge 的时候，发现了一些有意思的东西。因此，我决定写一篇不太不短的文章来讲述一下。

作者: Phodal Huang 2020年4月29日 20:15

Serverless 越来越火，无代码编程也提上了议程，还有云开发也在风口浪尖。那么，未来会是怎样的呢？

作者: Phodal Huang 2020年4月27日 20:30

这篇文章的草稿差不多在我的 todo 列表里躺了一年，直到最近，看到我的同事在吐槽手动创建步骤的繁琐性。我才想起来，我曾经想写一篇这样的文章，但是我在我的博客（ https://www.phodal.com ） 上找了好久，也没有发现。然后，我终于在我的 To-Do 应用中看到了它的身影。 虽然说是模式总结，到底只是个人经验。受限于个人经验，可能有些许的不足之处。若是各位读者愿意指出来，那自然感激不尽。 ## 开发过程：IDE 代码片段『精选』 > IDE 代码片段『精选』即在 IDE/编辑器中，通过插件或者内置组件，对特定语言、框架、技术等提供自动化的代码填写。 代码集这个东西，自然比较是比较有意思的。在我们的日常开发中，我们经常会使用到，它的名字有多样多样，如 - AutoComplete - Snippets - 智能感知 - …… 它倒也没有什么特别之处，在我们输入一些词的时候，给我们建议，如在 IDE 里输入 `list.for`，过程中就可以生成如下的代码： ```kotlin for (item in list) { } ``` 嗯，就这么简单，是不是经常使用到。 ## 开发过程：语言、框架抽象 DSL > 语言抽象 DSL，即通过编辑器、IDE 内置对于语言和框架的抽象，使开发人员可以通过编写 DSL 便可以生成特定语言的代码。 它特别适合于编写简单的模板代码，如 HTML、XML 等。作为一个开发人员，那么最常看到的例子就是 Zen Coding/Emmet，这个东西非常炫，输入 `ul>li*5>a[href="#"]`，然后按一下 tab，你就可以快速生成如下的代码： ```html

``` 嗯，它特定适合于编写结构化的代码格式。 ## 创建时：模板化代码生成 > 模板化代码生成，即在代码 or IDE 中内置特定系统、团队的代码范式，随后通过特定的参数，来生成适合于该团队和该系统的代码。 考虑到前端领域创建模板的复杂性，创建的过程中，需要同时创建 `*.component.scss`、`*.component.spec.ts`、`*.compnent.ts`、`*.component.html`，所以在前端领域非常之流行。最简单来说，Angular 开发人员通过 `ng g` 就可以生成各式各样的代码。 事实上，我觉得对应于后端开发也是如此，毕竟创建一个 CRUD API 可能需要 `model`、`repository`、`api`、`service` 等。不过，依我的观察来看，后端开发人员一般都没有 GET 到这项技能，因为 gradle 太 TM 难用了。 尽管，大部分框架都自带了类似的生成器，但是大多数时候，都得自己撸一个适合于架构的模板。所以，这里推荐一下适用于前后端的框架。 ### Angular Schematics > Schematics 是前端开发工作流工具，例如：创建一个组件、变更配置项至当前项目，并且不限制任何语言环境。 ### Plop > Plop 是一个微型生成器框架。它提供了一种以一致的方式生成代码或任何其他类型的纯文本文件的简单方法。 嗯，这两个框架，大家自己了解一下。 ## 创建时：DSL 生成代码 > DSL 生成代码，顾名思义就是通过 DSL 的方式，来生成代码，再集成到系统中开发。 最常见的一个例子就是我最近使用基于 Antlr 编写的 Chapi，便是这种模式。又或者是，对于一些模式化的开发的系统来说，它们也是通过类似的方式来生成大量的模板。 注意：通过这种模式生成的代码，往往是不会进行二次开发的。因为随着引擎的更新，这些代码会被覆盖住，导致难以维护。 如 Antlr 这样的框架，只需要通过： `antlr -Dlanguage=Java -listener -visitor CPP.g4 -o chapi/ast/antlr -package chapi.ast.antlr` 编译生成到指定的目录。于是乎，我们就可以 `import chapi.ast.antlr`，集成到系统中使用。 ## 构建时：DSL / 代码生成代码 > 构建时代码生成代码，即在构建的时候，才进行代码生成。 对于稳定的系统来说，可以只在构建时才运行代码生成。平时的时候，都是通过生成临时代码的方式。嗯，常见的 Angular 框架就是类似的方式运行的。 在开发的过程中，我们都是通过编码 DSL 或者是一种不同于最终运行语言来编写的。 ## 运行时：元编程 > 元编程（Metaprogramming）是指某类计算机程序的编写，这类计算机程序编写或者操纵其他程序（或者自身）作为它们的数据，或者在运行时完成部分本应在编译时完成的工作。 这一点大家都很熟了，我就不再重复描述了。 ## 未来 随着，无代码编程/低代码编程越来越流行，代码生成的基础架构来越来越火。

作者: Phodal Huang 2020年4月20日 20:36

人的智商不够、又或者是脑容量不足以容纳这么多的知识。所以，对于个人来说，我们工作的时候，依赖于文档、笔记、文章，来帮我们回忆起这些知识；对于组织来说，知识传递是需要知识管理的一个关键因素。

作者: Phodal Huang in Open Source 2020年4月18日 20:02

在 Ledge 知识平台 发布的这一周多里，我一直在思考如何让这个项目做得更好。在和 CSDN 编辑的讨论中，我意识到我可以把这个过程中的相关经验分享出来。因为毕竟大部分的开源项目做得不好。

作者: Phodal Huang 2020年4月13日 20:40

PS：文章仅为个人观点 —— 本文的内容基于我这几年在开源世界的观察得出的结论，并非调查所得到的结果。 上周，我在 GitHub 上发布了 Ledge 知识平台，我以一种“重量级”的方式来运行这个开源项目。换句话来说，以正确的方式运行起了这个项目。因为我知道怎么运作一个开源项目，加上一些外部的原因，我开始思考个人开源和组织开源的一些困境。 开始之前，让我讲个笑话和无奈： 组织开源的四大笑话是：一次性开源、按揭开源、KPI 驱动式开源、社区是什么？（分别代表了国内的几加大公司的开源做法） 不好意思，你们是对开源有什么误解吗？ ## 什么是开源 事实上，我们经常混淆了两个概念，那就是开源软件和开源这个行为。 > 开源软件是源代码可以任意获取的计算机软件，任何人都能查看、修改和分发他们认为合适的代码。开源软件依托同行评审和社区生产，皆以分散、协作的方式开发。 —— 红帽官网 换句话来说，你选择一个协议，将你写的代码公开发布，这叫开源一个软件。但是，它并不叫你搞开源。开源源于开源软件，但是它现在已经成为超越软件生产的运行和工作方式。 > 开源源于开源软件生产的运行和工作方式，它是一种基于去中心化、自组织式的软件开发模式运作的工作方式。它以社区作为根基，通过开放、透明、协作几项原则开展的活动。 ## 开源不是公开代码 在那本开源的《GitHub 漫游指南》里，我一直在讲述如何在 GitHub 上开发一个 “成功” 的开源项目。因为开源不仅仅只是说源代码的开源，还包含了设计文档、产品的内容等等，还要以开源的方式来运作。以 opensource.com 对于开源方式的解释来说，需要这么五个维度： 1. 透明度。 2. 协作。 3. 尽早发布、持续发布。快速建立原型，发布第一个版本，并且不断地快速地迭代。 4. 精英制度。根据提出的最佳方案做决定的方式 5. 社区。形成社区，提升社区参与度，转化为社区目标。 也因此，如果只是公开源码的话，那是走到开源的第一步，刚来到开源的起跑线上而已，还没参与到这个游戏中去。 ## 一个开源项目是一个产品 作为一个资深的开源运动参与者，我有一个这样的体会：运营一个开源项目，就好像创业一样。我们需要采用《黑客与画家》作者 Paul Graham 所说的创业公式： 1. 搭建原型 2. 上线运营 3. 收集反馈 4. 调整产品 5. 成长壮大 所以，开源就像是一场小型创业，需要进行竞品分析，需要制定合理的策略。当然了，如果你的东西绝无仅有，那就无需如此。而除了分析市场，针对于开发人员，还要考虑： 1. 作为投资人（技术投资），他们能获得什么？提升技术？找个好工作？ 2. 作为潜在的用户，从哪里知道这个项目？ 3. 作为贡献者，如何提供不同级别的贡献计划？ 4. …… 你并不一定非得去考虑这些问题，只要在持续完善的过程中，这些问题的答案就会浮现出来。只是呢，在你开始之前想好，可能会事半功倍。 ## 开源的重点在于生态建设 对于个人来说，开源的目的可能是找个好工作、为以后找个好工作……；对于一家组织来说，他们考虑开源可能有多种多样的目的： 1. 降低开发、维护成本。由社区来帮助寻找 bug，提出一些观点。 2. 技术影响力招聘 3. 建立技术壁垒。 4. 营造生态。 5. …… 一个好的开源作品，需要连接到上下游，即影响开发者，又影响使用者。慢慢地，它个作品就会成为一个影响行业的存在。尽管会不断有其它的项目冒出来，但是由于稳固的生态建设，将巩固组织在该领域的影响力。 ## 组织需要制定开源策略 从开头的大部分四大难题：一次性开源、按揭开源、KPI 驱动式开源、社区是什么？。我们就会发现：国内大公司的开源策略都是错的。 他们可能，今年发布 Phodal UI，明后发布 Phodal Compiler，后年发布 Phodal OS。然后，中间靠各种公关稿，完成在社区的宣传。 应该是这样的，今年发布 Phodal UI 1.0，年中发布 Phodal UI 2.0，明年发布 Phodal UI 3.0 和 Phodal Compiler 1.0，明年年中 Phodal UI 4.0 + Phodal Compiler 2.0。过程中，需要依赖于布道师来进行闭环： 1. 维护开发者关系 2. 在社区进行宣传 3. 对社区进行支持、收集社区反馈 4. 建立连接内部的通道 5. 促进内部进行改进。 这些组织需要建立一个具备可持续性的开源策略： 1. 明确其带来的业务价值（如人才引进 、生态等） 2. 专职的开发人员进行开源支持 3. 开放式的开源团队组织结构 4. 合理、适当地长期 KPI 考核机制 5. 政策和流程支持。如专项鼓励奖金 6. 明确地专利和知识产权机制 ## 开源到开放式组织 领导力变化，当我们在组织中开发一个软件应用时是以职权影响力为核心构建的；而开源方式，则是以非职权影响力构建的。 社区的每个人都可以提出自己的意见，你可以 say No，但是每个人都可以提出意见。就这一点来说，对于大部分的国内公司来说是一种挑战，大部分的领导希望听到统一的声音 —— 论组织内多样性的重要。 简单来说，大家想来就可以来，想走就可以走。所以，开源的一个难点就在于：如何吸引到人来参与开发。 尽管大部分项目都是围绕个人、团队的中心化开放式组织，如 linus 之于 Linux。但是，开源还可能变成一个中心化的组织，如 Node.js 的 IO.js 出走事件。根据开源协议，人们可以很容易派生出一个新的项目。 ## 结论 开源，就是生态。

作者: Phodal Huang 2020年4月8日 15:01

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