硬核

软工爬坑之旅(三)——趋同演化

. 5 min read . Written by seki
软工爬坑之旅(三)——趋同演化

趋同

趋同演化(英语:Convergent evolution)指的是两种不具近缘关系的生物长期生活在相同或相似的环境(或生态系统)中,因应需要而发展出相同功能的器官(即同功器官)的现象。

在「序」中我提到过——

“交互设计其实源于开发者的工作,而非视觉艺术。在我看来,体验设计(UX)等于交互设计+UI设计。”

最初,交互设计是作为软件设计的一部分——即「机器与人类之间接口」而存在的,那个年代,一个软件GUI部分的设计由两类人完成:艺术家和开发者,艺术家将图形绘制出来,开发者将其在软件中实现。

https://www.researchgate.net/profile/Demosthenes_Akoumianakis2/publication/256104120/figure/fig5/AS:392613606772746@1470617786959/The-Desktop-metaphor.png

后来,交互设计的工作从开发者中独立出来,成为单独的学科,而软件开发需求量增大,计算机图形渲染能力的提升,又促成了一类新职业的诞生——即UI设计师。最终,两者逐渐融合,成为「体验设计」的两个维度。

——这就是科学与艺术的趋同演化。

设计?设计!

“帮我设计一张新名片。”

“这个方案不行,需要重新设计一下。”

“邓小平是改革开放的总设计师。”

——请分析三句话中「设计」一词的含义。

好吧,讨论这个话题是因为我不止一次发现设计出身的人在学习软件工程时会对「设计」一词感到迷惑。软件工程的「设计」所讨论的是从想法到进行开发之前的一段工作——例如需求分析、结构设计、数据设计等等。

是不是和交互设计的方法论有些类似?毕竟,交互设计是脱胎于软件设计的。

建模

又一个容易让人误解的词。

软件设计中的「建模」与「3D建模」完全不是一回事,软件「建模」的工作同样在开发者实际敲下代码之前——严格来说,建模工作属于软件设计的「战略设计」部分:把这个软件划分成哪些块?每一块有什么目标?由多少人来负责?这些都是「建模」要规划的事情。

一个登录界面的时序图

方法

让我们用更极客一点的方式来定义「方法」:

如果说「设计」是实际的工作,是一种对象,那么「方法」就是它的类。方法抽象于实践并获得成功后的具体设计,并复用于下一次战斗。

设计务实,方法务虚。方法是一种思想, 如果没有方法的指导,那么实际工作将可能失去方向。

DDD(领域驱动设计)便是一种方法。

设计师眼中的DDD

2003年,程序员Eric Evans写了一本名叫「Domian-Driven Design(领域驱动设计)」的书,他在长期的软件设计实践中发现,软件架构应该与软件实现的演进保持一致,但在当时,这本书没有引起太大反响。

时间过了十年,谷歌、微软等一些有影响力的大厂开始采用Microservices(微服务)的架构来设计复杂且快速变化的业务,这时人们发现DDD的方法可以指导微服务设计,于是在DDD火了。

“组织沟通方式决定系统设计。”——康威定律

DDD的概念火到了大洋彼岸,一位设计师也开始学习这个复杂的玩意,他打算用自己的语言来解释DDD:

微服务架构也是OO(面向对象)的一种实现,想象一下,把业务拆分成许多个「服务」,每个服务至少可以独立完成一件事情。服务之间相互独立,并且由不同的开发小组完成。

这样一来,每个小组都能独自完成自己的工作,他们之间用数据(文档)来沟通。

——这便是微服务,每个小组都是独立的「对象」。

但是微服务也存在问题,最大的问题在于「人非机器」——

  • 人不能像机器一样快速阅读(读取)、记忆(存储)
  • 人用自然语言,而非数据进行沟通
  • 人类容易出错

于是,当微服务过于臃肿时,庞大的文档将成为累赘,人们渴望更好的沟通方式。

DDD的方法一定程度打破了这种隔阂——

首先,打破语言的隔阂,采用统一语言(UML),这样一来,每个人都能看懂周围的服务。

其次,设置「领域」来保证低耦合度,引入「领域专家」,领域专家可以为领域内的工作建模,拥有决定权。

总之,DDD让人重新说起了人话,每个人都可以参与到微服务的设计中,每个人本身成为微服务的一份子。

——设计师眼中的DDD(完)