我们如何找出问题所在 » 代码简洁性
在我上一篇文章之后，有些人问：“好吧，但你怎么知道哪里有问题？”
其实有些问题非常明显。你按下一个按钮，程序需要10分钟才能响应。这显然很糟糕。你每周收到100条关于某个特定页面UI的投诉——好吧，那也是个问题。
通常有一两个非常明显的大问题，这些应该首先处理，即使它们需要大量工作。例如，在Bugzilla 3.0之前，每次加载页面时，Bugzilla都必须编译每个库和整个要运行的脚本。在较慢的机器上，这给每个页面加载增加了几秒钟，在较快的机器上至少也要1秒。所以性能是Bugzilla一个明显的大问题。
但更重要的是，Bugzilla的代码也很糟糕。每个人都在阅读它——因为人们经常在公司中定制Bugzilla——但它是一团难以阅读、混乱的代码。
幸运的是，这两个问题有相同的解决方案。性能问题通过允许人们在Web服务器启动时预编译所有脚本来解决，而不是每次有人加载页面时都编译。为了实现这种预编译，我们必须进行大量的重构。因此，我们实际上通过处理代码问题来解决性能问题。
然而，完成所有这些花了四个主要版本（Bugzilla 2.18、2.20、2.22，最后是3.0）！在这个过程中，我们也为每个版本修复了许多小问题，所以每个版本确实比前一个版本更好。但处理主要问题是一项巨大的努力——这不是我们一夜之间就能编码完成的事情。
我认为有时候软件项目中的大问题没有得到处理，因为它们确实需要那么多工作来修复。但这并不意味着你可以忽略它们。这只是意味着你必须为一个长期项目做计划，并找出如何在此期间持续发布版本。
在所有这些问题都解决之后，我们可以将注意力转向其他地方，哇！结果发现其他地方仍然有一堆问题！突然之间，出现了一批新的“完全明显”需要修复的问题——这些问题一直存在，但被前一批“完全明显”的问题所掩盖。
现在，我们可以永远这样继续下去——修复一组“完全明显”的问题，然后转向下一组“完全明显”的问题。但我们遇到了一个问题——当你突然发现有五十个“完全明显”需要修复的问题，而你无法在一个版本中完成所有问题时，会发生什么？好吧，那时你突然需要一些方法来优先处理你要修复的问题。
对于Bugzilla项目，我们做了两件事来帮助我们确定优先级：Bugzilla调查和Bugzilla可用性研究。
在调查中，最重要的部分是允许人们以自由文本的形式回答向他们个人提出的问题。也就是说，我亲自向Bugzilla管理员发送问题，通常根据他们的具体情况定制消息。没有多项选择题，只有促使他们告诉我们什么困扰他们以及他们希望看到什么的问题。他们实际上很高兴收到我的电子邮件——很多人感谢我进行调查。
一旦他们全部回应，我阅读了所有内容，并编制了一份报告的主要问题列表——总体而言，这是一个令人惊讶的小列表！我们现在非常重视这些问题，我认为这总体上让人们对Bugzilla更满意。
在可用性研究中，令人惊讶的是最有帮助的部分是研究人员（他们是可用性专家）只是坐在Bugzilla前面，指出违反可用性原则的地方。也就是说，比他们实际进行的研究更有价值的是他们作为专家的观察，使用可用性工程的标准原则。我认为，他们是新鲜的眼睛——从未在Bugzilla上工作过的人，因此不会只是认为“好吧，就是这样”——也很重要。
所以我们收集了所有这些数据，它确实帮助我们确定了优先级。然而，重要的是我们在那个时候进行了调查和研究，而不是更早。在我们修复前几个主要问题之前，可用性和调查结果对我们来说将是压倒性的——它们会指出一百万个我们已经知道的问题，或者很多我们当时没有时间处理的问题，我们将不得不稍后重新进行调查和研究，使这一切成为浪费的时间。所以我们必须等到我们问自己“好吧，现在什么最重要？”的时候，那时收集数据变得非常重要和极其有用。
所以总的来说，我会说，当你试图让事情变得更好时，首先处理你知道的前几个明显的大问题，并处理它们，无论需要什么。然后事情会稍微平静下来，你会有一大堆需要修复的东西。那时你去从用户那里收集数据，并努力修复他们告诉你的真正问题。
-Max
分享 点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X
4条评论 发表回复
Ben 说： 2009年8月22日上午7:21 除了明显的大问题之外，程序中经常发生的另一个问题（我特别想到Windows）是它们经常移除越来越多用户曾经能够使用的技术功能。Windows过去允许你通过启动功能和系统工具进行各种个性化设置，以优化程序的运行方式。新版本已经移除了用户可操作的大部分内容，这真的很糟糕。不知道他们为什么这样做。
回复
Max Kanat-Alexander 说： 2009年9月16日上午3:05 确实如此。我认为他们试图解决的问题是Windows太复杂了。但他们在错误的层面上攻击它——复杂性是根本的，他们添加了所有这些功能来让你处理复杂性（那些技术功能），现在移除技术功能但不处理复杂性对任何人都没有帮助！ -Max
回复
Ape 说： 2010年6月12日上午3:08 “为什么软件糟糕” 一个真正讨论“糟糕意味着什么”的演讲
回复
Max Kanat-Alexander 说： 2010年6月12日下午12:56 那很有趣。 -Max
回复
发表回复取消回复
联系 关于 书籍：理解软件 书籍：代码简洁性
输入您的邮箱… 订阅
Max Kanat-Alexander 6月27日 我目前认为，AI代理能够成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。
简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做了正确的事。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。
这意味着你的测试和验证工具越好，你从模型得到的输出就越好。不仅仅是测试的数量。它们必须是好的测试，具有智能断言和良好的错误消息。
这也意味着代理的成功涉及如何将任务分解成可以分别通过自动化测试、linter等客观验证的单个部分。
需要注意的是，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。
阅读更多2010分享
Max Kanat-Alexander 6月4日 技术债务有价值的想法大多是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但这根本不对。它几乎立即开始。做正确的事的成本通常是几个小时，也许一天，你几乎总是立即收回那个时间。也就是说，做对通常花费的时间与做错花费的时间相同。“等等，什么？怎么可能？我们偷工减料是为了节省时间！”结果几乎总是它根本不会节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间来调试。它几乎从不节省你的实际时间。
偶尔，你的路径上会有一些如此巨大的“岩石”，你根本无法移动它。没有人应该花三个月设计一个新工具，只是为了你能一次发布一个一天的功能。但那是技术债务决策中极小的一部分。
这变得更加疯狂，因为如果你在过程中做对了一切（你总是重构系统，使其看起来像是被设计成现在所做的），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切都会变得越来越困难，直到你生成没有人能移动的“岩石”。复杂性不是某种线性的事情，你可以后来投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的境地，以至于你公司中没有人有时间或专业知识来修复它。
这一切感觉如此无辜：“让我们偷工减料吧，它将帮助我们满足这个截止日期”（一个通常是虚构的截止日期，你可以推迟几周而没有后果）。“很难弄清楚如何做对，我们可以推迟吗？”然后砰，很快你发现自己陷入了一个沼泽，一切都很难，“我们不知道为什么！”
我最后留给你一件事：当我直接编码的每一天，我对此完全 uncompromising。我基本上无法看糟糕的代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分中，我从未错过一个截止日期。
阅读更多9342分享
Max Kanat-Alexander 5月30日 我估计，我看到的或被告知的每一万条坏建议中，有一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、研究或确定什么是真的。相反，它教人们记忆和重复事实，其中大多数是不重要、不真实或无用的。
所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们对事物的意见，无论是在报纸、博客文章、论坛还是其他什么地方，很少具有那种价值。
那么要点是什么？嗯，最好有一些方法在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说：“它有效吗？”这条数据是否可靠地帮助你完成某事？它100%有效，还是更少？
对于许多帖子，你会发现：这些数据根本不能帮助你做任何事。
阅读更多219分享
Max Kanat-Alexander 5月29日 你对系统所做的任何更改在推出时都会收到某些人的负面反馈。这不是因为每个更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢它改变了。他们可能会批评新的用户界面，或者有一些关于新东西为什么“糟糕”的情绪化论点，但通常他们真的只是对任何更改发生感到不安。这不是什么不寻常的事；它存在于几乎所有人类中的一个因素。人们往往对在一段时间内愿意经历多少变化有一定的胃口，如果你超过了那个，他们就会不安。
重要的是要识别什么时候人们的反馈仅仅是这种“变化厌恶” vs 关于有价值事物的真实反馈。有几种方法可以判断：
- 变化厌恶通常持续3到10天。如果你在推出更改后的前3到10天内从用户那里得到反馈，并且同一反馈没有被大量用户提供，值得考虑用户的反应是否只是变化厌恶。
- 变化厌恶反馈通常是情绪化的。它可能是侮辱性的。它可能表达为只是一种意见（“新菜单的颜色很丑”） vs 一个事实（“我测量了，新工具比旧工具慢10倍。”）。
在管理变化时，你要避免的是创造如此多的变化厌恶，以至于引起反抗。反抗基本上看起来像如此多的人生气，以至于他们去找你的管理层，他们停止你的工作。当有疑问时，向更少的人推出更小的变化，以较慢的扩展速度。随着时间的推移，你将学会可以推出多少变化，多快。永远不要做“大爆炸”发布，让所有用户同时经历 massive change。
现在，所有这些 said，永远不要将所有反馈归因于“变化厌恶”。通常人们确实有合法的反馈。如果许多人提供你相同的事实反馈，你看了，他们的反馈有道理，你认为修复它会改进产品，那很可能不是变化厌恶。另外，说“这只是变化厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。这确实意味着你不应该与那个人争论或试图与他们推理，因为他们正在情绪化反应，你试图用“逻辑”说服他们不会帮助任何人。如果你认为是变化厌恶，你承认他们，他们只是继续与你斗争，有时你应该只是忽略他们，继续做你的工作。如果他们3天后带着更合理的论点回来，那么你知道不仅仅是变化厌恶，而且他们可能那时更有帮助。
阅读更多234分享
加载更多
© 2025 版权所有。由 The Fox 提供支持。 管理同意联系 关于 书籍：理解软件 书籍：代码简洁性 转到顶部