软件设计中的“拒绝”艺术:如何通过说“不”提升代码质量

本文探讨了在软件开发过程中,设计师如何通过明智地说“不”来避免糟糕功能的实现,从而提升系统的可维护性和用户体验。文章强调了识别不良想法的重要性,并提供了实用的设计原则和团队沟通技巧。

拒绝的力量 » 代码简洁性

管理同意

为了提供最佳体验,我们使用像cookies这样的技术来存储和/或访问设备信息。同意这些技术将允许我们处理数据,例如在本网站上的浏览行为或唯一ID。不同意或撤回同意可能会对某些特性和功能产生不利影响。

功能性

始终活跃 技术存储或访问对于使订阅者或用户明确请求的特定服务的合法目的是绝对必要的,或者仅用于通过电子通信网络进行通信传输的唯一目的。

偏好

技术存储或访问对于存储订阅者或用户未请求的偏好的合法目的是必要的。

统计

技术存储或访问仅用于统计目的。技术存储或访问仅用于匿名统计目的。没有传票、互联网服务提供商的自愿合规或来自第三方的额外记录,仅为此目的存储或检索的信息通常不能用于识别您。

营销

技术存储或访问是创建用户配置文件以发送广告,或在网站或跨多个网站上跟踪用户以用于类似营销目的所必需的。

管理选项 管理服务 管理{vendor_count}供应商 阅读更多关于这些目的 接受 拒绝 查看偏好 保存偏好 查看偏好 Cookie政策 {title} 印记

代码简洁性

拒绝的力量

2011年1月20日 by Max Kanat-Alexander

您有多少次使用过充满极其复杂功能、奇怪决策和不可用界面的软件?您是否曾因为计算机就是不按正确方式工作,或者您无法弄清楚如何使其正常运行而想要物理或口头虐待它?您有多少次想过,“任何程序员怎么会认为这是一个明智的想法?”

好吧,如果您曾经经历过任何这些事情,您的下一个想法可能是“****这台计算机”或“****那个让它这样行为的愚蠢程序员”。毕竟,系统的疯狂行为难道不是程序员和硬件设计师的错吗?嗯,是的,在某种程度上他们是。但在深入参与软件设计多年后,我现在对实施不良的功能有了另一种反应。我不是对实施系统的程序员生气,而是问自己,“是谁授权了这个功能的软件设计师?”谁在有能力阻止它时默默站着,让这个功能发生?

诚然,有时根本没有软件设计师,在这种情况下,您几乎可以保证会有一个破碎的系统。但当有软件设计师时,他们最终对系统的构建方式负责。现在,这项工作的大部分涉及在功能进入系统之前设计其结构。但软件设计师工作的另一部分是防止不良想法被实施。事实上,如果我在软件行业多年学到任何教训,那就是:软件设计师词汇中最重要的词是“不”。

问题是,如果您给一群人完全自由去实施任何随机进入他们脑海的想法,那么几乎每次他们都会实施不良想法。这不是对开发人员的批评,更像是生活中的一个事实。我对个别开发人员的智力和能力有极大的信心。我钦佩开发人员在软件开发中的奋斗和成就。这只是一个不幸的存在事实,即没有某种中央指导,群体中的人倾向于演化出复杂系统,这些系统无法尽可能好地帮助他们的用户。

然而,个别设计师通常能够为用户和开发人员都创造出一致和愉快的体验。但如果那个个别设计师在另一个开发人员开始以错误方式做某事时从不站出来说“不”,那么系统将自行崩溃,变成一堆混乱的不良想法。因此,拥有一个有权说“不”的软件设计师非常重要,然后该设计师在适当时实际使用这种权力也非常重要。

仅仅对任何真正值得“不”的想法说“不”,您就能改善产品的程度真是令人惊讶。

识别不良想法

在应用这一原则之前,有一件事您必须知道:如何识别不良想法。幸运的是,有许多软件设计原则可以帮助您了解什么是不良想法,并在真正需要时引导您说“不”。例如:

  • 如果功能的实施违反了软件设计法则(例如,它太复杂,无法维护,不易更改等),那么该实施是一个不良想法。
  • 如果功能对用户没有帮助,这是一个不良想法。
  • 如果提议明显愚蠢,这是一个不良想法。
  • 如果某些更改没有解决一个已证明的问题,这是一个不良想法。
  • 如果您不确定这是一个好主意,这是一个不良想法。

此外,随着时间的推移,人们倾向于学习什么是好主意,什么不是,特别是如果您使用上述作为指导方针并理解软件设计法则。

没有更好的想法

现在,有时设计师可以识别一个不良想法,但他们仍然实施它,因为他们现在想不出更好的想法。这是一个错误。如果您只能想出一个问题的解决方案,但它明显愚蠢,那么您仍然需要对其说“不”。

起初,这似乎违反直觉——问题不需要解决吗?我们不应该以任何可能的方式解决这个问题吗?

好吧,问题是:如果您实施一个“不良想法”,您的“解决方案”将迅速变成比原始问题更糟糕的灾难。当您实施一些可怕的东西时,它“有效”,但用户抱怨,其他程序员都叹气,系统崩溃,您的软件受欢迎度开始下降。最终,“解决方案”变成如此大的问题,以至于需要其他不良“解决方案”来“修复”它。这些“修复”然后本身变成巨大的问题。继续沿着这条路走下去,最终您会得到一个臃肿、混乱且难以维护的系统,就像今天许多现有的软件系统一样。

如果您经常发现自己处于感觉被迫接受不良想法的情况,很可能您实际上接近这一事件链的末端——也就是说,您实际上是在系统过去一系列预先存在的不良想法上构建。在这种情况下,解决方案不是继续“修补”不良想法,而是找到系统最基本、潜在的不良想法,并随着时间的推移重新设计它们,使其变得良好。

理想情况下,当您拒绝一个不良想法时,您应该提供一个替代的好想法——这样您就是在建设性地推动项目前进,而不是被视为开发道路上的障碍。但即使您现在想不出更好的想法,对不良想法说“不”仍然很重要。好想法最终会到来。也许需要一些研究,或者也许有一天当您站在淋浴间时突然想到。我不知道想法会从哪里来或它是什么。但不要太担心。只需相信总有某种好方法来解决每个问题,并继续寻找它,直到找到它。不要放弃并接受不良想法。

澄清:接受和礼貌

所以说“不”很重要,但需要一些澄清我真正意思的地方。我不是说每个建议都是错误的。事实上,开发人员通常是非常聪明的人,有时他们真的做到了。许多开发人员提出完美的建议并进行出色的实施。即使最差的解决方案也可以有好的部分,尽管整体上并不出色。所以很多时候,您实际说的不是“不”,而是更像,“哇,这个想法的一部分真的很好,但其余部分不是那么好。我们应该取这个想法的最佳部分,并通过更多的工作将它们构建成一些很棒的东西。”不过,您必须对想法中不好的部分说“不”。仅仅因为想法的一部分是好的并不意味着整个想法是好的。取想法中聪明的部分,完善它,并围绕它构建好想法,直到您设计的解决方案真正伟大。

此外,与团队其他成员良好沟通仍然至关重要——拥有说“不”的责任并不意味着您有权粗鲁或不体贴。如果您持续说“不”而没有任何善意,您将分裂您的团队,引起不满,并最终在与您惹恼的人争论中浪费数小时的时间。因此,当您不得不说“不”时,最好找到一种礼貌的方式来表达——一种表达对输入感激的方式,提出如何改进的积极建议,并轻松地让人失望。我理解不得不放慢速度解释事情是多么令人沮丧——更令人沮丧的是向第一次不理解的人一遍又一遍地重复解释——但如果这是拥有一个有效的开发团队同时仍然对不良功能说“不”所必需的,那么这就是您必须做的。

-Max

分享 点击在Facebook上分享(在新窗口中打开) Facebook 点击在LinkedIn上分享(在新窗口中打开) LinkedIn 点击在Hacker News上分享(在新窗口中打开) Hacker News 点击在Reddit上分享(在新窗口中打开) Reddit 点击在Threads上分享(在新窗口中打开) Threads 点击在X上分享(在新窗口中打开) X

5条评论 留下回复

KurtB 说:2011年2月25日上午8:39 +1 这与我的高中指导顾问办公室墙上的一张海报相辅相成,上面写着:“机智是在不树敌的情况下表达观点的艺术。”学习如何引导思路是一种社交技能,我相信编码人员可以从中受益。根据我的经验,从防御立场说“不”或试图通过胁迫得到我想要的很少奏效。 是的。我在顾问办公室花了太多时间——或者也许不够。 -kb 回复

Max Kanat-Alexander 说:2011年2月25日晚上9:39 嘿Kurt。是的,完全同意你的观点!机智地说“不”的能力是一种如果更广泛地培养会真正受益的能力。 -Max 回复

Vladimir Dzhuvinov 说:2011年3月26日上午5:20 软件业务,尽管其“逻辑”主题,通常由未解决的情绪、固执和意识形态支配。我知道这一点,因为我偶尔在自己的行为中注意到这些事情。学会在必须时说“不”不是一件容易的事,特别是在有压力且这种压力来自高层(来自老板)、客户或投资者时。或者来自我的女朋友。我还观察到,有时我选择不说“不”(或说“不”,但显得不机智)不是因为我不想,而是因为在那一刻我心理上懒惰,不想构建一个好的论据。 回复

Mike W. 说:2017年7月21日下午6:22 今天刚用了这个,并给了这个帖子的链接。“如果您不确定这是一个好主意,这是一个不良想法。”金玉良言。感谢在这个实例中为我说“不”增加了确定性! 回复

Max Kanat-Alexander 说:2017年7月26日晚上9:35 太好了,很高兴我能帮忙! -Max 回复

留下回复 取消回复

联系 关于 书:理解软件 书:代码简洁性

输入您的电子邮件… 订阅

Max Kanat-Alexander 6天前 非常兴奋地宣布,我将在2025年开发者生产力工程峰会上发表主题演讲之一。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作,自2004年以来几乎全职从事开发者体验。有一些基本的、普遍的真理关于如何使开发者体验变得伟大,我将尽力在有限的时间内涵盖尽可能多的内容。希望在那里见到您。:) 阅读更多 1177 分享

Max Kanat-Alexander 6月27日 我目前认为,AI代理可以成功生成的输出数量和质量取决于:

  1. 模型的质量。
  2. 代理的质量。
  3. 输入的质量(如提示或其他上下文)。
  4. 代理可以独立运行的确定性、客观验证的质量。 我目前认为,除非您是模型开发人员,否则最重要的部分是“确定性、客观验证”。 简单来说,如果您告诉AI做某事,它需要某种方式能够自行验证它做对了。在软件中,这通常意味着运行测试、linter等,如果系统做错了就会失败。 这意味着您的测试和验证工具越好,您从模型获得的输出就越好。这不仅仅是测试数量的问题。它们必须是好的测试,具有智能断言和良好的错误消息。 这也意味着代理成功涉及思考如何将任务分解成可以分别通过自动化测试、linter等客观验证的单个部分。 作为说明,输入的质量也很重要,并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码,代理会做得更好。令人惊讶的是,几乎所有帮助人类编写代码的东西也帮助代理。 阅读更多 2510 分享

Max Kanat-Alexander 6月4日 技术债务有价值的想法大多是一个神话。当您做出糟糕的软件工程决策时,它会在几小时、几天或几周内减慢您的速度。那是上限。许多人认为需要数月或数年才能看到在软件设计上偷工减料的影响,但这根本不是真的。它几乎立即开始。做正确事的成本通常是几小时,也许一天,而且您几乎总是立即收回那段时间。也就是说,做对通常花费与做错相同的时间。“等等,什么?那怎么可能?我们偷工减料是为了节省时间!”结果几乎总是它根本不会节省您的时间!它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败,需要更长时间调试。它几乎从不节省您实际时间。 偶尔,您的路径中有一些“岩石”如此巨大,以至于您根本无法移动它。没有人应该花三个月设计一个新工具,只是为了您能一次交付一个一天的功能。但那是技术债务决策中极小的一部分。 这变得更加疯狂,因为如果您在进行中做对一切(您总是重构系统,使其看起来像是设计来做 exactly 现在做的事情),那么一切在整个过程中都保持相对容易。但如果您偷工减料,一切都会变得复合性地更加困难,以至于您生成没有人能移动的“岩石”。复杂性不是某种线性的东西,您可以后来投入线性时间修复。您绝对可以使自己陷入如此糟糕的境地,以至于您公司中没有人有时间或专业知识来修复它。 这一切感觉如此无辜:“让我们只是偷工减料,它将帮助我们满足这个截止日期,”(一个截止日期通常是虚构的,无论如何,您可以推迟几周而没有后果)。“很难弄清楚如何做对这件事,我们可以推迟它吗?”然后砰,很快您发现自己陷入了一个沼泽,一切都很难,“我们不知道为什么!” 我留给您最后一件事:当我直接编码我生活的每一天时,我对此完全 uncompromising。我基本上无法看坏代码——我必须重构它,否则我无法工作。不知何故,在我整个职业生涯的那部分中,我从未错过一个截止日期。 阅读更多 12942 分享

Max Kanat-Alexander 5月30日 我估计,我看到的或被告知的每一万条坏建议中,我收到了一条好建议。互联网充满坏建议,因为文明充满坏建议。文明充满坏建议,因为全球的教育大多不教人们思考、研究或确定什么是真实的。相反,它教人们记忆和重复事实,其中大多数是不重要、不真实或无用的。 所以总的来说,我们不应该对互联网(尤其是社交媒体)充满不重要、不真实或无用的信息感到惊讶。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说,人们对事物的意见,无论是在报纸、博客文章、论坛还是其他什么,很少具有那种价值,尽管。 那么要点是什么?嗯,最好有一些方法在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说:“它有效吗?”这条数据是否可靠地帮助您完成某事?它100%的时间有效,还是更少? 对于许多帖子,您会发现:这些数据根本无助于您做任何事情。 阅读更多 249 分享

加载更多

© 2025 版权所有。由The Fox提供支持。

管理同意 联系 关于 书:理解软件 书:代码简洁性

转到顶部

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计