编写健壮的代码与过度设计

你们怎么知道您正在编写最强大的代码而又不会过度设计？

我发现自己对我的代码可以采用的每条可能路径都考虑得太多了，有时感觉就像是在浪费时间。我想这取决于您正在编写的程序类型，但是我不想花太多时间考虑永远不会发生的情况。

你们怎么知道您正在编写最强大的代码而又不会过度设计？

您认为健壮的代码是什么？代码已经过时了，而且功能强大到可以处理任何情况？错误的，没有人能预测未来！再犯一次，因为这将是一个复杂的，难以维护的混乱。

我遵循各种原则：首先是YAGNI（尚未）和KISS，所以我不会编写不必要的代码。这也有效地防止了过度设计。当需要扩展时，我可以重构应用程序。现代的重构工具使您可以轻松地创建接口，并在以后需要时交换实现。

然后，我尝试使我编写的代码尽可能健壮，其中包括消除程序可能采取的尽可能多的路径（以及声明状态）以及一些Spartan编程。一个很大的帮助是“原子”功能/方法，它们不依赖外部状态，或者至少在失败时不会使程序处于不一致状态。如果做得好，最终也不会出现意粉代码，这也是可维护性的一大福音。同样，在面向对象的设计中，SOLID原理是鲁棒代码的重要指南。

我真的发现，通常您可以通过深思如何将其设计为尽可能最直的路径来降低复杂性，例如程序路径或状态的组合爆炸。通过选择子例程的最佳顺序并为此目的进行设计，尝试将可能的组合保持在最低限度。

健壮的代码通常总是简单干净的代码，但是简单性是一个不容易实现的特征。但是，您应该为此而努力。总是尽可能地编写最简单的代码，并且在别无选择时只会增加复杂性。

简单性很强，复杂性很脆弱。

复杂性杀死。

我努力保持平衡，专注于

• 处理现有用例中的所有可能的执行路径（这是“稳健性”部分），
• 启用功能/需求我很确定在可预​​见的将来会实现这些功能，并且
• 我从经验中知道，代码库的长期可维护性（即保持代码干净和可测试）将需要这些知识。

这是一个模糊的边界区域-有时我设法做一些不必要的工作，有时我做不到的事后来证明是必要的。如果错过的机会不大，我很好。无论如何，我都努力从错误中学习。

健壮和过度工程之间的区别是优雅地处理所有可能的用例之间的差异，即使是应该避免的奇异和附带的用例也是如此。当我优雅地讲时，用户输入一个奇怪的异常案例或遇到一种情况，即需要一个未定义的不受支持或未指定的功能，并且该代码可以正常退出而不崩溃或通知用户不支持的功能。

另一方面，过度设计可能落入完全实现不需要或不需要的功能的领域（客户确实需要但从未要求过某些功能！），或者可以通过得出过于复杂的设计或过于复杂的方式来定义它代码来处理一个相对简单的问题。

1）获取要求。

2）编写最少的代码以满足要求。如果有歧义，请进行有根据的猜测。如果超级模棱两可，请返回1。

3）发送到测试。

4）如果测试人员表示良好，则记录批准。如果出现问题，请返回1。

专注于通过测试，而不是预测测试。如果您没有测试人员...请获取测试人员！它们不仅对验证代码的正确性至关重要，而且对于整个开发过程也至关重要。

首先，请尽可能保持数据标准化（非冗余）。如果对数据进行了完全规范化，则对数据的任何一次更新都不会使其不一致。

您无法始终保持数据规范化，换句话说，您可能无法消除冗余，在这种情况下，冗余状态可能会不一致。然后要做的是容忍这种不一致，并使用某种程序对其进行定期修复并对其进行修补，以对其进行定期修复。

强烈倾向于通过通知来紧密管理冗余。这些不仅很难确定它们是正确的，但可能会导致巨大的效率低下。（写通知的部分诱惑是因为在OOP中实际上鼓励这样做。）

通常，任何依赖于事件，消息等的时间顺序的事物都将很容易受到攻击，并且需要大量的防御性编码。事件和消息是具有冗余性的数据的特征，因为它们将更改从一个部分传递到另一部分，以防止不一致。

就像我说的那样，如果您必须有冗余（并且机会一定很不错），那么最好是能够a）容忍，并b）对其进行修复。如果您试图仅通过消息，通知，触发器等来防止不一致，则很难使其健壮。

• 编写以供重用。
• 编写测试。琐碎的，非琐碎的，有些荒诞的，复杂的，看看它在这种情况下如何处理。测试也将帮助您确定界面的形式。
• 编写程序以使其失败（例如，断言）。我的代码具有大量的重用性，并且我测试了大量的情况-比实际实现（基于行数）的错误检查/处理更多。
• 重用。
• 立即修复出问题的地方。
• 从经验中学习和建立。

错误会随之而来，但是（很幸运）它们会被本地化，并且（在大多数情况下）它们会在测试的很早就出现。重用的另一个好处是，客户端/调用者可以使用实现带来的错误来保存大多数错误检查/支架。

然后，您的测试应定义程序的功能及其强大程度-不断添加测试，直到您对成功率和投入感到满意为止；根据需要进行改进，扩展和强化。

我通过编写定义良好但不一定是最佳行为的代码来实现这种区分，这种代码的执行可能性极小。例如，当我非常确定（证明但未经测试）矩阵将是正定的时，我在程序中插入一个断言或异常以测试状态，但不为其编写自己的代码路径。因此，行为已定义，但次优。

鲁棒性：在无效输入或压力环境条件下，系统继续运行的程度。（代码完成2，p464）

这里的重要问题是询问坚固性对您有多重要。如果您是Facebook，那么当有人在输入中输入特殊字符时，让您的网站继续运行，以及同时登录1亿用户时服务器保持正常运行，这一点非常重要。如果您正在编写脚本来执行只有您才能执行的常见操作，则不必在意。之间有很多关卡。判断所需的鲁棒性是开发人员应学习的重要技能之一。

YAGNI的原理适用于添加程序可能需要的功能。但是该原理不适用于鲁棒性。程序员往往高估了将需要给定的将来扩展的可能性（尤其是如果它很酷），但是他们却低估了出错的可能性。同样，如果发现之后需要省略的功能，则程序员可以稍后编写它。如果发现毕竟需要进行省略的错误检查，则可能造成损坏。

因此，实际上最好还是在检查异常错误情况时进行检查。但是有一个平衡点。在这种平衡中需要考虑的一些事项：

• 该错误多久发生一次？
• 发生此错误的代价是什么？
• 这是内部使用还是外部使用？

别忘了人们可以并且会尝试以意想不到的方式使用您的程序。最好是在发生某些可预见的事情时发生。

作为最后一道防线，请使用断言或关闭。如果发生无法解决的事情，请关闭程序。这通常比允许程序继续执行不可预测的事情要好。