有很多编程和架构模式。模式允许使代码更清晰、可重用、可维护、更可测试并最终（但并非至少）让追随者成为真正酷的开发人员。
您如何对这些考虑因素进行排名？当您决定应用模式时，最吸引您的是什么？
我想知道代码可重用性（尤其是对于 MVP、MVC 模式）有多少次重要？例如，DAL 库通常在项目之间共享（它是可重用的），但控制器/视图（通过接口抽象）被重用的频率如何？
【问题讨论】：
标签： language-agnostic design-patterns
我认为您错过了列表中最重要的一项 - 更易于维护。结构良好且一致的代码（就像您使用易于重用的代码一样）更容易维护。
至于重用，那么是的，在很多情况下，通常是这样的：创建一个网页来保存/更新一些记录。几个月后 - 我们需要将其作为服务公开以供第三方使用 - 如果您的代码结构良好，这应该很容易且风险低，因为您只是添加了一个新的前端。
【讨论】：
我希望大多数人使用模式来学习如何在特定上下文中解决设计问题。您提到的所有这些非功能性要求可能非常重要，具体取决于项目的利益相关者需求。 至于 MVC 等，它不仅仅意味着在项目之间重用，这通常是不可能的或一个好主意。您从 MVC 获得的好处在您使用该架构的项目中应该很重要。您可以独立更改视图和模型中的细节，您可以为不同的模型重用带有控制器的视图，您应该能够在不影响控制器和视图的情况下更改持久性细节。所有这些在单个项目的开发过程中都非常重要。
【讨论】：
许多书中定义的“代码可重用性”或多或少是一个神话。尝试更多地关注易于阅读 - 易于维护。不要从“可重用性”开始，如果您首先考虑可测试性然后重用某些东西会更好。交付、测试、拥有干净的代码、重构、不重复自己很重要，而从一开始就构建可以在项目之间重用的组件则不太重要。任何要重用的东西都必须是一个自然的过程，更像是一个发现：你看到了重复，所以你构建了一些可以在特定情况下重用的东西。
【讨论】：
代码复杂性降低排名很高，如果我保持简单，我可以更好地维护项目并更快地处理它以添加/更改功能。
可重用性是一种工具，它有它的用途，但不是在所有地方都可以使用。我通常会重构那些在三个以上的地方显示出相同使用历史的组件以实现可重用性。否则，我可能会在一两个地方遇到特殊行为的需求，最终将一个组件拆分为几个更专业的组件，这些组件具有相似的结构，但如果放在一起就很难理解。
可测试性并不是我个人投入大量精力的事情。然而，它在许多情况下源于代码复杂性的降低：如果没有很多依赖项和复杂的代码路径，那么破坏测试或让它们更难执行。
至于炫耀能力......好吧......客户感兴趣的是应用程序在他想要的方面的表现，而不是我的代码有多“酷”。 'nuff说
【讨论】：