Doug Slater 10月02日 20:55
设计是代码的模具
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

文章以模具制造为比喻,探讨了软件设计如何像模具一样塑造代码。作者指出,代码填充软件设计的负空间,随着时间的推移,代码固化并变得更难改变。文章比较了Chrome和Firefox这两个独立实现的浏览器,它们虽然代码库不同,但在遵循的Web标准上是等价的。文章强调了设计导致代码,而非代码导致设计,并讨论了从代码反向推断设计的不易性和局限性。文章还提出了保持软件生命力的几个方法,如用自然语言记录设计、使设计在代码中显而易见、使用精确的抽象、使用有效的隐喻以及使代码易于理解。

🔍 设计像模具一样塑造代码,代码填充设计的负空间,随着时间的推移,代码固化并变得更难改变。

🌐 文章以Chrome和Firefox为例,说明了虽然两个浏览器的代码库不同,但在遵循的Web标准上是等价的,体现了设计的等价性。

📝 强调设计导致代码,而非代码导致设计,并讨论了从代码反向推断设计的不易性和局限性。

✍️ 文章提出了保持软件生命力的几个方法,如用自然语言记录设计、使设计在代码中显而易见、使用精确的抽象、使用有效的隐喻以及使代码易于理解。

🧠 指出代码库可能太大,难以完全装入开发者的大脑,且从低级细节推断高级概念很困难,如将汇编代码反编译回C代码。

I'm always in search of good metaphors for software design. Good or not, here's one:

A Design is a Mold for Code

In manufacturing, a mold is a hollow shape that fills with fluid material which expands into the space and sets to form a casting.

Image: A useful mold. Generated by Dall-E

Like in manufacturing, code fills the negative space of a software design. Over time, code sets and becomes harder to change.

Imagine two engineering teams who independently "fill" (implement) a design, and the design is the set of standards for a web browser. The two implementations are Chrome and Firefox. The two browsers have independent codebases[1] which take vastly different shapes, but as far as web standards are concerned, the two are equal. You could switch from Chrome to Firefox (which I recommend) and still browse compliant web pages with no discernible change.

Programmers who also like math sometimes call two pieces of code which can be swapped isomorphic with respect to the spec.

It's important not to reverse the causality: a design causes the work product, not the converse. A mold causes a casting, and a software design causes code. Nevertheless, to some extent, one can go in reverse, i.e. reconstruct a mold from a casting or infer a design from code.

The reconstructed mold might lose some fidelity, like sharp edges or precise dimensions, but it's far worse for code. Looking at code without supplemental information, a new dev can only infer a dim, vague notion of its design. She might even sense the mind(s) behind the design. However, it would be costly if even possible to losslessly reconstruct the design, i.e. to such a fidelity that it could be the basis for an isomorphic implementation.

In pseudocode:

[Test]fn Reverse_ProducesIsomorphicDesign() let design1 : ... let code1 = implement(design1) let design2 = reverse(code1) let code2 = implement(design2) assert(isomorphic(code1, code2)) // Fails

Above: The roundtrip from a design to code back to design is lossy.

There are a few reasons for this:

This is a problem for software that outlives its creator(s). The software will languish unless knowledge is retained and replicated.

There are some things developers can do to keep their software alive:


Notes

    Firefox and Chrome are not truly independent by this definition. Plenty of people who have worked on one browser have also worked on the other. Moreover, as open source projects, both teams can see the other's code. Chromium source and Firefox source

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

软件设计 代码 模具 Chrome Firefox Web标准 抽象 隐喻
相关文章