Blog | Phodal 全栈工程师

Blog

Latest articles

设计测试策略

距离我一次写测试相关话题的文章,已经有相当长的一段时间了。对于自动化测试相关的内容,我大抵还算是熟悉的。毕竟,开发人员写测试这件事在 ThoughtWorks 是自然而然的,它也体现在我的开源项目上。恰好,最近我正在帮助客户设计和实施测试策略。 我便有了想法重新写一篇文章,体系性的介绍一下相关的内容。我那已经达到 800+ 篇的博客,正好缺失这样的一篇文章。 PS:我并非一个专业的测试工程师,其中若有偏颇之处,欢迎大家指正。 什么是测试策略? 测试策略是一份在特定环境约束之下,描述软件开发周期中关于测试原则、方法、方式的纲要,并阐述了它们之间如何配合,以高效地减少缺陷、提升质量。在这份策略中,需要描述测试的类型、目标、方法、准入准出条件、所需的时间、资源以及环境等信息。 测试策略是一个因地制宜地策略模式,针对于不同的公司、不同的团队、不同类型的项目,相关的内容内容或多或少会出现变化。如对于快速迭代的互联网公司来说,单元测试、UI...

Rust.unwarp(): 编译器驱动开发

用 Rust 来写个应用,这个想法颇久了。之前呢,要么找不到合适的场景,要么觉得 Rust 门槛有些高。直到最近呢,刚好对底层编程有点想法,便想着用这门语言做点东西玩玩。 考虑到,我用这门语言的时间只有一星期多,某些观点和感受并非那么准确。因此,我的观点并不适合作为一份参考材料。 Rust 是什么? 让我来 copy 一下 Rust 是由 Mozilla 主导开发的通用、编译型编程语言。设计准则为“安全、并发、实用”,支持函数式、并发式、过程式以及面向对象的编程风格。 Rust 语言原本是 Mozilla 员工 Graydon Hoare 的私人项目,而 Mozilla 于 2009 年开始赞助这个项目,并且在 2010 年首次揭露了它的存在。 顺便加上 MDN 上的介绍:...

迁移防护网

每次看到遗留系统的时候,我总想着设计一个迁移方案。时间一久,收集的案例一多,外加上我也有了越来越多的案例,便想着记录一下这些内容。 遗留系统的迁移 遗留系统的迁移是一个相当复杂的工作,以至于重写的成本甚至比迁移的成本更高。但是从技术维度来看,步骤无非就是: 设定迁移的目标 制定迁移的计划 迁移计划的验证(PoC) 实施应用程序的迁移 校验迁移结果 对,就是这么简单。 遗留资产 我们通过把数字化时代的遗留资产划分了这几种类型: 遗留代码。所有没有测试的代码。 遗留基础设施。所有不安全、没有弹性、不可靠的基础设施。 遗留系统。所有不可观察、没有支持的自制系统或者商业化系统(COTS) 遗留架构。所有限制交付价值的架构。 旧式流程。所有不可度量的流程(缺少...

停止复用

最大化重用会使得可用复杂化。 —— 《Java 应用架构设计》 这个标题有点标题党了,但是我觉得你能理解:为什么我会用这么一个吓唬人的标题? 文章起源于我对于模块化、微服务、Serverless 以及单体应用几种不同的架构模式的思考。而这其中的一个原因就是:人们经常从一个极端走另外一个极端。既然单体不好,那么我们就要 FAAS 来替换单体;既然模块化架构有各种问题,那么我们应该回到大单体。 微架构 微架构是一系列架构风格的总称,通过构建一系列责任单一的小型应用,再组合出一个复杂的大型应用系统。受限于不同的运行环境,它还具备有不同的特性。 对于运行操作系统的微架构来说,它具备了语言无关的特性,如微服务;对于运行在浏览器的微架构来说,它具备了易于集成遗留系统的优势,如微前端;对于运行在移动操作系统虚拟机环境的微架构来说,它具备了应用可嵌入式的特质,如插件化。...

README 驱动开发

最近,我又挖了几个开源项目的坑,Ledge、Ledge Framwork、Igso 等等。每次挖新坑的时候,经常性地都要花很多的时间,想着怎么编写 README、完善 README。而就是这么一个简单的 README 的编写,它都要花费我相当长的时间,或是几个小时,或是几天。 问题来了,我真的是在写 README 吗? 引子 1:不止自述的 README README,又称“自述文件”,是随着软件发布的一种说明文件,里面通常包含有软件的描述或使用的注意事项。 在众多的开源项目里,README 是我们最常修改的文件之一。每当我们添加了一个新的功能,一个新的特性的时候,我们的第一反应就是更新一下 README,以向世人宣告我们的开源产品又添加了新的功能。 所以,在我的那本《GitHub...

开源游戏:开源会为企业带来什么

上周在公司内部又做了一次关于开源的分享,与三月份那次稍有不同的是,这次的关注点主要是:企业与开源软件。 开始之前,让我们再说说开源软件到底代表的是什么? 开源软件是源代码可以任意获取的计算机软件,任何人都能查看、修改和分发他们认为合适的代码。开源软件依托同行评审和社区生产,皆以分散、协作的方式开发。 由于,这篇文章所针对的是企业,所以这里的侧重点是:开源会为企业带来什么?按照这个模式,分享的内容分为了四个部分: 开源发展现状 开源发展案例分析 企业开源能力模型 企业开源模式 考虑到『开源发展案例分析』是各种业内案例,不适合用文章描述,这里就只介绍剩下的三个维度。 开源发展现状 按照时间线,我把开源划分了四个时代: 弱版权时代。哪来的闭源。Unix 在...

逆数字化:数字化时代的自由在何处?

很早以前,我便想着写一篇文章吐槽一下数字化时代。如果你熟知我在开源世界的贡献(代码 + 内容),就知道我一直是开源软件、自由软件的拥趸:RMS 一直是对的 [🐶🐶🐶] 。 首先,在这里讨论的是法律规定以内的自由,也就是守法前提下的自由。 直到,最近发生了一些事情,我才开始重新重视了一下这个问题。从现象来说,大致是这样的: 数字的『所有权』。我买了一本电子书,但是我只有阅读版权,而非所有权。如果是一本实体书,我可以把它出借个我的朋友,又或者是再次出售。除此,内容的提供商,它们『随时』有可能剥夺了我的使用权。尤其是,在中国特色的内容体系下。 随时可消失的数字产品。这个故事的起源是,我开通了网易云音乐的 VIP,而我在下载到本地的音乐会被它们删除。因为它们失去了版权,所以我们的相关歌曲都会被删除。当然了...

需求代码化

需求代码化,即将软件开发需求抽象为特定的领域语言,并使用管理代码一样的方式来管理需求,追踪需求的变化 。同时,为通过新的 API 来对接版本管理系统,以可视化需求,演变为看板代码化。 为了解决某种需求/需要,我们计划设计一个软件系统。通过与利益相关者进行交流之后,确认了新的系统是有必要存在的。于是,我们产生了一系列的概念和想法,并通过诸如愿景梳理、用户分析等一系列的想法,我们将这些想法明确下来。 在开始软件开发前,我们定义好了产品是什么,随后梳理出了用户故事地图。我们定义了在什么场景下,需要哪些用户,在哪里做些什么事情,并对这些行为做出响应。有了这些定义之后,我们作为这个系统的架构设计师,便开始思考需要保存、显示哪些数据,才能完成这个业务目标。 在进入开发之前,这些想法设计等,都被明确为软件需求,简称为需求。...

Yiki:元微前端框架

PS:Yiki(YY + Wiki)是一些关于软件开发、软件架构新设计的原型思考的 wiki。它针对于一些即将出现的新模式而设计,但是在当前阶段又缺乏足够的时间进行设计。(主要是最近没时间造这个轮子) 在过去的一两年里,从我接受到的一些线上、线下咨询的情况来看,微前端架构被越来越多中大型系统所采用。它们被用于不同类型的问题: 团队间协作 遗留系统改造 通过新技术创造价值(KPI) 这段时间里,也诞生了一个又一个优秀的微前端框架,如为 Angular 设计的 ngx-planet,还有适用于多种框架的 Umijs 的 qiankun……。 由于不同的微前端框架都源于它们的使用场景,也受限了它们不能满足于其它场景。受限于使用场景,这些微前端框架都需要不同程度的改造,才能满足各自的需要。...

云开发

随着持续部署、DevOps 在各个企业的推进,越来越多的企业已经有完善的基础设施,软件开发团队只需要一个在线的 IDE,就可以完成开发工作,这就进入了云开发时代。 什么是云开发? 云开发,是一种将开发过程完全迁移至云端的云原生开发模式,开发者可以在浏览器端、客户端完成一切的软件开发活动,如代码修改、调度、本地构建、代码提交、部署等等活动。其展示形式往往是通过在线 IDE 的形式完成。 在过去的一二年里,有越来越多的云厂商,选择了云开发的模式。值得注意的是,我们在这里定义的云开发和国内云厂商定义的云开发略有不同。国内云厂商所针对的是轻量级的应用开发,这里我们所针对的是所有场景下的云开发模式。换句话来说,支持轻量级应用开发是一个必由之路(MVP)。 对于一个云开发产品来说,它具备了这么一些关键要素:...

Discover, share and read the best on the web

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
Inoreader - Subscribe to RSS Feeds, Blogs, Podcasts, Twitter searches, Facebook pages, even Email Newsletters!