最近的一个月里,忙于设计一个架构设计问题,未来也仍将持续一断时间。 在业余时间里,过于投入的研究问题,以致于对于很多事情都提不起动力。比如,我在上个月挖的 Uncode 的坑,这个坑着实有点大。因此在没开始之前,我决定先休息一下,以获得更充足的动力 —— 事实上,我没这个精力了,2333。除此,也可能是因为当前的这个问题比较有意思,所以我投入的精力比较多。 正因为这是两颗磐石,在上一个清明假期里,我都没怎么做这两个相关的事情,我决定放个假去玩点别的 —— 因为花仲马在加班,所以我哪儿也去不了。 只有一个人的 Hackathon 回想起,几年前,我参加的几次公司的 Hackathon。对于公司和客户来说,它带来的是一些产品上的创意。对于个人来说,它带来了~~几天的休息时间~~激情碰撞的岁月。你大可以忘掉工作上那些烦人的...
6h
在先前的一系列《云研发:研发即代码》文章里,我们介绍了软件工程的代码化闭环。同时,在《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
物理分析这一词,来源于我同事 @NoaLand 所推荐的《大规模 C++ 程序设计》一书中所介绍的物理设计。 物理设计集成于研究系统中的物理实体,及它们之间如何相互关联。逻辑设计只研究体系结构(架构)问题,物理设计研究组织问题。 在粗粗了这本书的一些概念之后,我对整体的物理设计思路有更深入的了解。于是,在结合了《系统重构与迁移指南》一书中引入的『四级重构』,重新论证了我先前的一个想法:并不需要成为 xx 语言的熟练开发者,我也能分析这个语言的系统设计得是否合理? (PS:这是建立在我已经熟练使用多门语言 Copy/Paste 的前提下。) 于是乎,只需要学会对物理设计进行分析,就能成为架构上的砖家 —— 对于这部分的分析,是个程序员都会做。 而一系列的理论建立在几个基本的前提之下:...
Mar 2021
内源即将开源方法(最佳实践、协作方式、架构模式等)融入到组织的软件构建和发布方式之中,以在组织内构建类似开源的文化。 作为一个站在国内开源前线的开发者(GitHub 国内 Top 10),我本应该早点写一篇关于:『为什么应该选择内源,而非中台?』。然而呢,中台一直在火,找不到合适的机会。直到最近,因为拆中台,所以它又火了。我觉得再不聊聊,下一个热点技术领域又要出现了。 对于大部分不了解开源的人来说,他们很难理解:为什么“内源”能解决中台没有解决的问题?内源不就是在内部建立起开源式的项目,它哪能比中台更好? 为什么是“内源”优于中台? 中台背景下的复用 对于中台的定义,大家都很了解了:企业级能力复用平台,又或者是,各类的复用、聚合、协调。它从组织的层面定义了,内部的各个系统及其如何协作。中台做了一个非常优秀的事情:定义了企业...
Feb 2021
过去的十几天里,在 Inherd 开源小分队的努力之下,我们实现了 Coco 的第一个完整的功能 —— 实现对于一个项目的基本架构可视化。(PS:Coco 是一个研发效能分析工具,如团队发展现状(根据架构复杂度及行数变更)、团队演进、历史分析等。) 于是呢,为了验证开发流程的完整性,我们发布了 0.1.1 版本(当前仅构建了 macOS 平台,其它平台暂时未构建)。在这个版本里,我们实现了两个主要的命令行工具: coco。通过 CLOC、Git 等对项目进行你那样的。 visual(待改进)。对于 coco CLI 生成的结果进行可视化。 其中的一个重要的功能便是:交互式架构可视化。 架构图真的靠谱吗? 在软件开发中,我们经常习惯性地使用各类可视化工具,如 UML,它们用于让开发人员快速了解系统某一部分的架构,快速熟悉不同元素之间的关系。相似的,对于架构进行可视化,能帮助我们迅速了解系统的现状,快速找到系统中的问题。...
Feb 2021
整体来看,从大的趋势上没有太大的变化。这里并不考虑某些特定的技术,而是从总体上(战略)层面来看待问题。所以,就有了这么几个点: 前端架构治理。 微前端“普及” 低代码平台的返璞 超越前端 看上去最后一点一直是如此,哈哈。 前端架构治理 前端架构治理是一个颇为复杂的问题,我们限入了一个困境:要做的事情很多,但是无奈 JavaScript 的灵活性困扰了我们每一步。所以,在某些时候,我们所能治理的东西比较有限。常见的一些有:构建优化、组件化、微前端等。 大型前端应用 单个前端应用上了一定的规模,这本身是比较少见的 —— 从比例上来看。但是一旦遇到的时候,就往往需要大量地工作,才能治理好整个前端应用,还需要配合开发一些工具。好在市面上已经有大量的类似工具,也可以编写如 Lemonj...
Jan 2021
作为一个资深的软件工程师,我经常遇到其他/她开发人员大量的重复问题。过去只靠写博客,现在,我有了四种方式来解决: 博客。我的博客 phodal.com 上有 850+ 的博客 工具。创造开源工具解决重复性问题,如:ADR、Lemonj、Coca、Clij 开源电子书。系统性的归纳某一个领域相关实践和模式,如:《Serverless 应用架构》 知识平台。结合工具和电子书,如 DevOps 知识平台:Ledge 即使如此,依旧没有解决一个问题:我需要人力来分析项目、再抛出这些链接。于是,过去我一直就在想:能否做一个工具来取代自己? 当然了,我的真实意思不是:取代我自己,而是取代我做的那些重复性活动。(PS:等写完之后,再写一个自动化写 PPT 的工具,就完美了。) 所以,我开始编写一个新的工具,一个关于对代码进行自动化分析与建议的工具。...
Jan 2021
2020 年,庚子年,注定是不平凡的一年,所以就平凡的过去了。年初,疫情让我在家办公了几个月,年中开始了忙碌的几个月,年底又归于平凡。也因为疫情,多了一些 beach 的时间,不得不休完 20 天的看似,还有没机会用上的婚假,所以我有机会尝试一些新的想法。 太长不读版: 编程上,回到底层/系统编程,构建基础设施开发能力。 写作上,在 Ledge 项目上结合前端可视化,展示了知识管理的另一种可能性。 设计上,依旧还在一天一张画的练习上,暂时没有新的突破。 方法化上,丰富和完善了 DevOps/系统重构相关等知识体系。 影响力上,靠影响力带来了几个公司的项目,除此没有进展。 好像也没了。再对比一下上一年的目标: 工具,有了更多编程语言、软件工程相关的工具。 DSL 抽象,设计的...
Jan 2021
Subscribe to RSS Feeds, Blogs, Podcasts, Twitter searches, Facebook pages, even Email Newsletters! Get unfiltered news feeds or filter them to your liking.
Get Inoreader