前端开发中最臭名昭著的架构反模式可能是大泥球。术语“大泥球”适用于没有明显结构或模块化组织的系统。代码库有机且混乱地增长，成为维护的噩梦。这是许多开发人员发现自己所处的情况，特别是当面临最后期限并开发大量功能时。
这就是当前文章的内容：大泥球反模式以及前端开发中的示例，为什么它如此常见，它何时成为问题以及如何解决这个问题。
什么是大泥球？
大泥球是一个架构边界定义不明确的系统。在这样的系统中，代码变得纠缠和高度耦合，因此维护或扩展项目变得有问题。随着时间的推移，随着越来越多的功能被添加而不关注整体设计，使用代码变得越来越困难。如果没有结构，对系统某一部分的更改很容易破坏其他部分，从而无意中引入错误，从而进一步提高开发的复杂性。
在大泥球中，您经常会看到以下特征：
noaa 明确关注点分离；业务逻辑、ui 和数据获取是交织在一起的。 noaa 松散耦合；这些组件相互交织，因此很难将更改分开。 noaa 模块化；系统的每个部分都依赖于其他部分。 noaa 全局变量或共享状态具有不可预测的副作用。
大泥球是快速交付而没有对架构给予应有关注的高压的常见结果。在项目开始时，开发人员通常急于尽快构建功能，而很少有时间进行充分的规划。这导致代码库在各个方向上增长，新逻辑被插入到任何适合的地方。随着时间的推移，重构会被延迟或忽略，以支持交付更多功能，并且架构会恶化。
造成这种反模式的其他因素包括：
- 缺乏协调：开发者之间没有相互协调。不一致的编码和分散的功能随之而来。
- 没有既定标准或制定指导开发的架构原则。
- 技术债务：在已经很混乱的代码之上添加新功能，而没有清理混乱。
让我们仔细看看大泥球在普通前端项目中可能是什么样子。
前端大泥球示例
这是前端架构中大泥球反模式的抽象示例。考虑一个小型 react 项目，该项目在一段时间后变得混乱。
文件结构：
/src
/components
/header.js
/footer.js
/sidebar.js
/maincontent.js
/userprofile.js
/utils
/api.js
/constants.js
/styles
/globalstyles.css
/app.js
/index.js
该架构的问题：
- 缺乏模块边界：组件，例如页眉、页脚和用户配置文件，都驻留在一个文件夹中，而不考虑它们各自所扮演的角色。
- 关注点混合： 组件负责获取数据，即 api 调用和渲染 ui 元素。因此，逻辑层和表示层之间的紧密耦合仍然存在。
- 全局样式： 该项目依赖于单个全局 css 文件。随着应用程序的增长，这可能会导致样式冲突，并且更难以维护。 在组件中直接使用api：在userprofile.js等组件中直接导入获取和更新数据的方法，从而将数据获取逻辑与ui代码混合在一起。
userprofile.js 的示例代码：
import React, { useState, useEffect } from 'react';
import { fetchUserData, updateUserProfile } from './utils/api';
import './styles/globalStyles.css';
const UserProfile = () => {
const [user, setUser] = useState(null);
const [loading, setLoading] = useState(true);
useEffect(() => {
fetchUserData()
.then((data) => {
setUser(data);
setLoading(false);
})
.catch((error) => console.error('Error fetching user data:', error));
}, []);
const handleUpdate = () => {
updateUserProfile(user)
.then(() => alert('Profile updated!'))
.catch((error) => console.error('Error updating profile:', error));
};
if (loading) return Loading.;
return (
{user.name}
);
};
export default UserProfile;
代码中的问题：
- 无 soc： 数据获取、状态管理和 ui 渲染均在组件内的一处执行。
- 紧耦合： api 的更新会强制更新多个组件，因为 api 和组件之间没有抽象层。
- 无逻辑重用：另一个需要访问用户数据的组件将重新实现 api 调用或将自身与此逻辑紧密耦合。
这种错综复杂、相互依赖的代码很难扩展和维护，这就是大泥球。
问题什么时候开始出现？
采用此类架构的项目可能不会立即出现明显的问题迹象。但随着项目的发展，问题也随之复杂化：
- 开发速度缓慢：更改变得更加危险，因为与更改位置无关的系统部分可能会出现错误。
- 更大的技术债务：未重构的附加功能涉及架构改进，而这些改进变得更难以实现。
- 生产力低下：开发人员将开始花费更多时间来导航并从这些混乱的代码中找出有意义的东西，从而减慢功能的开发。
打结越多，就越难解开。当然，这只是技术债务增加和生产力下降的恶性循环。
如何避免大泥球
为了避免“大泥球”，必须尽早灌输良好的架构习惯，并在开发过程中严格执行。以下是一些策略。
模块化架构：将代码清晰地划分为具有责任边界的逻辑模块。例如，关注点可以通过数据获取、业务逻辑和 ui 渲染来分离。
抽象：通过服务或挂钩抽象 api 调用和数据管理，以便将这些关注点从组件中抽象出来。这将有助于解耦代码并更轻松地处理 api 中的更改。
模块边界：组件之间应该有明确定义的边界。不要将所有组件都放在一个文件夹下，而是为一项功能或域创建单独的文件夹。
全局状态管理： 使用 redux、mobx 或 react 的 context api 等库进行组件之间的共享状态管理。这大大减少了组件自行管理状态的需求。
重构：定期重构。不要让项目发展到绝对无法再处理的阶段；解决这些问题，同时保持代码库干净。
如果您已经陷入大泥球该怎么办
如果你的项目已经变成了一个大泥球，那么还有希望。补救措施是重构代码库零碎，尽可能地烘焙架构原则。开始于：
- 识别痛点：专注于代码中使用或扩展最困难的部分。
- 模块化组件： 增量重构组件以分离关注点并限制依赖关系。 现在，介绍测试：添加单元和集成测试，以确保您的重构不会破坏现有功能。
总之，大泥球是一种非常常见的反模式，在前端项目中造成很多麻烦。模块化架构的引入、关注点分离和定期重构无疑是避免代码库中这种模式带来的混乱的步骤，使其更干净、更易于管理。
