AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

软件质量的黄金准则

  • 2020-08-13
  • 本文字数:2056 字

    阅读完需:约 7 分钟

软件质量的黄金准则

在关于软件质量的相关谈论中,我通常会引用一条经验法则。所以,我决定发帖总结一下。我将其称为“软件质量的黄金准则”,因为它简单明了,并且可以广泛使用。


黄金准则如下:


宁可在 upstream (上游,接近问题的根源层面) 推送补丁,也不要在 downstream (下游,远离问题根源的层面) 解决问题。


我将在本文引用 Haskell 社区和生态系统的例子,进一步解释这个准则对软件工程 tradeoffs 的影响。


免责声明:软件质量的黄金准则不代表你对待他人的黄金准则,反之亦然。

第三方依赖

很多开发者项目都借助于第三方依赖或工具,但他们却很少思考如何修改或改进这些第三方代码。相反,他们更多屈从于旁观者效应。这也就意味着如果一个项目的应用越广泛,那么开发者就会越发理所应当地认为会有人帮助他们解决一切问题。长久以往,这些开发者在面对热门工具中的问题就会熟视无睹。


举例来说,很长一段时间以来,Haskell 不支持访问资料字段的点语法。在 Java 中,如果想要修改嵌套结构资料中的数值,只需要将参照变数串起来,例如:


a.b.c.d.e = 10 
复制代码


但是,在 Haskell 中则是每多一层,每个等号就会重复之前等号的序列并多一个取值用的函数,例如:


a <- a{b=(b a){c=(c (b a)){d=(d (c (b a))){e=10}}}} 
复制代码


Haskell 社区在 downstream 通过各种方式 ,包括 lens 在内的软件包,试图模拟点语法。这种方式有好有坏,好处在于拥有一流的数据访问器,缺点则是不尽如人意的类型推理、错误信息,以及缺乏编辑器对字符完成的支持。直到最近,Neil Mitchell以及Shayne Fletcher才通过 RecordDotSyntax提案将这个功能直接 upstream 到语言中,从根本上解决了这个问题。


从“软件质量的黄金准则”角度来看,开发者应当更倾向于直接改进依赖的工具和软件包,即‘upstream 推送补丁’,而非在本地迂回,逃避问题,即‘downstream 绕过问题’。这类 upstream 改进可以直接作用于以下几点:


  • 编辑器/IDE

  • 命令行 shell

  • 所使用的编程语言

  • 所依赖的软件包


注意,upstream 解决问题的成功率并不是百分之百,尤其是当某些 upstream 不欢迎外界贡献者时,但至少也要尝试下,再说放弃。

类型化 API

函数类型同样可以遵循这个准则。假如有两种方法可以为 head 函数分配一个“安全”(总计)类型,用于获取列表中的第一个值。


第一种方法将错误推到了 downstream:


-- Return the first value wrapped in a `Just` if present, `Nothing` otherwise head :: [a] -> Maybe a 
复制代码


而第二种则将需求推到 upstream:


-- Return the first value of a list, which never fails if the list is `NonEmpty` head :: NonEmpty a -> a 
复制代码


根据黄金准则,后者应当更得人心。第二种方法的head类型签名需要一个非空输入,通过禁止用户提供空列表,从而将修复措施推到了 upstream。 更一般地讲, 如果你能践行这条规则的话,最后就会做到让非法状态无法表示


在上述例子中,前者的head类型签名则是通过返回一个Maybe来绕过可能存在的空列表。这种类型提倡在过程后期捕捉错误,错误不会在第一时间反馈,导致软件质量的降低。而如果想要提升质量,则应当直接在 upstream 中问题的根源那里快速失败,而不是根据 downstream 的问题症状位置间接调试。

社会分工

我是康威定律的坚持拥趸者,根据该定律:


设计系统的架构受制于产生这些设计的组织(广义定义)的沟通结构。

—— 马尔文·E·康威


我有时将其解读为“社会分歧导致技术分歧”。


如果社会问题是技术问题的 upstream,那么依据黄金法则,我们应当优先解决根本原因(社会摩擦),而不是试图用技术解决方案掩盖社会分歧。


Haskell 社区内的经典例子,cabal 与堆栈的分歧,源于 FPComplete 与 Cabal 贡献者之间的分歧(根据 Haskell 的 reddit 子版块反馈修正)。由于未能解决 upstream 收费贡献者与开源贡献者之间的摩擦,导致 downstream 需要通过创建并行安装工具这样的技术解决方案来尝试绕开这个问题。如此一来,Haskell 社区分崩离析,导致初次使用的新手一头雾水并且用户体验极差。


这并不意味这 Haskell 社区中的分歧可以得到解决,也许收费贡献者和开源志愿者之间的矛盾是不可调和的,但这个例子仍然说明了未能在源头解决问题对质量的明显影响。


(译注:对国人来说,一个更广为人知的例子是 12306 电子售票系统:12306 问题的 upstream 是春运期间庞大人流量与铁路客运能力之间的供求矛盾,而 downstream 则是 12306 平台本身的数据处理能力和 UI 设计质量。显然,如果前者未能得到缓解甚至恶化,则后者的改进并不会从根本上解决广大旅客购票困难的问题,顶多是消灭频繁的卡顿和崩溃现象,而代之以"平滑"的购票排队体验——简单来说,该排队还是要排的。)

结语

请注意,软件质量的黄金准则并不是要求你必须在 upstream 解决问题,该准则只是建议,如果其他选项条件相同,那么应当优先选择 upstream 修复。有时,出于其他因素的考量,例如金钱或时间的限制,不得不放弃 upstream 修复。但如果我们希望质量为上,那么还是应当尽量遵守这个准则的。


原文链接:


http://www.haskellforall.com/2020/07/the-golden-rule-of-software-quality.html


2020-08-13 16:491732
用户头像

发布了 194 篇内容, 共 131.9 次阅读, 收获喜欢 217 次。

关注

评论 1 条评论

发布
用户头像
这篇文章想表达的观点:找到问题的根源, 从根源上解决问题
2020-08-14 11:13
回复
没有更多了
发现更多内容

Rust从0到1-错误处理-panic!还是Result

rust 错误处理 result panic!

架构实战营 模块四作业

夏日

架构实战营

华仔架构训练营作业(模块四)

不听不听王八念晶

架构实战营 模块四作业

Dylan

架构实战营

“三次握手,四次挥手”这么讲,保证你忘不了

三分恶

计算机网络

千万级学生管理系统的考试试卷存储方案

王瑞强

架构实战营

身份认证

escray

学习 极客时间 安全 5月日更 安全攻防技能30讲

架构师训练营模块4作业

歲月鎏金😈

python 高级函数补充

若尘

Python编程 高级函数 5月日更

探索GaussDB(DWS)的过程化SQL语言能力

华为云开发者联盟

数据库 GaussDB(DWS) SQL语言 PLSQL语言 索引表达式

云计算下半场:打法已变,谁主沉浮

ToB行业头条

云计算

懂得取舍才是缓存设计的真谛

万俊峰Kevin

缓存 cache 分布式缓存 Go 语言

过拟合 - DAY13

Qien Z.

5月日更 过拟合

如何实现一个简易版的 Spring - 如何实现 AOP(上)

mghio

Java 技术 后端 基础知识 spring aop

架构实战营模块 4 作业

梦寻解语花

架构实战营

架构实战营 模块四课后作业

iProcess

架构实战营

【Flutter 专题】122 图解自定义半遮挡头像 SeriesCircleProfile & CircleAvatar

阿策小和尚

5月日更 Flutter 小菜 0 基础学习 Flutter Android 小菜鸟

架构营作业-模块4

大师兄

架构实战营模块四作业

冷大大

作业 架构实战营 模块四

腾讯云CLS日志服务初体验

三掌柜

5月日更

架构实战营 模块4 作业

CR

集成学习案例二 (蒸汽量预测)

容光

《Spring 手撸专栏》第 3 章:初显身手,运用设计模式,实现 Bean 的定义、注册、获取

小傅哥

Java spring 设计模式 小傅哥 抽象类

聊聊dubbo协议2

捉虫大师

dubbo 协议

第四课作业

杰语

设计千万级学生管理系统的考试试卷存储方案

thewangzl

Spring cloud 之熔断机制

Damon

5月日更 熔灾

思考题太难了

Nydia

mongodb 修改字段类型

xiaolu

mongodb

NumPy之:ndarray中的函数

程序那些事

Python Numpy

重命名表,应该怎么做?

Simon

MySQL

软件质量的黄金准则_语言 & 开发_Gabriel Gonzalez_InfoQ精选文章