代码的抽象三原则 - 阮一峰的网络日志
代码的抽象三原则
软件开发是（Abstraction）的一种体现。
所谓"抽象化"，就是指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。
开发软件的时候，一方面，我们总是希望使用别人已经写好的代码，另一方面，又希望自己写的代码尽可能重用，以求减少工作量。要做到这两个目标，这需要"抽象化"。
最近，我读到美国程序员的一篇文章，谈到"抽象化"应该遵循的三个原则，觉得很有启发。
一、DRY原则
是 Don't repeat yourself 的缩写，意思是"不要重复自己"。
软件工程名著首先提出了这个原则。它的涵义是，系统的每一个功能都应该有唯一的实现。也就是说，如果多次遇到同样的问题，就应该抽象出一个共同的解决方法，不要重复开发同样的功能。
这个原则有时也称为（Once and Only Once）。
二、YAGNI原则
是 You aren't gonna need it 的缩写，意思是"你不会需要它"。
这是提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，这样可以大大加快开发。
它背后的指导思想，就是尽可能快、尽可能简单地让软件运行起来（do the simplest thing that could possibly work）。
但是，这里出现了一个问题。仔细推敲的话，你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化"，要求找到通用的解决方法；后者追求"快和省"，意味着不要把精力放在抽象化上面，因为很可能"你不会需要它"。所以，就有了第三个原则。
三、Rule Of Three原则
称为"三次原则"，指的是当某个功能第三次出现时，才进行"抽象化"。
这是软件开发大家在《Refactoring》一书中提出的。
它的涵义是，第一次用到某个功能时，你写一个特定的解决方法；第二次又用到的时候，你拷贝上一次的代码；第三次出现的时候，你才着手"抽象化"，写出通用的解决方法。
这样做有几个理由：
（1）省事。如果一种功能只有一到两个地方会用到，就不需要在"抽象化"上面耗费时间了。
（2）容易发现模式。"抽象化"需要找到问题的模式，问题出现的场合越多，就越容易看出模式，从而可以更准确地"抽象化"。
比如，对于一个数列来说，两个元素不足以判断出规律：
　　1, 2, _, _, _, _,
第三个元素出现后，规律就变得较清晰了：
　　1, 2, 4, _, _, _,
（3）防止过度冗余。如果一种功能同时有多个实现，管理起来非常麻烦，修改的时候需要修改多处。在实际工作中，重复实现最多可以容忍出现一次，再多就无法接受了。
综上所述，"三次原则"是DRY原则和YAGNI原则的折衷，是代码冗余和开发成本的平衡点，值得我们在"抽象化"时遵循。
==========================================================
图灵公司打算重新出版的中文版，正在寻找译者。如果你对此有兴趣，请与朱巍编辑联系（Email：zhuw(）试译。关于此书的更多情况，可参考我翻译的续集。特别提醒：翻译是非常辛苦、但是报酬很低的工作，写信前请想清楚，你是真的想翻译这本书。
学习 Linux 时，经常可以看到两个词：User space（用户空间）和 Kernel space（内核空间）。
计算机硬件有两种储存数据的方式：大端字节序（big endian）和小端字节序（little endian）。
布尔代数是计算机的基础。没有它，就不会有计算机。
DNS 是互联网核心协议之一。不管是上网浏览，还是编程开发，都需要了解一点它的知识。http://www.aqee.net/kiss-my-yagni/我们都知道KISS (Keep It Simple, Stupid)和 YAGNI (You Ain&t Gonna Need It)软件开发原则，然而，过度复杂的软件仍然随处可见。
假设我们需要一个应用服务。没错，缺少管理系统是不行的。而且需要一个&&用来实现系统低耦合。哦，我们的业务逻辑看起来有很多的业务规则，那就用来管理吧。还需要一个，没错，&&没有它如何能让我们分布式的多个模块相互独立不依赖？数据库？当然是Oracle。但&&和&&也是需要的，因为关系型数据库有时不善于做某些事，我们需要更高的性能。我们还需要一些额外的应用层。还需要一些。还有模块化&&我们可不希望我们的应用是铁板一块，否则如何能复用我们的组件？你说对了，我们要使用，这个东西很适合我们。我忘了说Web Services吗？很重要。并且是少不了它的。
即使没有架构师来设计，这些技术也会很自然的出现在架构设计中。每一样都看起来合情合理，无可厚非。
不。YAGNI(你不需要它们)。你开发的业务系统极有可能只有几百人同时在线，有可能只有一些业务逻辑，其余的都是大量的不报表和统计。为了实现一个可用的、而且简单好维护的软件应用，你不需要上面提到的那些技术架构。
我是不是有些自相矛盾？因为之前我还坚持说，能够降低软件的复杂度，但现在却宣称应该远离那些技术和框架。其实并不冲突。
如果后来证明你真的需要一个消息队列模块&&那就增加，把同步调用代码替换成发送消息队列的代码。如果后来你的postgresql/mysql数据库不能很好的处理这样大的数据，那就换成Oracle。如果你的用户开始增加到百万级，那就考虑Cassandra。你只需要重写那些DAO类就行了。如果后来发现需要在系统里集成很多第三方的软件，那就研究一下ESB。如果你发现在很多项目间需要将一些代码拷来拷去，那就归纳提炼，做成可复用的组件。
但不是在这种需求出现之前就做这些事情。因为系统会因为它们而变得复杂度陡增，很难迭代，尤其是当团队里并不是每个人都熟悉这些技术的情况下。
这是在倡导在计划中走一步看一步吗？难到我们积累的经验不能让我们事先判断将会需要什么吗？是的，我们可以有预见，但那是在有足够的数据支持下。在项目的前期，我们几乎什么数据都没有。
有两种东西我们知道可能会是需要的。第一，实用工具。那些能简化我们的工作的工具。例如，ORM，它通常(但并不是总数)能简化我们的数据库访问。一个依赖反射注入框架，它能简化代码之间的交互。其次是子系统。某种形式上的消息队列服务系统，NoSQL数据库，ESB，这些都是子系统。它们并不属于我们的系统的原生部分，它们不是工具。它们会增加开发、配置、部署的复杂度。我们自己需要去评估使用它们给系统造成的影响，是否值得一用。
在&凡事自己动手&的错误做法和YAGNI开发原则之间其实有清楚的界限。这都是常识。这是我们的经验发挥作用的地方&&判断什么是最好的工作辅助工具，什么只是很酷的&也许会有帮助&的工具。
当有人对我说&让我们使用X来实现Y吧，&我会说：&不，我们要保持简单。我们现有的技术架构能处理它&。这样做的结果就是：更简单的软件。易于维护，易于让新手接手。而且不失功能性。
阅读(...) 评论()}