可重用代码不是通用代码

Image Credits: Pixabay.com

可重用的代码作为解决所有软件问题的一站式解决方案，是一个危险的神话。 让我解释一下原因。

假设您正在编写软件库。 您脑中冒出一个好主意，可以创建可广泛使用的通用解决方案。 您可以疯狂地编写涵盖所有功能并适应所有场景的API。 每种可能的新方案，都将其添加到您的API中。 您的代码不成比例地增长。 但是从真正意义上讲它是通用的，每个人都开始使用它。 你很高兴。

然后有一天，新的API出现了。 它比已有的API更精简，涵盖了更多方案。 它也更快，更容易使用。 您的API被淘汰。 每个人都迅速移到下一个闪亮的事物。 但是历史再次重演。 该API还因满足不同用例的附加代码而变得肿，最终被其他东西取代，依此类推……

怎么了

所有问题的根本原因在于编写通用解决方案。 当任何可重用的代码尽可能只关注通用案例时，它就会变得肿，难以使用，并最终成为一件痛苦的事情。

通用是可重用软件的基本要求。 但是，使软件过于通用会导致其可用性受损。 因此，简而言之，编写好的可重用代码与编写通用代码无关。 不仅如此。

编写实用且可重用的代码应侧重于紧急使用，而不是长期使用。 假设您遇到了可以在应用程序中重用的代码。 您可以采用它，对其进行一些改进，然后在您的应用程序中使用它。 这样，您仅在需要时才支付实际需要的价格。

稍后，您发现改进的代码可以在其他应用程序中进一步使用。 您将再次使用经过改进的代码，对其进行增强，然后再次使用。 因此，通过提高可重用性，您不仅可以充分利用代码的优势，而且还可以确保不使用，不需要的代码不属于您的解决方案。

这里的关键不是试图预测未来。 可重用性的范围应该只在您对事物的直接可见性之内，并且当新的机会发挥作用时，您可以增强代码。 这样，您不仅可以节省时间和精力，而且还可以最终创建出更精简，更有意义的代码以及可重复使用的最新代码。

这里有一些使代码实际上可重用的方法。

代码重用应着重于避免重复。

Lemony Snicket说得对。

"不要重复自己。 它不仅是重复的，而且是多余的，而且人们以前也听说过。"

记住，我们谈论过紧急重用。 代码可用性的目标应该仅此而已。 因此，编写所需的代码并继续这样做，直到开始重复解决相同的问题为止。 然后将该解决方案重构到一个公共位置并进行引用。 这样，您就不会创建浪费的通用代码。 您正在创建避免重复的代码。

也就是说，DRY(不要重复自己)原则重申了同一件事，该原则指出不应重复代码逻辑，因为重复的代码会导致技术负担。 不必要的重复代码会阻塞系统，从而导致质量下降。 此外，它还会创建一个代码怪兽，这成为可维护性的噩梦。

请记住，DRY更像是一种哲学，团队成员必须放下个人的编码自我，并为项目的更大利益而努力。 如果有人已经做过某事，请使用它。 不要重新发明轮子。

让类/方法/函数做一件事

路易斯·沙利文曾经很漂亮地说过。

"形式遵循功能。"

这意味着每个类/函数只有一件事给我们更改它的一个理由。 这通常意味着创建其他方法使用的方法，但这有助于使方法/类变得简单且耦合程度降低。

每个系统都是由特定领域的语言构建的，该语言是程序员设计的，以恰当地描述它。 函数是该语言的动词，类是名词。 在任何编程语言中，它们通常都是组织的第一线，编写好代码是编写好代码的本质。

编写可重用的类/函数只有两个黄金法则。

• 它们应该很小
• 他们应该只做一件事，并且应该做好

因此，这意味着您的函数不应足够大以容纳嵌套结构。 因此，函数的缩进级别不应大于一或两个。 这种技术使阅读，理解和消化变得更加容易。 除此之外，我们还需要确保函数中的语句处于相同的抽象级别。

混合的抽象级别总是非常令人困惑，并在适当的时候导致无法管理的代码。 熟练的程序员将可重用代码视为要讲的故事，而不是要编写的代码。

他们使用所选编程语言的功能来构建更丰富，更具表现力和更简洁的代码块，从而可以充当理想的讲故事的人。

避免过多使用继承

有时，作为开发人员，我们试图考虑到项目的未来，"为防万一需要"编码一些额外的功能，或者"最终将需要"。

只是不要这样做。 您不需要它，在大多数情况下……"您根本不需要它"(YAGNI)

同样的原则也适用于继承。 除非很明显您将有多个实现，否则不要引入继承层。

也就是说，继承是扩展类功能的好方法。 但是开发人员倾向于通过在类中将继承级别设置为多达六个或更多来对继承进行错误管理，这是荒谬的。

正如"四人帮"在其书本设计模式中恰当地描述了过度继承的危险。

"因为继承将子类公开给其父级实现的详细信息，所以人们常说'继承破坏封装'。"

继承导致高度耦合，因为超类将其内部公开给子类，而子类的功能又完全依赖于超类。 这使得僵硬并且在需要时难以更改超类的功能。 这就是为什么继承不是实现代码重用的好方法。

更好的方法是根据对象的组成而不是继承来考虑。 这使用户可以更轻松地获取所需的功能，并根据自己的约束创建自己的对象。 您甚至可以考虑创建任何类都可以以自己的方式实现的过程接口。 与涉及多个继承级别的类相比，接口通常更易于理解和实现。

通常，仅当一个类是另一类的扩展并且继承类的大多数代码使用超类的代码时，才应使用继承。 从可重用性的角度来看，任何超出此范围的措施都是自杀的。

最后的想法

通常，编写可重用的代码与开发通用的，巨型的代码块无关。 编写可重用代码的关键是编写具有高内聚力和松散耦合的，集中的，可组合的组件。

最后，不要将代码可重用性作为目标。 根本不值得。 使避免代码重复成为目标。 以避免编写浪费的代码为目标。 使编写干净，易于理解，易于维护的代码成为目标。 一旦开始以正确的心态进行思考，可重用性就会自动出现。

请记住，编写可重用的代码首先要解决问题，然后才能解决问题。 其余的都应该落在那儿，您可以选择哪种方法更适合进入下一个层次。

正如拉尔夫·约翰逊(Ralph Johnson)正确说的。

在软件可以重用之前，首先必须要使用它。

关于作者：

Ravi Rajan是位于印度孟买的全球IT计划经理。 他还是一位狂热的博客作者，Hai句诗作家，考古爱好者和历史狂人。 在LinkedIn，Medium和Twitter上与Ravi联系。

(本文翻译自Ravi Shankar Rajan的文章《How to Make Your Code Reusable》，参考：https://levelup.gitconnected.com/how-to-make-your-code-reusable-891ea5db415c)