个人黑客马拉松

最近的一个月里，忙于设计一个架构设计问题，未来也仍将持续一断时间。 在业余时间里，过于投入的研究问题，以致于对于很多事情都提不起动力。比如，我在上个月挖的 Uncode 的坑，这个坑着实有点大。因此在没开始之前，我决定先休息一下，以获得更充足的动力 —— 事实上，我没这个精力了，2333。除此，也可能是因为当前的这个问题比较有意思，所以我投入的精力比较多。 正因为这是两颗磐石，在上一个清明假期里，我都没怎么做这两个相关的事情，我决定放个假去玩点别的 —— 因为花仲马在加班，所以我哪儿也去不了。 只有一个人的 Hackathon 回想起，几年前，我参加的几次公司的 Hackathon。对于公司和客户来说，它带来的是一些产品上的创意。对于个人来说，它带来了~~几天的休息时间~~激情碰撞的岁月。你大可以忘掉工作上那些烦人的...

6h

流程即代码：低代码 & 云研发 IDE —— Uncode

在先前的一系列《云研发：研发即代码》文章里，我们介绍了软件工程的代码化闭环。同时，在《Water：云研发架构模式》介绍了设计这样的开发环境里，我们所需要的一些模式。今天呢，作为这一系列的落地实践，我们将介绍云研发 IDE的设计思想，以及如何实现，当然还有一点儿早期代码：https://github.com/inherd/uncode。 第一次声明：这是一个概念性 IDE 的设计，暂不适合任何生产环境。 在开始真正阅读之前呢，为了能更好地让大家理解，我们要回顾一下软件工程行业： DevOps 理念在国内的软件行业有了长足的发展，在包括传统企业（银行、制造业）在内的公司里已经广泛接受，并进行了大规模推广。 云原生技术已经成为市场的主流趋势。云迁移与遗留系统上云是市场的一大热门话题。 中台方法论在实践上还缺少真正的成功案例。...

3w

数字技术战略：开发者体验 —— 内部工具的“最后一公里”

这是一篇迟来的文章，我本应该在很早之前写完，但是一直都发现时机不够成熟。去年，在经历了多个低代码前端项目的售前，以及一个低代码项目的技术实践强化，国内的 IT 企业缺乏对于『开发者体验』缺乏系统性的思考。 来，先我们来看一个开发者体验（DX，Developer Experience）的定义： 开发者体验，与用户体验类似，只是对象是软件开发人员。将之与国际进行对应，便是开发人员对于针对使用或期望使用的产品、系统或者服务的认知印象和回应。有所不同的是，用户关注的内容变为库，SDK，文档，框架，开源解决方案，通用工具，API 等的开发人员的体验。 而完善开发者体验是有一些基础条件的： 稳定性。SDK、库、框架等具备满足使用方持续可用的状态。 功能完备。可以满足大部分的正常的功能需求。...

3w

分层架构演化：从单体的插件化演化所引起的思考

最近，在为 Coco 优化分层架构之时，我陷入了各种决策困难之中。所以我通过不断地延迟决策，以摸清更适合现有系统的现状。换个简单来说，在危险边缘徘徊，以期待能获取最大的收益。 在设计新的架构时，我们总会凭借原先的经验，并结合业务现状的需求，并根据未来的需求做出我们的设计。即： 过去的经验。 现在的需求。 未来的方向。 种种因素的影响之下，它注定了我们无法设计一个满足所有历史时期的系统。未来会变成现在，现在会变成过去。 Coco 架构设计：从过去到过去的未来 原先对于 Coca 的各种设计问题，以及 Golang 对于多平台的支持问题等多方面的因素。迫使 Inherd 开源小组在 Coco 在初始阶段，便考虑了为 Coco 设计插件系统。直到最近，我们实现了插件系统之后，发现了原来设计的分层架构已经不满足现今的需求。...

4w

基于 Git 的代码物理分析

物理分析这一词，来源于我同事 @NoaLand 所推荐的《大规模 C++ 程序设计》一书中所介绍的物理设计。 物理设计集成于研究系统中的物理实体，及它们之间如何相互关联。逻辑设计只研究体系结构（架构）问题，物理设计研究组织问题。 在粗粗了这本书的一些概念之后，我对整体的物理设计思路有更深入的了解。于是，在结合了《系统重构与迁移指南》一书中引入的『四级重构』，重新论证了我先前的一个想法：并不需要成为 xx 语言的熟练开发者，我也能分析这个语言的系统设计得是否合理？ （PS：这是建立在我已经熟练使用多门语言 Copy/Paste 的前提下。） 于是乎，只需要学会对物理设计进行分析，就能成为架构上的砖家 —— 对于这部分的分析，是个程序员都会做。 而一系列的理论建立在几个基本的前提之下：...

Mar 2021

“内源”文化优于中台思想

内源即将开源方法（最佳实践、协作方式、架构模式等）融入到组织的软件构建和发布方式之中，以在组织内构建类似开源的文化。 作为一个站在国内开源前线的开发者（GitHub 国内 Top 10），我本应该早点写一篇关于：『为什么应该选择内源，而非中台？』。然而呢，中台一直在火，找不到合适的机会。直到最近，因为拆中台，所以它又火了。我觉得再不聊聊，下一个热点技术领域又要出现了。 对于大部分不了解开源的人来说，他们很难理解：为什么“内源”能解决中台没有解决的问题？内源不就是在内部建立起开源式的项目，它哪能比中台更好？ 为什么是“内源”优于中台？ 中台背景下的复用 对于中台的定义，大家都很了解了：企业级能力复用平台，又或者是，各类的复用、聚合、协调。它从组织的层面定义了，内部的各个系统及其如何协作。中台做了一个非常优秀的事情：定义了企业...

Feb 2021

轻量级架构可视化：Coco 实现

过去的十几天里，在 Inherd 开源小分队的努力之下，我们实现了 Coco 的第一个完整的功能 —— 实现对于一个项目的基本架构可视化。（PS：Coco 是一个研发效能分析工具，如团队发展现状（根据架构复杂度及行数变更）、团队演进、历史分析等。） 于是呢，为了验证开发流程的完整性，我们发布了 0.1.1 版本（当前仅构建了 macOS 平台，其它平台暂时未构建）。在这个版本里，我们实现了两个主要的命令行工具： coco。通过 CLOC、Git 等对项目进行你那样的。 visual（待改进）。对于 coco CLI 生成的结果进行可视化。 其中的一个重要的功能便是：交互式架构可视化。 架构图真的靠谱吗？ 在软件开发中，我们经常习惯性地使用各类可视化工具，如 UML，它们用于让开发人员快速了解系统某一部分的架构，快速熟悉不同元素之间的关系。相似的，对于架构进行可视化，能帮助我们迅速了解系统的现状，快速找到系统中的问题。...

Feb 2021

前端规划：我的 2021 前端技术战略

整体来看，从大的趋势上没有太大的变化。这里并不考虑某些特定的技术，而是从总体上（战略）层面来看待问题。所以，就有了这么几个点： 前端架构治理。 微前端“普及” 低代码平台的返璞 超越前端 看上去最后一点一直是如此，哈哈。 前端架构治理 前端架构治理是一个颇为复杂的问题，我们限入了一个困境：要做的事情很多，但是无奈 JavaScript 的灵活性困扰了我们每一步。所以，在某些时候，我们所能治理的东西比较有限。常见的一些有：构建优化、组件化、微前端等。 大型前端应用 单个前端应用上了一定的规模，这本身是比较少见的 —— 从比例上来看。但是一旦遇到的时候，就往往需要大量地工作，才能治理好整个前端应用，还需要配合开发一些工具。好在市面上已经有大量的类似工具，也可以编写如 Lemonj...

Jan 2021

写个取代自己的工具：Coco —— 自动化分析与建议

作为一个资深的软件工程师，我经常遇到其他/她开发人员大量的重复问题。过去只靠写博客，现在，我有了四种方式来解决： 博客。我的博客 phodal.com 上有 850+ 的博客 工具。创造开源工具解决重复性问题，如：ADR、Lemonj、Coca、Clij 开源电子书。系统性的归纳某一个领域相关实践和模式，如：《Serverless 应用架构》 知识平台。结合工具和电子书，如 DevOps 知识平台：Ledge 即使如此，依旧没有解决一个问题：我需要人力来分析项目、再抛出这些链接。于是，过去我一直就在想：能否做一个工具来取代自己？ 当然了，我的真实意思不是：取代我自己，而是取代我做的那些重复性活动。（PS：等写完之后，再写一个自动化写 PPT 的工具，就完美了。） 所以，我开始编写一个新的工具，一个关于对代码进行自动化分析与建议的工具。...

Jan 2021

2020 节点：平凡 & 重新出发

2020 年，庚子年，注定是不平凡的一年，所以就平凡的过去了。年初，疫情让我在家办公了几个月，年中开始了忙碌的几个月，年底又归于平凡。也因为疫情，多了一些 beach 的时间，不得不休完 20 天的看似，还有没机会用上的婚假，所以我有机会尝试一些新的想法。 太长不读版： 编程上，回到底层/系统编程，构建基础设施开发能力。 写作上，在 Ledge 项目上结合前端可视化，展示了知识管理的另一种可能性。 设计上，依旧还在一天一张画的练习上，暂时没有新的突破。 方法化上，丰富和完善了 DevOps/系统重构相关等知识体系。 影响力上，靠影响力带来了几个公司的项目，除此没有进展。 好像也没了。再对比一下上一年的目标： 工具，有了更多编程语言、软件工程相关的工具。 DSL 抽象，设计的...

Jan 2021