编写可扩展代码和可删除代码

Question

我知道这可能只是语义问题，但阅读题为“编写易于删除、不容易扩展的代码”的文章使我认为，它或多或少地遵循了创建易于维护的代码的思路。现在，无论是通过使软件易于扩展或可删除来使其易于更新或修改，在编写代码之前必须遵循良好的设计思想的原则。

我想问的问题是，我们是否应该考虑一种更适合于当今软件设计和体系结构的风格的代码，即敏捷和以用户为中心(因此与业务需求相比进化得更快)，既包括可重用性，也包括可擦除性？

或者它已经存在了？有人能指出一些标准或准则吗？

Answer 1

我认为分层被低估了。我希望有更多的文本讨论，作为一个设计点。分层意味着在另一个抽象之上放置一个抽象(而不允许底层抽象通过泄漏)。

一个很好的、非常有效的分层例子是当你改变语言的时候。例如，您可以在SQL数据库的基础上编写一些SQL，这样就可以获得数百万行代码的好处，而无需与它们集成(例如，您不必知道实现SQL所用的编程语言是什么)！

DSL是另一个很好的例子。有时，在声明性DSL中创建新的源代码是将一个层与另一个层( DSL实现层)隔离的最佳方法。

我们的编程语言背负着很多包袱，例如，执行新操作通常有特定于语言的要求，而这不是应用程序的要求(例如，new String("foo")应该是应用程序中任何其他对象的独立对象，甚至是其他new String("foo")'s )。

通过适当的分层，我们可以将基本的和偶然的需求/依赖/特性相互分离。

Answer 2

我们是否应该考虑一种更适合于敏捷和以用户为中心的现代软件设计和体系结构(因此与业务需求相比进化得更快)的代码风格，既包括可重用性元素，也包括可擦除性元素？

可擦除代码与可扩展代码的根本问题是理解。开发人员(S)越好地了解正在解决的问题以及如何最好地解决问题，解决方案就越好。

理解与其说是一种编码风格，甚至不是一种设计风格--本文中讨论的所有元素和技术(例如分层、隔离、组合、通用接口)都是常见的技术。这是一个思考的过程。

链接文章中描述的过程描述了作者日益增长的理解。作者开始复制粘贴代码(步骤1)，然后后退一步，并将其合并到库中(步骤2)。接下来，作者跨项目共享公共代码(步骤3)，然后实现过多的共享是维护的负担，并创建独立的抽象层(步骤4)，然后用越来越大的部分重复(步骤5、6和7)。

虽然开发人员熟悉这些步骤，但细节并没有那么重要。他们包括在上下文和“讲一个故事”。重要的是：

1. 一些前期的思考和设计是至关重要的，但是一旦你开始编写代码，就不要停止思考。除非你熟悉这个问题，否则你的设计会随着你学到更多的东西而改变。
2. 因此，不要害怕重构(删除代码只是重构的一个子类别)。
3. 因此，创建可以轻松重构的代码。如果您不能更改代码(例如，您不理解它，或者它太脆弱(例如缺乏自动化测试)，那么您将陷入糟糕的设计之中。

在此过程中，作者提出了一些好的方面，例如寻找错误并提出错误，而不是创建繁琐的解决方案。