王垠最近的DRY原则的危害这篇文章引起了大家的关注，我正好借着这个上下文发表一下自己的看法。
自己很早就有“不重复”的觉悟，但当时自己的总结是：“如果A和B的代码很相似，并且它们在面对变化的时候很大概率是要求保持一致的，那么不要把A和B的代码重复写两遍”。 后来看到了所谓的“DRY”原则，第一反应是心有戚戚，第二反应是它说得太绝对了。
我说它“太绝对”并非出于某些普适的中庸观念得出的，我就举一个例子：
某电商管理页面左有导航栏，下有条目 [“商店管理”，“商品管理”, “数据统计”] ，其中每个导航栏条目下包含数个子页面，如“商品管理”下就有“商品列表”，“橱窗列表”等页面。现有需求：当用户处于某导航栏条目下的某个子页面的时候，高亮该导航栏条目。
- 代码1
current_uri == "/goods/goods_list" or current_uri == "/goods/goods_showcase_list"
- 代码2
current_uri in ["/goods/goods_list", "/goods/showcase_list"]
- 代码3
current_uri.startsWith "/goods/"
对于这三段代码，我并不认为一种就一定比另外一种好。可能很多人会很诧异，明明代码3漂亮得多嘛！
当然我最后选择的也的确是代码3的写法，不过，确定用代码3之前，我确认了以下问题：
我能确定我在处理这段逻辑的时候总是会用
==作比较么？ 如果答案是否定的，我就不能从代码1转换到代码2我能确定UI的导航栏上的条目（如“商品管理”）和页面的URL结构（如"/goods/"）有固定的关系么？ 有没有可能加入新的页面，它所属的导航栏条目和它的URL不满足以上关系？ 如果答案是否定的，我就不能从代码2转换到代码3
这里的关键在于：我需要建立一个导航栏UI控件和页面URL之间的联系。那么这个逻辑关系只会在当前的需求里出现么？有没有可能这个逻辑在别的地方同样可能用到？ 如果答案是否定的，我就不能写下代码3，而是应该把这段逻辑抽离成为独立的模块。
当然菜鸟和我和大师都可能写下代码3，然而每个人得到这段代码的过程是不一样的。大师的代码就是可以灵活地应对变化，这是因为人家的确想得比你多，而不是因为人家遵循了什么DRY原则。
