这些烂代码习惯，能保住你的饭碗！

乔梁-北京

发布于 2026-06-16 16:08:29

1670

1 引子

既然之前写了代码质量的评估标准，今天就再介绍一下，如何用烂代码保住你的饭碗。

下面这些问题不只是『写得丑』，而是直接导致团队效率崩盘、项目质量雪崩，让老板增派人手的好办法的。

2 过度工程（Over-Engineering）

表现

一开始就为了『可能』出现的需求堆积无数抽象、接口、设计模式。
代码复杂到自己都看不懂，还自豪地说『架构很优雅』。

Java 示例（反例）

public interface UserPersistenceStrategy {
    void saveUser(User user);
}
public class DefaultUserPersistenceStrategy implements UserPersistenceStrategy {
    public void saveUser(User user) {
        // 保存逻辑
    }
}
public class UserManager {
    private UserPersistenceStrategy strategy;
    public UserManager(UserPersistenceStrategy strategy) {
        this.strategy = strategy;
    }
    public void save(User user) {
        strategy.saveUser(user);
    }
}

问题

这么复杂只为了简单保存一个用户？需求根本没有多变，而纯粹浪费维护成本。

正确做法

YAGNI（ You Aren't Gonna Need It）原则

只为当前真实的需求设计，不预支未来的复杂性。

3 核心逻辑隐藏在工具类

表现

大量 Utils、Helper 类，把真正重要的业务逻辑藏在一堆静态方法里。
导致整个项目就像一锅炖烂的汤，谁也不知道一口能吃到啥。

Java 示例（反例）

public class UserUtils {
    public static boolean isVip(User user) {
        return user.getPoints() > 1000;
    }
}
public class OrderService {
    public void createOrder(User user) {
        if (UserUtils.isVip(user)) {
            // 走VIP流程
        }
    }
}

问题

业务逻辑（如是不是 VIP）藏在工具类，或者 Service 很难读懂。

正确做法

业务逻辑应该放在领域模型或服务层，而不是扔到工具类。

4 滥用继承，过深继承树

表现

一堆 Manager 继承 BaseManager，BaseManager 又继承 AbstractBaseManager。
父类改一点，子类全炸。

Java 反例

public class AbstractUserManager {
    protected void connect() { /* 连接DB */ }
}
public class BaseUserManager extends AbstractUserManager {
    protected void authenticate() { /* 鉴权 */ }
}
public class PremiumUserManager extends BaseUserManager {
    public void premiumFeatures() {
        connect();
        authenticate();
        // 高级功能
    }
}

问题

深层继承导致理解难度爆炸。
复用错位：PremiumUserManager 明明只是想扩展功能，却被迫继承一堆底层细节。

正确做法

优先使用组合（Composition），而不是继承（Inheritance）。

"has-a" 通常比 "is-a" 更灵活。

5 DTO、Entity、VO、Form 层层转，复制到疯

表现

小小一个用户对象，DTO、Entity、Form、VO、BO 来回转好几圈。
每个类 99% 字段一样，只是名字不同。

Java 反例

public class UserDTO {
    private String name;
    private int age;
}
public class UserEntity {
    private String name;
    private int age;
}
// 然后各种Mapper工具来回copy...

问题

过度分层导致性能、开发效率受损。
没有业务边界时硬分层就是负担。

正确做法

按上下游系统的边界来设计对象，只有真正跨层或跨系统需要隔离时才引入 DTO、VO。

6 伪接口编程

表现

每个类都强行写个接口，接口永远只有一个实现。
『为了接口而接口』，没有替换的必要，还要维护双份代码。

Java 反例

public interface UserService {
    void createUser();
}
public class UserServiceImpl implements UserService {
    public void createUser() { /* 逻辑 */ }
}

问题

没必要的抽象让代码量虚高，理解成本上升。

正确做法

接口是为了变化而生。如果没有多实现需求，直接用具体类，后续有需要时再提取接口。

没有契约的微服务

表现

微服务接口设计混乱，没有 API 规范，没有版本管理。
参数随便变，返回值随便加字段。

Java 反例

@PostMapping("/user")
public Map<String, Object> createUser(@RequestBody Map<String, Object> body) {
    // 用 `Map` 接参数，返回也是 `Map`
}

问题

无类型约束，调用方无从下手。
接口文档形同虚设。

正确做法

用严格定义的 Request/Response 对象，配合 Swagger/OpenAPI，接口必须有明确契约。

7 总结一句话

在大型项目里，不是写不写得动代码的问题，而是

能不能让别人快速理解
能不能让后续维护简单
能不能支持系统可扩展性

烂代码 ≠ 只影响自己 烂代码是拖垮整个项目、整个团队的毒瘤。

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2025-06-11，如有侵权请联系 cloudcommunity@tencent.com 删除

public