可复用性，可测试性，代码复杂度降低和可展示性编程重要性

Question

有很多编程和体系结构模式。模式允许代码更清洁，可重用，可维护，更可测试&终于（但不是至少）感受到跟随者是一个真正的酷开发者。

你如何评价这些考虑？当你决定应用模式时，最吸引你的是什么？

我不知道多少次代码的可重用性（特别是对于MVP，MVC模式）很重要？例如DAL库经常在项目之间共享（它是可重用的），但控制器/视图（通过接口抽象）多久会被重用？

Answer 1

如果我把事情简单化，代码复杂度降低很高，我可以更好地维护项目并更快地处理它以添加/更改功能。

可重用性是一种工具，它有其用途，但不适用于任何地方。我通常会重构那些在三个以上地方显示相同使用历史的组件的可重用性。否则，我冒着在一个或两个地方遇到专门行为的需要，最终将一个组件分解成几个具有相似结构的专业组件，但如果将它们放在一起很难理解。

可测试性并不是我个人投入的大量精力。然而，它在很多情况下都是从降低的代码复杂度中派生出来的：如果没有太多的依赖关系和复杂的代码路径，那么将会减少测试的危险或者使它们更难执行。

至于炫耀能力......好吧......客户对应用程序的表现感兴趣，而不是根据他的要求来表达他的想法，而不是关于我的代码的“酷炫”。 'nuff says

Answer 2

我想你错过了列表中最重要的一个 - 更易于维护。代码结构良好，结构一致（使用简单的可重用代码时）更容易维护。

至于reusablilty，那么是的，在许多场合，通常是这样的：创建一个网页来保存/更新某些记录。几个月后 - 我们需要将此作为第三方使用的服务公开 - 如果您的代码结构良好，应该既简单又低风险，因为您只需添加新的前端。

Answer 3

我希望大多数人使用模式来学习如何在特定环境下解决设计问题。您提到的所有非功能性需求可能非常重要，具体取决于项目利益相关者的需求。 对于MVC等，它并不意味着只能在项目之间重复使用，这通常是不可能的或者是一个好主意。您从MVC中获得的好处在您使用该架构的项目中应该很重要。您可以独立更改视图和模型中的细节，您可以针对不同模型重新使用控制器的视图，您应该能够更改持久性细节而不会影响控制器和视图。在单个项目的开发过程中，这一切都非常重要。

Answer 4

许多书中定义的“代码可重用性”或多或少都是一种神话。尝试着重于易于阅读 - 易于维护。不要着眼于“可重用性”，如果你开始首先考虑可测试性，然后重用某些东西，会更好。重要的是提供，测试，清理代码，重构，不重复自己，重要的是从开始构建可以在项目之间重用的组件。无论重复使用什么，都必须是一个自然的过程，更像是一个发现：你会看到一个重复，所以你建立了一些可以在特定情况下重用的东西。