《人月神话》(P6)虚怀若谷和避免过度设计

简介: 结构师的交互准则和机制结构师的交互准则其实就是彻底、谨慎、和谐的与人交流。尽早的交流和持续沟通能够使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。

结构师的交互准则和机制

结构师的交互准则其实就是彻底、谨慎、和谐的与人交流。尽早的交流和持续沟通能够使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。

面对估算过高的难题,结构师有两个选择:削减设计或者采用成本更低的方法。然而后者并不是结构师能够控制的,这是在向开发人员提出要求。此时,结构师想要发挥自己的作用,必须:

  1. 牢记是开发人员承担着创造性功能的实现责任,结构师只能提出建议。
  2. 能够为自己所制定的某项说明提供一种建议的实现方法,并且准备接收任何其他可行的方法。
  3. 对开发人员的建议保持低调和平静。
  4. 准备放弃对自己提出的建议的坚持。
  5. 听取开发人员在体系结构上改进的建议。

自律——开发第二个系统所带来的后果

在开发第一个系统时,结构师倾向于精炼和简洁,他知道自己对正在进行的任务不够了解,所以会谨慎仔细的工作。当第一个项目结束之后,结构师会信心满满,准备设计第二个类似的系统。然而,这第二个系统通常人们所设计的最“危险”的系统,通常都会被过分的进行设计。

在这里例举了一个OS/360的例子,大概意思就是,结构人员有了第一次的经验之后,习惯性的为新系统增加了过多的修饰功能和想法,导致新系统粗糙、浪费、缺乏优雅。

结构师需要避免这样画蛇添足的事情发生,需要有意识的运用自我约束准则避免功能的过度装饰,要根据系统基本理念及目的来权衡功能取舍。结构师必须要有超过两个以上的系统开发经验,才能确保原则上的概念和目标在详细设计中得到完整体现。

以上是《人月神话》第五章——画蛇添足的主要内容

在上一章中,作者表名了结构师的工作是一种无需任何歉意的贵族专制,可是专制并不代表任性,反而需要他们认真谨慎,虚怀若谷。不仅要有自己的想法,还要善于听取他人建议,并最终做出决定。可见,能成为结构师的人并不一定是技术大牛,踏实、善于沟通、有责任心才是最重要的。

无论结构师多么优秀,他们也会犯过度设计的错误。从现在来看,单个软件的使用人群需要越来越大公司才能发展,结构师就需要不断的为许多不确定人群而设计软件。但是通常来说,设计通用的项目比设计专用的项目更加困难。这时就容易出现许多盲目的功能,过多的向产品添加过于边际的功能,所以我们能够看到很多APP都会推出一个“极速版”,这个极速版就是为了防止某些用户因为功能增加,而放弃使用产品的情况。

数百万的用户,能够提出上千个特色功能,这些需求对于结构师的诱惑是极大的,可是有经验的结构师往往就懂得权衡整体利益。
例如他们会明确的定义用户群,这是获得概念完整性的一种重要方法,经常需要分析用户是谁、用户需要什么、用户认为自己需要什么、用户想要什么。
还有另一个方法就是分析需求场景出现的频率,之所以频率需要通过结构师人为分析而来,而不是调查而来,一方面是因为调查成本太高,另一方面通过结构师对频率进行猜测可以让产品用户群的形象更加清晰。不过当那些非常重要的决策需要取决于某些猜测时,还是会花费精力来取得更准确的估计。
总之,为了避免过度设计,一定要清晰用户群体和需求频率,哪怕是错误的也比不清晰来的强。

目录
相关文章
|
7月前
|
缓存
代码优化与过度设计:寻找平衡的艺术
作为开发人员,我们常常会面临一个棘手的问题,即如何在代码优化和过度设计之间找到平衡点?因为我们都希望通过优化代码来提升程序性能,但实际情况是稍有不慎就可能陷入过度设计的泥潭,让代码变得难以理解和维护,反而适得其反。在实际开发中,我们应该如何在这两者之间找到平衡呢?那么本文就来简单分享一些经验和方法,从而帮助我们避免陷入这种困境泥潭中。
105 3
代码优化与过度设计:寻找平衡的艺术
|
1月前
|
机器学习/深度学习 人工智能 测试技术
探索软件测试中的“禅”:寻找内在的平和与外在的效率####
在软件测试的世界里,我们常常被缺陷的数量、测试用例的覆盖度以及上线时间的紧迫性所困扰。但如果我们能像禅宗修行者一样,将注意力转向内心的平静与专注,或许能在纷繁复杂的测试工作中找到一种全新的效率和质量提升之道。本文将带您走进软件测试的“禅意世界”,探讨如何在看似枯燥无味的测试过程中,通过调整心态、优化方法,实现个人成长与项目成功的双赢。 ####
|
2月前
|
机器学习/深度学习 人工智能 监控
提升软件质量的关键路径:高效测试策略与实践在软件开发的宇宙中,每一行代码都如同星辰般璀璨,而将这些星辰编织成星系的过程,则依赖于严谨而高效的测试策略。本文将引领读者探索软件测试的奥秘,揭示如何通过精心设计的测试方案,不仅提升软件的性能与稳定性,还能加速产品上市的步伐,最终实现质量与效率的双重飞跃。
在软件工程的浩瀚星海中,测试不仅是发现缺陷的放大镜,更是保障软件质量的坚固防线。本文旨在探讨一种高效且创新的软件测试策略框架,它融合了传统方法的精髓与现代技术的突破,旨在为软件开发团队提供一套系统化、可执行性强的测试指引。我们将从测试规划的起点出发,沿着测试设计、执行、反馈再到持续优化的轨迹,逐步展开论述。每一步都强调实用性与前瞻性相结合,确保测试活动能够紧跟软件开发的步伐,及时适应变化,有效应对各种挑战。
|
1天前
|
UED
别让细节拖累你的产品:学会权衡才是硬道理
在产品管理中,细节优化与整体推进之间的平衡至关重要。本文探讨了“抠细节”的利弊,并提出了确定优先级、设定阈值、数据驱动、强化团队协作、保持开放心态及学会妥协等平衡策略,帮助产品经理在细节与全局之间找到最佳平衡点,实现产品成功。
|
设计模式 机器学习/深度学习 算法
聊一聊过度设计!
新手程序员在做设计时,因为缺乏经验,很容易写出欠设计的代码,但有一些经验的程序员,尤其是在刚学习过设计模式之后,很容易写出过度设计的代码,而这种代码比新手程序员的代码更可怕,过度设计的代码不仅写出来时的成本很高,后续维护的成本也高。因为相对于毫无设计的代码,过度设计的代码有比较高的理解成本。说这么多,到底什么是过度设计?
266 0
|
测试技术 程序员
代码重构的力量:如何衡量重构成功
许多工程团队都在努力衡量他们重构工作的有效性。让我们看一下可以帮助您衡量重构成功的 5 个指标。 代码重构为开发人员提供了急需的精神休息,我认为许多开发人员都可以与此相关。整天编写代码要求很高,尤其是在您每天创建新功能的情况下。这是一项繁重的工作,开发人员通常需要一些空间来思考代码库的整体组织并回顾可以改进的地方
174 0
|
测试技术
【观点】开发人员的测试悖论
译文出自:伯乐在线
613 0
|
UED
为什么有些设计初衷很好,结果却很糟糕
本文讲的是为什么有些设计初衷很好,结果却很糟糕,刚刚,在她意识到自己已经买了机票之后,她又打开另一个标签页,预定这次旅行的酒店房间,又租了一辆车。随后返回到美国航空的标签页获取她的确认编号,同时记录在她的日历上。
1402 0