※ 引述《sec5566 (sec)》之铭言：
: 或是命名规则有问题的，
: 像函式用大驼峰，类别用小驼峰，
: 或很奇怪的名称之类，
: 不然就是排版很乱的，
: 这种大家会手痒去改吗？
就跟推文乡民讲的一样 这是团队的管理问题
通常命名如果不符规则 只是改大小写这应该不用过问吧
但是改名称 老实讲这要看写的人还在不在职啦
不然你改了 code review时解释说: 这名称很奇怪
除非你跟对方沟通过 或你比对方大牌
做事做就是做人 没有对事不对人的
(何况 你有办法保证你的命名一定比较好？)
: 改下去又是大工程了，结果工作越做越多
你前面讲dry原则的 软件开发原则很多 但这些原则多半都被有心人士拿来吵架用
更何况 这些原则能不能为商品带来价值 多数都不能
我建议三小原则的 放在自己心中默默实践就好
我讲一下重构的几个种类 这是小弟我在业界的观察
1. 命名、拆解
这就是clean code里很基本的东西
function不要太长 命名清晰描述单一动作
改名的事情我前面说过了 这边就不赘述
IMO 比起改错字、大小写 他命名很奇怪我把他改掉
把大function拆解成小function 还比较有用
(而且绝对不会是大工程... 所以... 要实践你所谓的dry可以从小事做起)
2. 运用语言技巧 精简程式码
老实讲这种事情就只是单纯的炫技
小弟我就曾经把一大段大量重复的code
利用Template 将逻辑拆解成Policy
使得每个重复的流程都可以透过组合的形式避免duplicated
但说真的 它的价值就只有文学上的价值而已
(我认为在某些状况下 重复的code不见得是错误或不良的)
3. 架构
我认为需要改架构的状况只有几种：
a) 逻辑紊乱重复 导致效能低落或维护不易
b) 当前的架构无法因应新的需求或改变
这种状况 才是你所说的工程浩大
不然一般状况下的重构搬移删除重复代码都只是很基本很浅的功夫
TL;DR
其实重点是这样的
在这个业界 有需求 满足需求才会产生价值
你的需求 如果只能满足你个人 那我肯定你做的事情是没啥帮助的
更何况 你重构又怎么能保证不会有新的问题产生
所以最好的方式是 建立测试 才去重构
而不是重构自己爽完了 留给后人收拾问题
小弟上次重构 把一个重点功能的速度提升至少2.5倍
还赢得了与某大公司进一步合作的机会 给你参考