可重用性，可测试性，代码复杂性降低和显示能力编程的重要性

Question

有很多编程和架构模式。模式允许使代码更清晰，可重用，可维护，更可测试和更好。最后（但并非至少）认为追随者是一个真正酷的开发者。

您如何对这些考虑因素进行排名？当您决定应用模式时，最吸引您的是什么？

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

Answer 1

我认为你错过了列表中最重要的一个 - 更易于维护。可以更容易地维护良好且一致的结构化代码（因为您可以轻松地重用代码）。

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

Answer 2

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

Answer 3

许多书中定义的“代码可重用性”或多或少都是一个神话。尝试更多地关注易于阅读 - 易于维护。不要以“可重用性”为开头，如果您开始首先考虑可测试性然后重用某些东西，那就更好了。重要的是交付，测试，拥有干净的代码，重构，不重复自己，并且从可以在项目之间重用的开始组件构建不太重要。无论要重用什么都必须是一个自然的过程，更像是一个发现：你会看到一个重复，所以你可以构建一些可以在特定情况下重用的东西。

Answer 4

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

可重用性是一种工具，它有一个用途，但不是在每个地方。我通常会重构那些在三个以上的地方显示相同用途的组件的可重用性。否则，我冒着在一两个地方遇到专门行为的风险，并最终将一个组件拆分成几个更具特色的组件，这些组件具有相似的结构，但如果保持在一起则难以理解。

可测试性不是我个人投入的精力。然而，它在很多情况下来自于代码复杂度的降低：如果没有很多依赖关系和错综复杂的代码路径，那么打破测试的危险就会减少或者使他们更难执行。

至于炫耀能力......好吧......客户对应用程序的表现感兴趣，而不是就我的代码“酷”程度而言。 '努夫说。