《人月神话》(P5)设计与实现分离

简介: 概念完整性绝大多数的欧洲大教堂,是由不同时代、不同的建筑师的设计所构成的。后来的建筑师总是试图在原有建筑师的基础上有所“提高”,所以雄伟的哥特式教堂上,依附着祥和的诺曼底十字架,展现出属于各个设计师的骄傲。

概念完整性

绝大多数的欧洲大教堂,是由不同时代、不同的建筑师的设计所构成的。后来的建筑师总是试图在原有建筑师的基础上有所“提高”,所以雄伟的哥特式教堂上,依附着祥和的诺曼底十字架,展现出属于各个设计师的骄傲。

对于计算机体统而言,绝大多数系统体现出的概念差异和不一致性远远超过欧洲的大教堂。这不是由于不同时代的设计师开发的原因,而是由于设计被分成了由若干人完成的任务。

我主张,在系统设计中,概念完整性是最重要的考虑因素,为了反映连贯的思路,宁可舍去不规则的特性和改进,哪怕它是更好的。在本章和以下两章里,我将说明这个观点的重要性。

  • 如何获得概念完整性
  • 是否需要一位杰出的精英,和一群思想被压制的平民编程人员
  • 如何避免设计师制定出无法实现或者代价高昂的方案
  • 如何确保实现人员充分理解设计,并正确的整合

获得概念完整性

软件系统的目的是使计算机更加容易使用,功能与概念的复杂程度的比值才是系统设计的最终测试标准,单是功能多或者系统简洁都无法成为一个好的设计。

对于给定级别的功能,能够用最简洁和直接的方式来实现的系统是最好的。只是简洁是不够的,引入很多独特的基本概念,可以达到所需的简洁特性,但它们并不直白。而且仅仅了解基本要素的组合规则还不够,还要学习习惯用法,以及如何在工作中进行组合。在语法上,每个部分都应该使用相同的技巧,在语义上,应该具有相同的相似性。因此,易用性实际上需要设计的一致性和概念上的完整性

贵族专制统治和民主政治

为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成。对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力的方法(同样适用于小型项目)。这种方法曾经在IBM的产品线上获得过巨大的成功。必须将结构和实现区分开来,前者描述发生了什么,后者描述如何发生的。如同时钟一样,小孩子都能明白如何辨认时间,而时钟的实现,描述了表壳中的种种机械方案。

系统结构师,如同建筑的结构师一样,代表的是用户的利益。结构师的工作,是运用专业技术知识来支持用户,而不是维护限售人员、制作者所鼓吹的利益。

难道不能遵循民主的理论,从所有员工中搜寻好的创意以获得更好的产品?

这问题是很简单的,并不是结构师才有最好的创意。新的概念经常来自于用户和实现人员,然而为了概念完整性、易用程度,最好将不能与系统基本概念进行整合的良好想法和特色放到一边,不要采用。

是否必须由一些智力精英来告诉可怜的实现人员如何工作?

对于结构师专制的问题,答案是肯定的。他们是少数人,他们的工作产物的生命周期比实现人员的产物要长,并且结构师一直处在解决问题,实现用户利益的核心地位。如果想要系统概念上的完整性,那就必须有人控制这些概念,这是一种无需任何歉意的贵族专制统治。

是否创造性活动都被这些精英独占,实现人员仅仅是机械中的齿轮?

关于创造性的问题,答案是否定的。因为结构人员和实现人员的工作都同样富有创造性,只是性质不同而已。在给定的系统体系下实现其设计,同样需要创造性的新思路和卓越的才华。实际上,产品性能很大程度上依赖实现人员,就像易用性依赖于结构师一样。在很多领域,一定的限制反而会增项小组人员的创造性,因为他们的目标更明确,注意力更集中。在毫无限制的小组中,决策过程会出现大量的争议和想法,对具体实现的关注反而较少。

以上是《人月神话》第四章——贵族专制、民主政治和系统设计前3节的内容

一个整洁、优雅的编程产品必须向它的每位用户提供一个条理分明的概念模型,这个模型用于描述应用本身和它的实现方法,指明操作参数和界面策略,以此来保证概念完整性从而提升系统的易用性。有很多由一个人或者两个人设计的杰出软件,比如之前火热的手游“宝石迷证”和“植物大战僵尸”,那些经典的书籍和音乐也是采用这样的方式创造出来的。

然而,很多产品的开发无法使用这种获得概念完整性的直接方法,很多现代软件的最终产品是非常复杂的,光是设计就需要很多人月的工作量,而且周期紧迫竞争异常激烈。因此最困难的问题就是,如何组织大型团队获得和单人开发项目时的概念一致性。这就是《人月神话》关注的主要问题。

本章采用逆向思维的方式,巩固了上一章提出的“外科手术团队”和“概念完整性为主”的观点,对可能会出现的种种问题和质疑角度进行分析,使得我们更加确信概念完整性是产品质量的核心,结构师是确保概念完整性的重要环节

同时,本章提出了第三个核心概念——必须将设计与实现分离。那么分离之后是否又会继续增加沟通交流的工作量?对于系统的复杂度又会有什么影响?这些方案真能够解决“人月”的不合理问题吗?

目录
相关文章
|
4天前
|
设计模式 前端开发 网络协议
软件体系结构 - 软件架构复用
软件体系结构 - 软件架构复用
16 0
|
6月前
|
设计模式 算法 Java
设计模式第十五讲:重构 - 改善既有代码的设计(下)
设计模式第十五讲:重构 - 改善既有代码的设计
239 0
|
7月前
|
消息中间件 架构师 安全
重新认识架构 — 不只是软件设计
通常情况下,人们对架构的认知仅限于在软件工程中的定义:架构主要指软件系统的结构设计,比如常见的 SOLID 准则、DDD 架构。一个良好的软件架构可以帮助团队更有效地进行软件开发,降低维护成本,提高系统的可扩展性和可维护性。这里的架构定义有更多元化的理解:架构不仅是对软件开发设计和流程规范的定义,也包含了参与架构设计的人员、以及项目过程中和架构有关的活动,都可以称为架构。 从广义角度来理解架构,意味着更全面的思考和新的融合。
23 0
|
存储 架构师 数据可视化
一文弄懂数据架构和信息架构的区别
我们经常会听到关于数据架构和信息架构的讨论,它们是一回事吗?让我们看看数据和信息之间的区别,以及组织需要考虑的关键事项。
一文弄懂数据架构和信息架构的区别
|
6月前
|
设计模式 Java 测试技术
设计模式第十五讲:重构 - 改善既有代码的设计(上)
设计模式第十五讲:重构 - 改善既有代码的设计
258 0
|
7月前
|
消息中间件 架构师 安全
重新认识架构—不只是软件设计
结合自身经历阐述架构师定位、架构活动如何保障企业、组织实现商业价值。
重新认识架构—不只是软件设计
|
11月前
|
安全 数据可视化 测试技术
【设计思维框架】框架 :为现代企业重新设想的设计思维(下)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
11月前
|
架构师 UED
【设计思维框架】框架 :为现代企业重新设想的设计思维(上)
【设计思维框架】框架 :为现代企业重新设想的设计思维
|
12月前
|
消息中间件 JavaScript 小程序
架构设计:为什么说复用是邪恶的?
架构设计:为什么说复用是邪恶的?
|
前端开发 开发者
架构整洁之道-01 设计与架构
设计:实现业务时的详细的设计,比如模块的依赖设计,业务逻辑设计,前端页面的设计。更偏向于细节内容的设计 - 架构:类似搭建房子一样,先有房子的形状、布局等,一个项目的架构那就是各个模块依赖关系,或者说结构。未来设计方向的一个框架。
129 0