这些烂代码习惯，能保住你的饭碗！
持
乔梁约 3 分钟
乔梁约 3 分钟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 {protectedvoidconnect() { /* 连接DB */ }}public class BaseUserManager extends AbstractUserManager {protectedvoidauthenticate() { /* 鉴权 */ }}public class PremiumUserManager extends BaseUserManager {publicvoidpremiumFeatures() {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 {voidcreateUser();}public class UserServiceImpl implements UserService {publicvoidcreateUser() { /* 逻辑 */ }}
问题
没必要的抽象让代码量虚高，理解成本上升。
正确做法
接口是为了变化而生。如果没有多实现需求，直接用具体类，后续有需要时再提取接口。
没有契约的微服务
表现
微服务接口设计混乱，没有 API规范，没有版本管理。参数随便变，返回值随便加字段。
Java 反例
@PostMapping("/user")public Map<String, Object> createUser(@RequestBodyMap<String, Object> body) {// 用 `Map` 接参数，返回也是 `Map`}
问题
无类型约束，调用方无从下手。 接口文档形同虚设。
正确做法
用严格定义的 Request/Response 对象，配合 Swagger/OpenAPI，接口必须有明确契约。
7 总结一句话
在大型项目里，不是写不写得动代码的问题，而是
能不能让别人快速理解 能不能让后续维护简单 能不能支持系统可扩展性
烂代码 ≠ 只影响自己
烂代码是拖垮整个项目、整个团队的毒瘤。