首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >软件设计中"说不"的力量:拒绝糟糕功能的技术决策艺术

软件设计中"说不"的力量:拒绝糟糕功能的技术决策艺术

原创
作者头像
qife122
发布2025-09-03 21:55:58
发布2025-09-03 21:55:58
1400
举报

说不的力量 » 代码简洁性

代码简洁性

说不的力量

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

今天刚刚用了这个,并给了这篇文章的链接。"如果你不确定这是一个好主意,那就是坏想法。" 金玉良言。🙂

感谢在这个例子中为我

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 说不的力量 » 代码简洁性
    • 代码简洁性
      • 说不的力量
    • 识别坏想法
    • 没有更好的想法
    • 澄清:接受和礼貌
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档