在大型代码库中处理一次性/特殊情况的建议？

Question

任何人都有关于在大型复杂Web应用程序中处理一次性或特殊情况业务规则的最佳方法的建议吗？

大多数情况下，请求来自向客户承诺的销售人员。举一个简单的例子，假设某人正在销售Stack Overflow。然后，与销售代表交谈的客户说：“我会购买一个订阅，但只有当您将网站上的背景颜色更改为黑色并且向我发送电子邮件时，我希望您在电子邮件发送给我时发送到一个地址在9-5之间，并在当天的任何其他时间使用这个其他地址“。 销售代表说是的，没问题，先生。最后你会看到充斥着一堆

的代码

if (customerID == 123) { 
    //do something for this customer
} 

Answer 1

如果您 有义务执行这些一次性特殊情况：

将它们抽象出来（这样你就可以轻松地将这些特殊情况配置/存储在一个合理的位置，而不是分散地硬编码到你的源中）。

当下一个（相同的）到达时，你将有一个结构。

Answer 2

绝对开始介绍用户个人资料并将其附加到您的客户详细信息中。硬编码条件逻辑将引入重复代码，可维护性并且还使您的系统非常脆弱。无论何时需要添加/进行更改，都必须为Web应用程序引入停机时间。如果它们都是数据驱动的，那会不会更好？

Answer 3

我不时会收到这样的请求。我尽我所能地尽可能地向后推，或者将这些案例抽象出来，而不是让它们成为代码库本身的一部分。也许你可以做类似的事情。

无论如何，你可能知道这一点，但是：

  

第一名。如果你发现自己简单地实现了一个功能   因为已向一位客户承诺， RED危险灯应该   在脑子里走吧。如果你正在为一个客户做事，   你有一个松散的大炮销售人员，或者你正在滑倒   危险地沿着斜坡走向咨询软件。而且什么都没有   咨询软件错误;滑下来是一个非常舒适的斜坡，   但它不如收缩包裹软件那么有利可图。

来自"Set your priorities"

的

Joel Spolsky