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

代码复杂性的降低排名很高,如果我保持简单,我可以更好地维护项目,更快地添加/更改特性。

可重用性是一种工具,它有其用途,但并非在每个地方都有。为了可重用性,我通常重构那些在三个以上地方显示相同使用的清晰历史的组件。否则,我可能会在一两个地方遇到专门行为的需要,最后会将一个组件拆分成两个更专业的组件,这些组件共享类似的结构,但如果放在一起就很难理解。

可测试性并不是我个人投入大量精力的东西。然而,在许多情况下,它源自于降低的代码复杂性:如果没有太多的依赖性和复杂的代码路径,那么破坏测试或使测试更难执行的危险就更少了。

至于炫耀能力…好。。。客户感兴趣的是应用程序在他想要的方面表现如何,而不是我的代码有多“酷”。努夫说

我认为你错过了清单中最重要的一个——更容易维护。结构良好且一致的代码(正如您使用易于重用的代码得到的那样)更容易维护。

至于可重用性,在很多情况下是的,通常是这样的:创建一个网页来保存/更新一些记录。几个月后——我们需要将其公开为第三方使用的服务——如果您的代码结构良好,那么这应该是容易的、低风险的,因为您只是添加了一个新的前端。

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

许多书中定义的“代码可重用性”或多或少是一个神话。试着把注意力更多地放在容易阅读-易于维护上。不要从“可重用性”开始,如果您先考虑可测试性,然后再重用一些东西,会更好。重要的是交付、测试、拥有干净的代码、重构、不要重复自己的工作,以及从一开始就构建可以在项目之间重用的组件。无论要重用什么,都必须是一个自然的过程,更像是一个发现:您看到了一个重复,所以您构建了一些可以在特定情况下重用的东西。