这些烂代码习惯，正在悄悄毁掉你的软件项目！
持
乔梁约 3 分钟
乔梁约 3 分钟下面这些问题不只是“写得丑”，而是直接导致团队效率崩盘、项目质量雪崩的。
1 过度工程（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);}}
问题
业务逻辑（如是不是 VIP）藏在工具类，或者 Service 很难读懂。
正确做法
业务逻辑应该放在领域模型或服务层，而不是扔到工具类。
2 滥用继承，过深继承树
表现
一堆 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” 更灵活。
3 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。
4 伪接口编程
表现
每个类都强行写个接口，接口永远只有一个实现。
"为了接口而接口"，没有替换的必要，还要维护双份代码。
Java 反例
public interface UserService {voidcreateUser();}public class UserServiceImpl implements UserService {publicvoidcreateUser() { /* 逻辑 */ }}
问题
没必要的抽象让代码量虚高，理解成本上升。
正确做法
接口是为了变化而生。如果没有多实现需求，直接用具体类，后续有需要时再提取接口。
5
表现
微服务接口设计混乱，没有 API 规范，没有版本管理。
参数随便变，返回值随便加字段。
Java反例
@PostMapping("/user")public Map<String, Object> createUser(@RequestBodyMap<String, Object> body) {// 用Map接参数，返回也是Map}
问题
无类型约束，调用方无从下手。
接口文档形同虚设。
正确做法
用严格定义的 Request/Response对象，配合Swagger/OpenAPI，接口必须有明确契约。
6 总结一句话
在大型项目里，不是写不写得动代码的问题，而是
能不能让别人快速理解
能不能让后续维护简单
能不能支持系统可扩展性
烂代码 ≠ 只影响自己，烂代码是拖垮整个项目、整个团队的毒瘤。