软件设计，两句话概括
在软件设计方程的背景下，现在可以将软件设计的主要原则简化为两句话：
降低维护成本比降低实现成本更重要。维护成本与系统的复杂度成正比。
差不多就是这样。如果你对软件设计的了解仅限于这两条原则和软件的目的，你就可以推导出软件开发的所有其他通用原则。
- Max
评论
Mark Castillo 说：2010年5月13日下午1:01
呵呵……我还在寻找实现和维护零成本的原则。也许这里可以有一个基本原则……“零成本是无法实现的”。
回复
Wanderson Santos 说：2010年5月18日上午5:39
我完全同意，但我们能否将其与敏捷原则（如XP中的“简单设计”）对齐？
Max Kanat-Alexander 说：2010年5月20日下午3:12
嗯，我并不真正认同任何现有的特定软件方法论。所以，如果有人想说“哦，这听起来有点像XP的某个原则，可以这样与之配合”，并且这对某人有所帮助，那很好。但如果目的仅仅是因为XP存在而有人认为一切都应该符合XP，那么我认为这并不太好。通常，那些希望将所有东西都塞进他们特定软件方法论的人，个人会有所获益——例如，他们是该方法的顾问，或者他们写了一本关于它的书，想卖更多书。并不是说卖书或当顾问有什么错。但仅仅因为个人利益而推广一套想法是有问题的。
- Max
回复
Ape 说：2010年6月12日上午2:43
我想看看你如何推导出其他原则的一些例子。观察这个思维过程和涉及的推理模式会很有趣。
Max Kanat-Alexander 说：2010年6月12日下午12:36
嗯。好吧，这里有几个简单的例子：
我们知道复杂度会导致更多的维护努力。什么导致复杂度？嗯，我们可以证明导致复杂度的一件事是系统组件的紧耦合。因此，通过寻找减少复杂度的方法，我们可以推导出松耦合的原则。
我们想减少维护努力。所以，我们会花一些时间观察什么占用了我们的维护时间。修复错误肯定占用了相当一部分时间。那么，如果能在错误存在之前就捕获它们，从而消除错误维护，不是很好吗？通过一些实验，我们可能会推导出自动化测试的想法。
如果你将较低级别的原则追溯到这些更高级别的简单性，它会变得更简单。
它适用于几乎所有的软件开发原则，除了HCI原则，我认为那是一个单独的领域。
- Max
回复
Todd A » 两句话的软件设计 说：2010年7月15日上午10:41
[…] 这就是我在网页设计中一直争论的，尽管我从未像Code Simplicity那样雄辩地表达过：1. 降低维护成本比降低实现成本更重要。 […]
回复
Harald Wellmann 说：2010年10月27日上午7:36
假设系统中的维护问题数量与其大小成正比，你还需要考虑在较大系统中隔离和修复问题所需的额外时间。
这就是为什么我认为维护努力与系统大小之间的关系不是线性的：
在复杂度分析方面，你的第二句话相当于 m = O(c)
我甚至声称 m = O(c log c) 或 m = O(c^2)
Max Kanat-Alexander 说：2010年11月4日晚上11:42
是的，我确实仔细考虑了你的评论，我认为你是对的。一个更数学准确的陈述可能是：维护努力是系统复杂度的函数。
但我担心有些人可能不知道“是……的函数”是什么意思。
回复
Mike W. 说：2017年9月21日晚上9:41
“维护成本与系统的复杂度成正比。”
我认为这是一个很好的句子；它只是使用了“proportional”的英语含义，而不是数学定义。
为了不打扰数学家，你可以这样说：
“随着系统复杂度的增加，维护成本增加。”
或者如果你不在乎非数学家是否理解你：
“维护成本是系统复杂度的严格递增函数。”
（如果你对最后一句话想得太多，你会意识到没有办法数学地测量系统的复杂度，但你_可以_简单地检查两个系统并确定它们的相对复杂度。）
Max Kanat-Alexander 说：2017年9月24日晚上11:15
基本上。
回复
Enrique Dewulf 说：2012年3月10日下午3:10
我认为热情甚至高于专业技能。没有时间用于枯燥的单调。当然有时间工作。也有时间恋爱。那就没有其他时间了！
回复
两句话的软件设计 说：2015年1月23日上午9:50
[…] 这就是我在网页设计中一直争论的，尽管我从未像Code Simplicity那样雄辩地表达过： […]
回复
最新思考
Max Kanat-Alexander 6月27日
我目前认为，AI代理能够成功生成的输出数量和质量取决于：
- 模型的质量。
- 代理的质量。
- 输入的质量（如提示或其他上下文）。
- 代理可以独立运行的确定性、客观验证的质量。
我目前认为，除非你是模型开发者，否则最重要的部分是“确定性、客观验证”。
简单来说，如果你告诉AI做某事，它需要某种方式能够自行验证它做对了。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。
这意味着你的测试和验证工具越好，你从模型得到的输出就越好。这不只是测试数量的问题。它们必须是好的测试，具有智能断言和良好的错误消息。
这也意味着代理的成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单个部分。
作为说明，输入的质量也很重要，并且在我们的控制之下。如果我们编写更好的文档和更清晰的代码，代理会做得更好。令人惊讶的是，几乎所有帮助人类编写代码的东西也帮助代理。
阅读更多 2310 分享
Max Kanat-Alexander 6月4日
技术债务有价值的想法大多是一个神话。当你做出一个糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那根本不是真的。它几乎立即开始。做正确事的成本通常是几个小时，也许一天，而你几乎总是立即收回那个时间。也就是说，做对通常花费的时间与做错花费的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！” 结果几乎总是它根本没有节省你的时间！它使处理变更更加混乱。它使代码审查时间更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从未节省你的实际时间。
偶尔，你的路径上会有一些“巨石”，你根本无法移动。没有人应该花三个月设计一个新工具，只是为了你能一次性地交付一个一天的功能。但那是技术债务决策中极小极小的一部分。
这变得更疯狂，因为如果你_随着进行_做对一切（你总是重构系统，使其看起来像是被设计成现在所做的 exactly），那么一切在整个过程中都保持相对容易。但如果你偷工减料，一切都会变得复合性地更加困难，以至于你_生成_了没有人能移动的“巨石”。复杂度不是某种线性的东西，你可以后来投入线性时间修复。你绝对可以让自己陷入一个如此糟糕的境地，以至于你公司中_没有人_有时间或专业知识来修复它。
这一切感觉如此无辜：“让我们偷工减料吧，它会帮助我们满足这个截止日期”（一个通常是虚构的截止日期，你可以推迟几周而没有任何后果）。“很难弄清楚如何做对，我们能推迟吗？”然后砰，很快你发现自己陷入了一个沼泽，一切都很难，“我们不知道为什么！”
我最后留给你一件事：当我直接编码的每一天，我对此完全 uncompromising。我基本上无法看坏代码——我必须重构它，否则我无法工作。不知何故，在我整个职业生涯的那部分，我从未错过一个截止日期。
阅读更多 12940 分享
Max Kanat-Alexander 5月30日
我估计，我每看到或被告知一万条坏建议，才收到一条好建议。互联网充满坏建议，因为文明充满坏建议。文明充满坏建议，因为全球的教育大多不教人们思考、学习或确定什么是真实的。相反，它教人们 memorizing 和 repeating 事实，其中大多数是不重要、不真实或无用的。
所以总的来说，我们不应该惊讶互联网（尤其是社交媒体）充满不重要、不真实或无用的信息。并非全部如此——我在网上学到了大量非常有用的东西。有大量有价值的内容。我会说，人们对事物的_意见_，无论是在报纸、博客文章、论坛还是其他什么，很少具有那种价值。
那么，要点是什么？嗯，最好有某种方式在开始依赖或向他人重复之前确定某事是否重要或有用的。最简单的工具是说：“它有效吗？” 这条数据是否可靠地帮助你完成某事？它100%有效，还是更少？
对于许多帖子，你会发现：这条数据根本无助于你做任何事。
阅读更多 249 分享
Max Kanat-Alexander 5月29日
你对系统所做的任何更改在推出时都会收到_某人_的负面反馈。这发生不是因为每次更改都有问题，而是因为用户习惯了系统的工作方式，他们不喜欢_它改变了_。他们可能会批评新的用户界面，或者有一些情感论点关于为什么新东西“糟糕”，但通常他们真的只是对任何更改发生感到不安。这不是什么不寻常的事；它是几乎所有人类中存在的一个因素。人们往往有一定的 appetite 对于他们愿意在一段时间内经历多少更改，如果你超出那个，他们会感到不安。
重要的是要认识到人们的反馈是简单的这种“更改厌恶” vs 关于有价值事物的真实反馈。有几种方法可以判断：
- 更改厌恶通常持续3到10天。如果你在推出更改后的头3到10天内收到用户的反馈，并且同一反馈不是由大量用户提供的，值得考虑用户的反应是否只是更改厌恶。
- 更改厌恶反馈通常是情感的。它可能是侮辱性的。它可能表达为 just an opinion（“新菜单的颜色丑陋”）vs a fact（“我测量了，新工具比旧工具慢10倍。”）。
你在管理更改时试图避免的是创建_如此_多的更改厌恶以至于引起反抗。反抗基本上看起来像_如此_多的人愤怒以至于他们去找你的管理层并停止你的工作。当有疑问时，向更少的人推出更小的更改，以较慢的扩展速度。随着时间的推移，你将学习你可以推出多少更改，多快。永远，永远不要做“大爆炸”发布，让你所有用户一次经历 massive change。
现在，所有这些 said，永远不要将_所有_反馈归因于“更改厌恶”。通常人们确实有合法的反馈。如果许多人提供你相同的事实反馈，并且你查看它，他们的反馈有道理，你认为修复它会改进产品，那很可能_不是_更改厌恶。另外，说“这只是更改厌恶”并不意味着你应该完全忽略反馈。你至少应该承认它，让人们知道他们被听到了。它_确实_意味着你不应该与那个人争论或试图与他们推理，因为他们正在有情感反应，你试图用“逻辑”说服他们 out of it 不会帮助任何人。如果你认为是更改厌恶，你承认他们，而他们只是继续与你斗争，有时你应该只是忽略他们并继续做你的工作。如果他们3天后带着更合理的论点回来，那么你知道那不只是更改厌恶，而且他们可能那时更有帮助。
阅读更多 274 分享
加载更多
© 2025 版权所有。由 The Fox 提供技术支持。