软件开发是"抽象化"原则（Abstraction）的一种体现。
所谓"抽象化"，就是指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。
开发软件的时候，一方面，我们总是希望使用别人已经写好的代码，另一方面，又希望自己写的代码尽可能重用，以求减少工作量。要做到这两个目标，这需要"抽象化"。
最近，我读到美国程序员Derick Bailey的一篇文章，谈到"抽象化"应该遵循的三个原则，觉得很有启发。
一、DRY原则
DRY是 Don't repeat yourself 的缩写，意思是"不要重复自己"。
软件工程名著《The Pragmatic Programmer》首先提出了这个原则。它的涵义是，系统的每一个功能都应该有唯一的实现。也就是说，如果多次遇到同样的问题，就应该抽象出一个共同的解决方法，不要重复开发同样的功能。
这个原则有时也称为"一次且仅一次"原则（Once and Only Once）。
二、YAGNI原则
YAGNI是 You aren't gonna need it 的缩写，意思是"你不会需要它"。
这是"极限编程"提倡的原则，指的是你自以为有用的功能，实际上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，这样可以大大加快开发。
它背后的指导思想，就是尽可能快、尽可能简单地让软件运行起来（do the simplest thing that could possibly work）。
但是，这里出现了一个问题。仔细推敲的话，你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化"，要求找到通用的解决方法；后者追求"快和省"，意味着不要把精力放在抽象化上面，因为很可能"你不会需要它"。所以，就有了第三个原则。
三、Rule Of Three原则
Rule of three 称为"三次原则"，指的是当某个功能第三次出现时，才进行"抽象化"。
这是软件开发大家Martin Fowler在《Refactoring》一书中提出的。
它的涵义是，第一次用到某个功能时，你写一个特定的解决方法；第二次又用到的时候，你拷贝上一次的代码；第三次出现的时候，你才着手"抽象化"，写出通用的解决方法。
这样做有几个理由：
（1）省事。如果一种功能只有一到两个地方会用到，就不需要在"抽象化"上面耗费时间了。
（2）容易发现模式。"抽象化"需要找到问题的模式，问题出现的场合越多，就越容易看出模式，从而可以更准确地"抽象化"。
比如，对于一个数列来说，两个元素不足以判断出规律：
1, 2, _, _, _, _,
第三个元素出现后，规律就变得较清晰了：
1, 2, 4, _, _, _,
（3）防止过度冗余。如果一种功能同时有多个实现，管理起来非常麻烦，修改的时候需要修改多处。在实际工作中，重复实现最多可以容忍出现一次，再多就无法接受了。
综上所述，"三次原则"是DRY原则和YAGNI原则的折衷，是代码冗余和开发成本的平衡点，值得我们在"抽象化"时遵循。
==========================================================
附：
[广告]
图灵公司打算重新出版《Joel on Software》的中文版，正在寻找译者。如果你对此有兴趣，请与朱巍编辑联系（Email：zhuw(at)turingbook.com）试译。关于此书的更多情况，可参考我翻译的续集《More Joel on Software》。特别提醒：翻译是非常辛苦、但是报酬很低的工作，写信前请想清楚，你是真的想翻译这本书。
（完）
kenneth 说：
翻译一下书，也挺不错的饿，但是太忙了
2013年1月31日 14:27 | # | 引用
白色北京城 说：
我觉得阮一峰很有意思，没写过一行代码，整天研究代码的东西，自以为很懂
这就是所谓纸上谈兵吧
2013年1月31日 14:46 | # | 引用
老猫 说：
经常是自己不断造轮子的同时，公司其他同事也在不断造轮子。
2013年1月31日 14:52 | # | 引用
一酷 说：
2013年1月31日 14:54 | # | 引用
十二能 说：
阮一峰 肯定是写过代码的，不然不会有这么多个想法。
2013年1月31日 15:05 | # | 引用
白色北京城 说：
赵括也有很多粉丝，要不当不上将军。书多的再多有什么用，给你个项目，能用上才是本事。
整天研究这个研究那个，一到项目上，就开始画虫了，我不觉得一个根本不写代码的人发出的文章会具备很强的指导意义，不误导人就不错了。我也一直看阮一峰的文章，技术文缺乏严谨的态度，看多了会误导很多人，非技术文倒是能拓宽一下知识面，还是不错的。
2013年1月31日 15:06 | # | 引用
mindful 说：
书多的再多，不算很严谨吧
2013年1月31日 15:09 | # | 引用
laoguo 说：
我写代码的原则：
１）尽可能不写代码。写得越少，bug就越少。
２）尽可能不修改既成的代码。修改得越多，新bug出现的可能性就越大。
３）试图在１）和２）之间谋求平衡，以求最省事。
2013年1月31日 15:11 | # | 引用
laoguo 说：
原因是大家比较喜欢看这里的评论。这里的评论没有分页，看起来方便。而且都是搞技术的，都喜欢写些与众不同的评论。这样使得信息量变大，就有了看得价值了。
小阮同志的文章大多时候只是一块有底色画布。
2013年1月31日 15:13 | # | 引用
NathanWu 说：
同意以上的观点
2013年1月31日 15:17 | # | 引用
NathanWu 说：
2013年1月31日 15:20 | # | 引用
kergee 说：
至少能学到一点吧，至少比不写的强吧
2013年1月31日 15:34 | # | 引用
francis 说：
2013年1月31日 16:34 | # | 引用
回复 说：
起码这个主题就是他自己搭的...
2013年1月31日 16:45 | # | 引用
kaicui 说：
如果觉得文章不好，大可以不必来看啊。如果连文章的好坏都分不清楚还在这里大言不惭，不觉得很无聊吗
2013年1月31日 17:27 | # | 引用
beikel 说：
作为开发过多个软件的人来说（贝壳系统救护：） ），我从阮兄这得到比较多的有用的东西，阮兄读了很多著作，归纳了很多知识点，方便了很多人，有没有用，作为做过多个项目的人来说，自然会明白清楚分辨出有用的东西
2013年1月31日 17:47 | # | 引用
beikel 说：
至于这篇文章说的内容，我是深有体会，归纳相同的东西，确实减少很多不必要的重复工作和加快各种类同产品的开发，减少工作量，而且测试也更快
2013年1月31日 17:49 | # | 引用
马猴 说：
你确定一峰没有写过代码？！
2013年1月31日 18:49 | # | 引用
我要匿名 说：
2013年1月31日 19:55 | # | 引用
我的名字叫麒 说：
苦苦连C都学不会的飘过~~
2013年1月31日 20:01 | # | 引用
oodasong 说：
这就是再一再二不可再三吧
2013年1月31日 20:35 | # | 引用
Joe 说：
让我想到抽象化两个常用的：面向对象和面向接口。
2013年2月 1日 08:47 | # | 引用
达伟 说：
弱弱的问一句是不是如果我要写篇连锁反应的文章，非要我先学会造原子弹？
阮一峰的文章是为大家创造一个“集思广益”的场所，其实大部分文章看来不是一个具体范畴，但是在IT（IT之外也一样）里有点想法的人，会发现阮哥是一个有很强大发散思想的人，很多文章都在贯穿一个主题：条条大路通罗马。很多门类科学其实都是共同的。读阮一峰的文章我不在乎从中学到什么具体技术，而是学习领会一个“思考分析的方法”，这个是让我很受用的。
2013年2月 1日 09:08 | # | 引用
guoqiao 说：
我觉得大家不要理会那个人了吧，跑题了。你越辩论，他越亢奋。
2013年2月 1日 09:22 | # | 引用
litefy 说：
自己的猜想 就当作事实了. 阮一峰是写过代码的.
2013年2月 1日 10:06 | # | 引用
雍寇德 说：
2013年2月 1日 13:24 | # | 引用
phplaber 说：
阮老师是写过代码的，链接楼上的朋友已贴出。我想说，即便没写过代码，就不能研究代码了？代码终归代表的是一种思维逻辑，以电脑能理解的标记呈现罢了。如果某种思维逻辑在人脑能通过，剩下的就是与计算机“对话”的问题了。
2013年2月 1日 13:47 | # | 引用
plums 说：
看了博主的很多文章，很受用，谢谢
2013年2月 1日 16:34 | # | 引用
白色北京城 说：
可以研究，但是研究的目的是用，而不是放在那里，理论终归是理论，只有结合实践才有意义。我之所以上来说是因为平常看阮一峰研究了各种技术，各种模式，各种高端理论，如果他一个也没用到项目中，这样的研究又有什么意义。
跟自幼熟读兵法，却没带兵打过仗一个道理。
2013年2月 1日 20:57 | # | 引用
沙渺 说：
实际做的项目可都是很错综复杂的，涉及很多对别人来看毫无用处的细节。
把项目的过程像流水账一样，所有细节啰嗦半天，结果最后总结的还是这些核心的理论，又何苦如此？
您弄错了一件事情：怎么读文章，怎么用知识，这明明是读者的责任。赵括打不明白仗，只怪自己缺少经验好大喜功，读了书不知道怎么用。怎么也不能怪兵书的思想写的不好。（兵书就必须保证读了就能赢？那写兵书的人得多冤啊。）
读文章懒于思考、不肯鉴别，这个后果只能由读者自己承担。一概推到作者的头上没有道理。
2013年2月 2日 00:11 | # | 引用
白色北京城 说：
可我觉得阮一峰只是会点儿编程的皮毛而已，还非要以大师的姿态自居，这是我不爽的地方，如果能拿出点儿真本事做点儿东西出来，那我真服，否则都是扯淡
2013年2月 2日 00:43 | # | 引用
杨少波 说：
谁以大师姿态自居了？这个推断从何而来？
别人有实验和只是分享精神，如果有纰漏，请你帮助更正，提出更好的解决方案。
2013年2月 2日 14:28 | # | 引用
zarzen 说：
就是你这样的人太多。所以技术氛围会变得糟糕。
有些事情，不需要项目证明。当然如果有，是很好的。没有不代表，错。
况且你貌似没怎么去挖掘过博主的代码，就开始说话了吧？
2013年2月 2日 16:56 | # | 引用
轻扬 说：
您从哪看出阮哥“以大师的姿态自居”的呢？
2013年2月 3日 01:10 | # | 引用
白色北京城 说：
一种说不出的感觉，感觉这个阮一峰很喜欢显摆，总感觉这个人很虚伪，不似一个技术人员应该有的低调和务实。
这个才是我真正敬佩的博客：http://www.matrix67.com
2013年2月 3日 01:47 | # | 引用
华定平 说：
人家是翻译别人的文章
2013年2月 3日 09:19 | # | 引用
细雨平湖 说：
发现牛逼人物很多！阮兄的厉害我认为不在于他编了多少代码，而在于他原来学经济学的，编程是自学的，而且我看得出他是真心热爱编程的，这点真是很难得！白色北京城兄引用的博客我也看了，的确也很牛！很高兴能从各位高手这儿启蒙，学到更多东西！
2013年2月 3日 12:07 | # | 引用
我要匿名 说：
M67很牛逼啊，我曾经可是彻头彻尾的膜拜过他，他是万千“业余数学”爱好者的精神偶像。这里用“业余爱好”是因为有所谓的数学专业的同学对他进行过专业批判，本来想引用的是豆瓣的“烟花不堪剪”说的话，可惜她注销了什么也搜不到了，下面贴出的是“Semailles ”最近说的（http://www.douban.com/group/topic/21262034/），大意和烟花说的相同，但没烟花刻薄：
“您的書單裏面有那麼多科普類的文章，譬如KLEIN的確定性的喪失，天書中的證明，存在之輕。而且在您的複分析的那篇帖子中，也表達了您對於複數的產生的悉心關切。我見過很多這樣的人，最明顯的就是M67，DAZZLED，你去看他們的BLOG，就會發現這些人一律執著于哲學和初等數學的範疇中，跟你大談數學思想方法，跟你扯出高斯，黎曼，扯上哥廷根老一輩，扯上哥德爾。爲什麽這些貨色嘴上出言不遜，旁徵博引，似乎還懂那麼一點數學，你去看看他們的聽眾就知道了。低等數學的周圍是一群學著高數，學著線性代數的人，物以類聚，哲學這東西很容易就把他們糊弄過去了。 ”
由于我本人不是学数学的，所以这并不代表我完全同意他说的，只想把这段话贴出来给你看，M67也遭受着类似的莫名“攻击”。假如他们（M67和阮）都不够出名的话，还有谁会冒着被喷的危险来批判他们，如果在出名之前就已经保持着一贯的风格，何来炫耀之说。他们只是在那里存在着，可有人非要上去贴各种标签，也许M67就是喜欢这些所谓的“初等”东西，但他也没有非要和数学专业的秀才们一较高低，他只是喜欢，花大量的时间写出来，然后简单的分享出去。（接下面）
2013年2月 3日 23:00 | # | 引用
我要匿名 说：
（接上面）你所不喜欢的“以大师的姿态自居”事实上是他的“风格”，也是你的“偏见”，像阮一峰这样资深博主写的东西是很明确的，不可能迎合所有人，不可能使所有人受益，喜欢的就看，不喜欢的拉倒。事实上，他文章中关于编程的内容只占很少的一部分，这也是他最近几年刚培养的兴趣，如果你不喜欢这部分可以看其他方面的文章啊。讲这些也没有否定你批判的权利，你可以对他文章的思想、细节进行批评，对为人的批评就没多大意义了。
关于“务实”，那你算说错了，他本来就不是搞编程的，你怎么能期待他来做很多项目在深刻掌握和理解之后再发表与此相关的文章，在我看来，他这更像是一个自我学习的过程，发表一篇文章不是为了证明自己早已知道这些东西，而是说他遇到了这些知识，从他的角度来说觉得有人也会用的上，于是就分享了过来，是一个记录也是一个提高的过程。事实上，网络上在这方面比他弱的人多了去了，人们之所以不去评论，因为可能连他们的网站都找不到，不能因为阮一峰出名，我们就要求更多，这不公平。对于他这样的博主，我不觉得有理由去苛求更多。
我想说明的是，很多时候我们给出一个观点，假如它错误，可能是因为我们的眼界不够开阔，了解的不够多。也就是说你的说法也有可能是正确的，但从他的一千多篇文章中来看，我实在无法同意你的观点。
以上只是我个人观点，当然也有可能错的面目全非（我的眼界不够开阔），但肯定可以给你提供一个看法。
2013年2月 3日 23:02 | # | 引用
白色北京城 说：
也许真的是我偏见，不过我敢于表达自己的想法，相信像我这么想的人也不在少数，你的看法或许是对的。不过我依然坚持我的看法，我一看到阮一峰写写技术文就像看到一个魔术师在表演魔术，貌似很高深，很了不起，也因此吸引了很多人的眼球，其实在真正的科学技术面前，那就是小儿科级别的拙劣表演。或者简单用两个字来总结，就是装B。阮一峰跟m67最大的区别是，m67写篇文章写的都很深入，而且有理有据，有理论有实践。而阮一峰的技术文章大多数是蜻蜓点水，或者空有理论，你再让他多说一点儿，他就说不出个所以然了，因为他自己其实并不懂。这种行文态度是我所讨厌的，就像我说的，当科普文其实还好，说是技术，那就贻笑大方了。
2013年2月 3日 23:56 | # | 引用
吴畅 说：
我觉得这位说的话很有价值的地方在于，他的话可以作为人类智识在某个阶段的一个分界点。
---------------------------------------------一个常常看贴不回人的真心回帖
2013年2月 4日 01:00 | # | 引用
我要匿名 说：
大家都明白对方的意思，也无意驳倒对方，再说下去意义不大，我就此打住。
2013年2月 4日 01:50 | # | 引用
陈一龙在线 说：
感谢ruan大侠分享。
2013年2月 4日 03:01 | # | 引用
cswuyg 说：
第二点很有感触
2013年2月 4日 11:08 | # | 引用
忧郁马赛克 说：
妹的，大清早一帮人不说技术，在这里讨论某个人，我觉得这一类帖子的回复应该是类似头脑风暴那种，不驳斥楼主，而是提出引导楼下往此贴主题方向走的回复，尼玛，看看抽象三原则的译本而已，结果看完回复后真心鄙视那些有动机的、习惯性固执的、引发毫无技术性的回复的楼上了。
2013年2月 4日 11:16 | # | 引用
Grants 说：
博主的“技术”范围很明显：js。 在现实生活里，用js的那套什么理论来忽悠的是很多，很多都是花架子。
总之一句话： 在战场上用的功夫，和在后花园里的花拳绣腿，是两码事。
博主当然也是尽力了，但是一旦上了战场，他会知道，那堆js技术，到底有没有价值。
2013年2月 4日 16:09 | # | 引用
斯人 说：
很有收获：“指的是当某个功能第三次出现时，才进行"抽象化"”!
谢谢！
2013年2月 4日 18:29 | # | 引用
清己 说：
@白色北京城 如果你来写代码抽象的三原则，你会怎么写， 怎么让大家感觉到真正的科学技术？
敢于表达自己的想法不错，但不代表随意表达！
我想你应该是一位知道什么是真正的科学技术的人， 希望能从你的言行中看到严谨。
2013年2月 7日 10:23 | # | 引用
清己 说：
这个让我想到了“无为”。
如果是这样，我会比较赞同。
1）尽可能写精简的代码，越精简，bug就越少。
2）尽可能的保证每一个函数的原子性, 配套完整的测试，方便修改。
3）尽可能将1）和2）做到最好，这样不管开发、调试最省事。
如果有其他，我觉得是
4）API的约束与自由的权衡，一般而言，API自由度越高，使用者学习成本越高，系统行为更不可控。
5）注意API的用户体验。
"三次原则"对我很有帮助，感谢@阮一峰！
2013年2月 7日 10:43 | # | 引用
datoukao 说：
说的有道理，但一峰哥不爱听批评，我们民族就是没有民主基因的。
2013年2月 7日 23:42 | # | 引用
james 说：
我很不理解为什么很多人看了以后不谈自己对写代码的理解，反倒一味在批评博主这儿不好那儿不好的。我今天因研究编码问题来到了博主的网站，看了几篇文章都觉得挺好的。博主把自己的心得拿出来分享，不同意博主观点的，站出来反驳就是。
2013年2月 8日 05:58 | # | 引用
GS 说：
不干写代码的活并不等于逻辑思维不好，而代码写得好不好考验的就是逻辑思维里面的总结/区分能力。换句话说就是现在IQ题测设的东西。更何况生活的很多地方也会有同样的需求，只不过不叫那么专业的名词而已。
2013年2月 8日 13:13 | # | 引用
是马无马 说：
有人看到了山上的松林，有人看到了山顶的亭子，有人看到了烟雾缭绕；
有人看出了美景，有人看出了顽石，有人看出了四不像但绝对不是山的东西。
山就在那里，岿然不动。
体会出不同东西，是您的自由：不过若我们礼貌地互相站得远点儿，这世界就真清净了。
2013年2月 8日 17:55 | # | 引用
Mr.King 说：
C本来就不容易学，所以学不会不要失去信心。
2013年2月 8日 23:54 | # | 引用
Jak Wings 说：
不知为什么会有这么多人回应他这句话。学学阮先生，对这类带有个人妄想的无聊评论作出无视的态度。大家可见阮先生有兴致回复这类评论？
2013年2月 9日 01:37 | # | 引用
practise 说：
@ 白色北京城：
有人以编程为职业，有人以编程为业余爱好，博主阮一峰先生是属于后者。再说编程大师本来就不以为编程是一门科学而是一门艺术。@白色北京城，追求技术精湛很好，但是不应该强求别人以你认同的风格来写博客。
2013年2月11日 15:02 | # | 引用
简直是搞笑 说：
你作为一个如此“严谨”的人，怎么会说出这种话【没写过一行代码】？你不是在打自己的脸嘛？
2013年2月14日 14:24 | # | 引用
嘻哈鸟 说：
有些人就擅长纸上谈兵，让他真做他倒做不好，纸上谈兵能弹出水平也不错啊！不见得非要亲自去做，所以有实践者、有评论家
2013年2月14日 17:18 | # | 引用
loyalbanker 说：
没记错的话，阮一峰是美工吧，当然这两年比较流行，可能改叫前端工程师了。
http://www.ruanyifeng.com/blog/2008/01/javascript_book_recommendation.html
阮一峰在中文blog圈的确算是一个很特殊的角色，真要说的话只能和月光比较相似，既善于维护自己形象，也大多是皮毛，不过阮一峰比月光高端许多，主攻翻译和整理外媒资料再讲述，实际上比所谓纯程序blog酷壳作者陈皓那样自大僵化的典型程序员好不少，偶尔看看科技文章也不是什么坏事。
当然如果你真想看阮一峰失态，那就只有等待中文博客圈再出一个当年cw的hung搅乱整个格局，只有那样带着不良个人利益目的出现的hater才能让人失态。
当然白色北京城的喷点也不对，拿M67拍阮一峰就更可笑了，他比阮一峰更恶劣，只是看起来很深奥罢了，加上这几年果壳的民科风潮，，其实文章里让人哑然失笑的内容很多，远不如阮同学的blog有看点。
2013年2月19日 17:26 | # | 引用
Ayu 说：
我在阮哥博文里学到不少东西。
技术也好，视野也好，总之我觉得是个好地方。
2013年2月22日 23:53 | # | 引用
Ayu 说：
如果看了about的页面，你会发现他不是个美工.而且js和美工好像不是一回事.
'所谓纯程序blog酷壳作者陈皓那样自大僵化的典型程序员'
hello, hater :-p
2013年2月22日 23:58 | # | 引用
Jack Hou 说：
我個人是從阮兄的博文裡得到不少啟發，很感謝他的心得分享。
2013年2月23日 21:39 | # | 引用
流浪猫 说：
看了评论我真的很悲哀，本来就是篇抛砖引玉的文章，结果底下的留言大多数却是和博主技术水平有关的口水战。我大概是07年初开始关注这个BLOG的，当时文章的类型比现在多样。有影评，有时政，有经济，还有许多有趣的东西。可能是因为某些原因（比如请喝茶），博客的内容多样性没以前好了。再加上作为一个编程爱好者，翻译的书以及文章在IT圈的一些网站和杂志刊载。有些人产生了博主是技术人员的误解。以我的观察，博主应该是从事和经济学有关的工作。
接下来我想说一下我为何关注博主的技术类文章。我本人是一位靠写代码吃饭的程序员，从事.net框架的BS项目的开发（就是常被行内人员瞧不起的那类）。刚接触这个BLog的时候，我还是位在校大学生，学什么东西都像一只无头苍蝇不得要领。博主以一个业余爱好者的角度写的一系列自学编程的文章让我受益匪浅。工作后，尽管BLOG的技术文章已经远远达不到我个人提高技术水平的要求，但还是有些文章给了我不少启发。尤其是一些关于算法类的和科技前沿的内容。老实说，博主编写JS的水平应该在我之上，这一点让我汗颜。但更让我敬佩的是博主对于编程的热爱。作为一位靠编程生计的普通人，写代码的乐趣因为工作而磨去大半。你需要花费大量时间去开发和维护一些你其实不感兴趣的代码。而你真正感兴趣的技术有时只能利用你的业余时间进行。最近希望通过换工作来技术转型也碰了不少壁。博主靠着自已的一腔热情，现在在IT圈里也产生了不少的影响，着实让人羡慕。其实技术是否大牛，并不影响一个人是否可以发表自己的看法。编程离不开谦虚，编程也离不开分享与交流。
2013年3月 4日 14:34 | # | 引用
冰上游鱼 说：
这思想是在说：要够懒（不做重复的事儿，把事物抽象化，通用化），而且要有点儿“着急”（敏捷）。
2013年3月 5日 01:20 | # | 引用
何维 说：
1.我觉得至少这篇blog的主题很明确，就是谈软件抽象的，大家的评论如果集中在博主对软件抽象的理解上是否正确，那么这个评论是可行的。
2.从一篇技术文章，或者从一个以技术为主的blog里，推断出博主有装B倾向，这个我觉得没有任何意义，因为其实你可以说任何一个人在装B，他爱写技术文章，你可以说他装B显摆；他不爱写技术文章，你可以说他装B深沉，他写一点技术文章，但是写的不勤，你可以说他爱装B，每次写一点出来吊人胃口。
3.乐于表达观点这个没错，但是如果你是搞技术的，而且你也推崇严谨的话，我觉得最好在表达自己观点的时候，给出一个比较严密的论证。你可以说你看了博主的那几篇blog里面的那几行句子，推断出他是个装B的人。
ps：我觉得赵括爱纸上谈兵没错，他的错误在于不知道如何把纸上的理论结合到实际；如果你觉得博主总结的都比较到位，虽然博主没有机会去实践自己的总结，而你有机会去实践，且对你自己又有帮助，这不是双赢吗？
2013年3月10日 18:16 | # | 引用
biaobiaoqi 说：
rules of three挺有指导意义的。
ls有人拿出oop那一套封闭性...风马牛不相及而已。
2013年4月 8日 12:05 | # | 引用
kevin 说：
道理是知道实践起来比较不给力啊
2013年4月 9日 22:56 | # | 引用
GaoPP 说：
那你就一辈子码农的命了!!!
2013年4月17日 22:20 | # | 引用
wangjl 说：
Rule Of Three
这个命题存在一个致命的缺陷：第二次出现的代码（或部分代码）肯定会从第一次出现的地方copy过来。
Rule of three 允许了：“同样的错误可以出两次”，所以我认为它的代价和和收益并不一定是相等的。
我选择Rule of two
2013年4月20日 01:18 | # | 引用
elan 说：
我擦 前段时间在淘宝上买了《Joel on Software》的中文版 那个版本翻译确实惊悚 - - 书的装帧也很烂 一些观点看起来也老了 不过终归是好书 这个翻译应该不太难吧 毕竟台湾的翻译项目已经把全本翻译完了= = 但是最后的问答没有翻译
2013年4月24日 16:33 | # | 引用
菜鸟一枚 说：
这就是理论和实践的东西，没有一种理论可以指导所有的实践，所以关键在于自己去怎么理解，去应用。本人是菜鸟，只是谈谈自己的看法，没有别的意思。呵呵。
2013年5月 5日 09:58 | # | 引用
xiaolong 说：
我觉得楼上的质疑明显跑题了，看过算法导论的人都知道 清晰的算法思想才是最重要的，当然跟编码经验有关；
一个整天只会编码的monkey 木有自己的思想 岂不更悲剧
2013年6月29日 22:26 | # | 引用
clear 说：
这里面越来越像天涯论坛了
2014年2月10日 10:31 | # | 引用
luobotang 说：
评论很精彩啊！
2014年7月28日 16:40 | # | 引用
菜鸟一枚 说：
我觉得很有感触，谢谢楼主，楼主好人。
2014年9月 1日 22:19 | # | 引用
light 说：
对某个实现有足够的信息做到“DRY原则”而且可以预见“DRY原则”更好，那直接“DRY原则”。我觉得这三个原则更适合新手，老手倒不需要这些条条框框。
2014年11月19日 11:26 | # | 引用
年华果腹 说：
好酸啊
2015年11月24日 14:43 | # | 引用
NULL 说：
阮一峰更多的是从原理探究为什么，最初的来源。
2016年5月28日 11:26 | # | 引用
11111 说：
天呐 我真的无法理解你。
代码就是 屎. 我要是老板 阮一峰 一年最少 100W 人民币,而你，无论代码写的多好最多20W 年薪。
而阮一峰的薪水是2013年,而你的薪水是2016年的。
2016年7月14日 15:00 | # | 引用
svn 说：
博主是在分享自己的学习心得，你却不是评论他的知识是否正确，恶意的人身攻击
2016年11月 9日 14:50 | # | 引用
TimberTang 说：
阮大神真的是我心目中的神. 读完他计算机相关的博客, 绝对受益匪浅
2016年12月28日 15:31 | # | 引用
cara 说：
乐死我了，从头到尾只是你自己一个人的自我猜测而已吧？自己一点东西都拿不出来的有什么资格在这里指手画脚别人的成果呢？你不嫌丢人吗？以后做什么事都不要以你那鼠目寸光的姿态来发表一些你自认为有道理但其实只是一堆废话的言论了好吗。
2018年11月10日 11:27 | # | 引用
kinga 说：
大家的评论很有意思。一篇文章一千个读者。
能写自己的文章已经不容易，定期更新更不容易。
可以发表意见，但请尊重作者。
2019年5月25日 22:11 | # | 引用
就叫商先生吧 说：
关于他说的“仔细推敲的话，你会发现DRY原则和YAGNI原则并非完全兼容。前者追求"抽象化"，要求找到通用的解决方法；后者追求"快和省"，意味着不要把精力放在抽象化上面，因为很可能"你不会需要它"。”这个观点是有很大问题的。DRY是从已经实现的代码角度来看，如何进行设计；YAGNI是对于还没有实现的功能，进行取舍。这两者要解决的问题根本不是一个层面的，不具有可比性，阮这样说只是他的主观臆断。从实际项目角度来看，这两个原则的目标是高度一致的。
以我的一个实际项目为例，某个项目本身是一个单体工程，后来由于不断演进，需要进行拆分，主体业务作为一个项目，两个具备一定通用性，使用率较高的两个模块拆分成单独的服务。其中有个功能是用户输入的值允许参数化。决策者当时决定，拆分出来的两个服务允许参数化，这样假如第三方需要的时候，也可以支持了。于是就导致，参数化在主体模块，独立服务模块都支持参数化。同样的逻辑在三个项目中存在。随着项目不断发展，以前参数化方式的很多弊端被发现，于是每次修改的时候，三个模块都要同步修改。经过很长时间运行，其实发现独立服务根本没有人使用这样的功能，只有这个主体业务在用。
这个设计首先违背了YAGNI，为了不存在的第三方调用，虚构出这样的一个需求；其次违背了DRY，同样的代码到处拷贝，每次维护继续拷贝。
所以DRY不是阮所谓的追求抽象化，而是说要集中，封装，其实更类似于开闭原则，将变化的部分，集中到一起，而不是同样的逻辑到处分散。DRY是针对你必不可少的功能和逻辑而言；YAGNI是告诉你，有些东西根本不需要，不需要的东西，何来抽不抽象，变不变化?只有不写的代码，才没有bug。
2019年7月31日 10:47 | # | 引用
BlackC 说：
也许我就是那个深陷抽象陷阱的人
恨不得把工作中所有代码都抽象一遍
只是想着以后有可能会复用
现在明白的是 不一样的场景有不一样的最优解
2023年1月31日 16:42 | # | 引用