重复代码复制粘贴一时爽维护火葬场同一段逻辑出现在三个以上地方就是灾难的前奏。今天改需求你改了A处忘了B处测试没覆盖到上线就炸。DRY原则不是口号是血泪教训。把公共逻辑抽成方法或工具类哪怕只调用两次也值得。有人说“两次而已没必要抽”等第三次出现时你已经找不到所有散落的副本了。复制粘贴是技术债里利息最高的那种。过长方法一个方法三百行谁看谁头疼方法超过五十行基本可以断定它干了不止一件事。读代码的人得从头看到尾中间跳出去查变量再回来接着看脑子早乱了。把大方法拆成小步骤每个方法只做一件事名字起清楚。比如processOrder拆成validateOrder、calculatePrice、saveOrder。拆完不仅好读单元测试也好写。方法短了bug藏不住。过大的类上帝类什么都管什么都管不好一个类两千行字段五十个方法一百个。这种类叫上帝类听着威风实则谁都不敢动。改一个字段不知道哪里会受影响。按职责拆用户相关的放UserService订单相关的放OrderService。单一职责原则不是学院派理论是让你半夜不被报警电话吵醒的护身符。类越小改起来越放心。长参数列表五个以上参数调用全靠猜createUser(String name, int age, String city, String phone, String email, boolean isVip)调的时候得对着方法签名数位置一不小心传反。参数超过三个考虑封装成对象。UserCreateRequest把相关参数收进去调用清晰扩展也方便。参数列表越长出错概率越高。发散式变化一个类因为不同原因被改每次改价格逻辑要动这个类改库存逻辑也要动这个类改通知逻辑还得动它。这说明类承担了多个维度的变化。把不同原因的变化拆到不同类里价格归价格库存归库存。一个类只应该因为一个原因被修改否则改一处崩三处。霰弹式修改一个小需求改十几个文件加一个字段从Controller改到DAO中间Service、DTO、Mapper全要动。这不是敏捷是折磨。说明职责划分太碎或者抽象层次不对。该合并的合并该用继承或组合的重新设计。改一个功能动十个文件不是勤奋是设计烂。注释过多代码说不清楚才靠注释遮羞好代码自解释坏代码才靠注释。方法名getUserById不需要注释int a b 2; // 计算两倍纯属废话。真正该注释的是为什么这么做而不是做了什么。如果一段代码非要大段注释才能看懂不如重写。注释是无奈时的补丁不是常态。坏味道像房间里的灰尘每天落一点不扫就积成厚厚一层。每周花半小时重构一小块比攒半年再推倒重来轻松得多。别让代码烂在手里改掉这些坏味道你会发现加班少了头发多了。