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

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

概念完整性

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

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

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

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

获得概念完整性

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

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

贵族专制统治和民主政治

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

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

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

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

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

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

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

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

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

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

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

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

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

目录
相关文章
|
7月前
|
Java 持续交付 数据库
避免服务分层污水池反模式
【6月更文挑战第30天】本文介绍污水池反模式,分层架构在敏捷性、部署性和性能方面得分较低,但具有高测试性和易开发性。关键在于合理分层以降低耦合和提高解耦效果。
292 1
避免服务分层污水池反模式
|
5月前
|
设计模式 架构师 数据建模
架构师必备底层逻辑:设计与建模的技术深度探索
【8月更文挑战第13天】在软件开发的浩瀚星海中,架构师如同星辰指引,他们不仅规划着系统的蓝图,更在底层逻辑上精雕细琢,确保系统的稳健与高效。其中,“设计与建模”作为架构师的核心能力之一,是连接业务需求与技术实现的桥梁。本文将深入探讨架构师在设计与建模过程中的关键思维与实践方法,为工作学习中的技术同仁提供一份宝贵的干货分享。
70 3
|
5月前
|
存储 Java 数据库连接
成为工程师 - 系统分层的设计原则
成为工程师 - 系统分层的设计原则
|
8月前
|
存储 设计模式 编译器
软件体系结构 - 复杂指令集架构 (CISC)
【4月更文挑战第18天】软件体系结构 - 复杂指令集架构 (CISC)
269 6
|
8月前
|
前端开发 Oracle 安全
软件架构设计 C/S与B/S架构的区别
C/S是Client/Server的缩写。服务器通常采用高性能的PC、工作站或小型机,并采用大型数据库系统,如Oracle或SQLServer。
87 0
|
8月前
|
存储 缓存 数据处理
软件体系结构 - 哈佛架构
软件体系结构 - 哈佛架构
143 0
|
8月前
|
设计模式 算法
23种设计模式分类
23种设计模式分类
132 0
|
设计模式 网络协议 Java
《移动互联网技术》 第十章 系统与通信: 掌握Android系统的分层架构设计思想和基于组件的设计模式
《移动互联网技术》 第十章 系统与通信: 掌握Android系统的分层架构设计思想和基于组件的设计模式
135 0
|
存储 算法 程序员
25【软件基础】面向对象分析与设计思想总结
`面向对象的本质`:通过对象之间的协作完成功能。
709 0
架构:第九章:架构设计(为什么要这么设计,解决了什么问题)
架构:第九章:架构设计(为什么要这么设计,解决了什么问题)
280 0

热门文章

最新文章