React組件設(shè)計：為什么認知負荷比性能指標更重要？
作者：阿森
你的組件能跑，性能指標也不錯。但在code review時被提意見："這個邏輯能不能拆一下，看不太懂"。你心想：性能沒問題啊，為什么還要改？
一個真實的困境：
你的組件能跑，性能指標也不錯。但在code review時被提意見："這個邏輯能不能拆一下，看不太懂"。
你心想：性能沒問題啊，為什么還要改？
真相是：你的代碼在機器上跑得很快，但在開發(fā)者的腦子里跑得很慢。
而當人的大腦處理效率下降時，bug、延期、溝通成本就會隨之上升。
一、認知負荷理論——為什么有些代碼讓人想砸電腦
認知負荷的三個維度
認知心理學(xué)中的認知負荷理論（Cognitive Load Theory）把人腦處理信息分為三層：
1. 內(nèi)稟負荷（Intrinsic Load）
- 問題本身的復(fù)雜度
- 比如"實現(xiàn)權(quán)限系統(tǒng)"比"渲染一個按鈕"的內(nèi)稟負荷高
- 這個你無法改變，只能通過分解任務(wù)來降低
2. 外來負荷（Extraneous Load）
- 理解這個問題所需的額外工作量
- 這是你的代碼造成的
- 比如看不懂變量名、嵌套太深、邏輯混亂
3. 相關(guān)負荷（Germane Load）
- 用于學(xué)習(xí)和建立心智模型的認知資源
- 好的代碼設(shè)計能讓這部分資源充分發(fā)揮
關(guān)鍵發(fā)現(xiàn)：人的工作記憶容量是有限的（約4-7個元素）。如果外來負荷太高，相關(guān)負荷就沒有空間了，學(xué)習(xí)和創(chuàng)新就停止了。
看這個對比：
// 這段代碼的外來負荷很高
export function UserPanel({u, d, s, p, c, h, e}) {
return (
<div>
{u && u.role === 'admin' || u?.role === 'super' ||
(d && d.permission > 5) ? (
<AdminPanel data={s} onHandler={p} config={c} header={h} />
) : u && !u.banned ? (
<UserPanel data=5gk0f71da onEvent={e} />
) : (
<RestrictedView />
)}
</div>
);
}
// 工作記憶需要同時維護：
// 1. u, d, s, p, c, h, e 的含義（7個縮寫）
// 2. 條件判斷的優(yōu)先級（&&、||、?:的嵌套）
// 3. 三個分支返回什么（AdminPanel、UserPanel、RestrictedView）
// 4. 各個分支需要的props映射（哪個數(shù)據(jù)給哪個組件）
// = 至少15-20個信息元素要同時處理一個開發(fā)者的工作記憶容量被"解析代碼結(jié)構(gòu)"占滿了，就沒有空間去思考"需求該怎么改""這里有沒有bug"。
// 這段代碼的外來負荷很低
exportfunction UserPanel({
user,
userData,
settings,
onPanelOpen,
config,
onStatusChange,
onDetailExpand
}) {
// 第一步：權(quán)限判斷 - 獨立的邏輯塊
const isAdmin = user?.role === 'admin' || user?.role === 'super';
const hasElevatedAccess = userData?.permission > 5;
const canAccess = isAdmin || hasElevatedAccess;
const isUserBanned = user?.banned === true;
// 第二步：分支判斷 - 清晰的決策樹
if (isUserBanned) {
return<RestrictedView />;
}
if (canAccess) {
return (
<AdminPanel
data={settings}
onOpen={onPanelOpen}
config={config}
/>
);
}
return (
<UserPanel
data={userData}
onChange={onStatusChange}
onExpand={onDetailExpand}
/>
);
}現(xiàn)在工作記憶只需要維護：
- 三個權(quán)限判斷變量（3個信息）
- 清晰的if-else流程（理解簡單）
- 每個分支的返回值（一行一個）
工作記憶占用 = 原來的1/3
這不是代碼行數(shù)的問題（確實增加了），而是認知復(fù)雜度的問題。
二、命名——第一道認知防線
為什么看到一個變量名，大腦會做三件事
當你看到 data 這個名字時：
- 語義檢索：大腦從長期記憶里搜索"data"通常代表什么（通用名詞，含義模糊）
- 上下文匹配：在這個文件里它應(yīng)該是什么？（需要往上翻代碼）
- 預(yù)期對齊：根據(jù)這個名字，我預(yù)期它會是什么形狀？（還是不知道）
如果這三者不匹配，**大腦就陷入"認知沖突"**。
// ? 認知沖突案例
function Item({data}) {
return <div>{data.name}</div>;
}
// 用這個組件時
<Item data={userInfo} /> // "data"是用戶信息嗎？
<Item data={productList} /> // "data"是列表嗎？還是單個項？
<Item data={apiResponse} /> // "data"包含響應(yīng)的全部字段？還是只是data字段？每次使用都要思考一下，累積起來就是大量的時間浪費。
// ? 清晰的命名
function UserCard({userInfo}) { }
function ProductList({items}) { }
function ApiResponse({response}) { }
// 還是不夠好，可以更明確
function UserCard({currentUser}) {
// 一眼就知道這是"當前用戶"，不是"所有用戶"
}
function ProductGrid({productItems}) {
// "Items"明確了這是一個集合
}
function ApiResponse({apiResult}) {
// 雖然叫"result"，但"Api"前綴說明了上下文
}命名的層級
第一層：通用名詞（最差）
<Component data={x} />
<Component info={y} />
<Component content={z} />問題：任何東西都可以叫"數(shù)據(jù)"、"信息"、"內(nèi)容"。
第二層：帶數(shù)據(jù)類型（更好）
<Component userList={users} />
<Component orderData={order} />
<Component productArray={items} />改進：至少告訴我"這是用戶列表"還是"這是訂單數(shù)據(jù)"。
第三層：帶業(yè)務(wù)含義（最好）
<Component searchResults={users} />
<Component currentOrder={order} />
<Component recommendedProducts={items} />最好：不僅知道數(shù)據(jù)類型，還知道在業(yè)務(wù)中的角色。
實際例子：
// 場景：列表頁面
// ? 糟糕
<Sidebar menu={config} />
<Table data={rows} columns={cols} />
// ?? 好一點
<Sidebar navigationMenu={config} />
<Table items={rows} columnDefs={cols} />
// ? 最好
<Sidebar navigationLinks={navigationConfig} />
<Table dataRows={rows} columnDefinitions={cols} />
// ?? 甚至可以更明確
export interface SidebarProps {
/** 側(cè)邊欄導(dǎo)航鏈接列表，用于頁面路由 */
navigationLinks: NavLink[];
}
export interface TableProps {
/** 表格顯示的數(shù)據(jù)行 */
dataRows: DataRow[];
/** 表格列的定義，包括字段映射和渲染規(guī)則 */
columnDefinitions: ColumnDef[];
}成本-收益分析：
- 多打幾個字母：+30秒
- 減少新人詢問："這個參數(shù)是什么意思？" = -5分鐘 × 5個人 = -25分鐘
三、邏輯復(fù)雜度——分層遞進vs一坨代碼
嵌套深度與理解難度的關(guān)系
研究表明，代碼嵌套深度與bug率有正相關(guān)：
嵌套深度 | 平均bug率
---------|----------
1-2層 | 3.5%
3-4層 | 8.2%
5-6層 | 15.1%
7+層 | 25%+這不是因為深層代碼更復(fù)雜，而是因為大腦跟蹤深層狀態(tài)的成本指數(shù)級上升。
// ? 嵌套地獄 - 7層嵌套
exportfunction OrderStatus({order, user, config}) {
return (
<div>
{order ? (
user ? (
config?.showDetails ? (
order.items ? (
order.items.length > 0 ? (
order.status === 'completed' ? (
<Success message="訂單完成" />
) : (
<Pending />
)
) : (
<Empty />
)
) : (
<Loading />
)
) : (
<Simple />
)
) : (
<LoginPrompt />
)
) : (
<Error />
)}
</div>
);
}
// 讀這段代碼時，工作記憶需要追蹤的狀態(tài)：
// 1. order 存在嗎？
// 2. user 存在嗎？
// 3. config.showDetails 為真嗎？
// 4. order.items 存在嗎？
// 5. order.items 長度 > 0 嗎？
// 6. order.status === 'completed' 嗎？
// = 6個條件同時在工作記憶中旋轉(zhuǎn)// ? 分層遞進 - guard clause模式
exportfunction OrderStatus({order, user, config}) {
// 第一層：驗證前置條件
if (!order) return<Error />;
if (!user) return<LoginPrompt />;
// 第二層：檢查配置
if (!config?.showDetails) return<SimpleView />;
// 第三層：檢查訂單數(shù)據(jù)完整性
if (!order.items || order.items.length === 0) {
return<EmptyOrder />;
}
// 第四層：根據(jù)訂單狀態(tài)渲染
if (order.status === 'completed') {
return<CompletedOrder order={order} />;
}
// 默認：處理中
return<PendingOrder order={order} />;
}
// 讀這段代碼時：
// 1. 快速掃過前置條件檢查
// 2. 每個if塊之后，不需要再維護之前的條件
// 3. 工作記憶只需要追蹤"當前"這一塊的邏輯
// = 每塊只需維護1-2個條件這叫提前返回模式（Early Return）或衛(wèi)語句（Guard Clause）。不是因為它少了代碼行，而是因為每一段代碼的獨立性更高。
實戰(zhàn)改進案例：電商商品詳情頁
// ? Before - 混亂的邏輯
exportfunction ProductDetail({productId, user, inventory, pricing}) {
const [detail, setDetail] = React.useState(null);
const [inCart, setInCart] = React.useState(false);
React.useEffect(() => {
if (productId && user?.id &&
(user.role === 'vip' || !pricing?.locked)) {
fetch(`/api/product/${productId}?vip=${user.role==='vip'}`)
.then(r => r.json())
.then(d => {
if (d && d.id === productId &&
(!inventory || inventory[productId] > 0)) {
setDetail(d);
}
});
}
}, [productId, user?.id, user?.role, pricing?.locked]);
return (
<div>
{!detail ? (
<Spin />
) : user ? (
detail.restricted && user.role !== 'vip' ? (
<Alert message="僅VIP可見" />
) : inCart || detail.inStock ? (
<div>
<h1>{detail.name}</h1>
<Price value={detail.price} />
<Button onClick={() => setInCart(true)}>加入購物車</Button>
</div>
) : (
<Alert message="庫存不足" />
)
) : (
<LoginPrompt />
)}
</div>
);
}問題分析：
- 5層嵌套
- 權(quán)限判斷邏輯分散
- 狀態(tài)管理不清楚
- 副作用中混含太多業(yè)務(wù)邏輯
// ? After - 清晰的流程
exportfunction ProductDetail({
productId,
currentUser,
inventoryMap,
pricingConfig
}) {
// ========== 權(quán)限檢查 ==========
const userCanViewProduct = checkProductAccess(currentUser, pricingConfig);
// ========== 數(shù)據(jù)獲取 ==========
const {
product,
isLoading,
error
} = useProductDetail(productId, userCanViewProduct);
// ========== 庫存檢查 ==========
const isInStock = checkInventory(product?.id, inventoryMap);
// ========== 購物車狀態(tài) ==========
const [isInCart, setIsInCart] = React.useState(false);
// ========== 渲染：前置條件檢查 ==========
if (!currentUser) {
return<LoginPrompt />;
}
if (isLoading) {
return<ProductSkeleton />;
}
if (error) {
return<ErrorAlert message={error} />;
}
if (!product) {
return<NotFoundPage />;
}
// ========== 渲染：權(quán)限檢查 ==========
if (product.restricted && !userCanViewProduct) {
return<RestrictedAlert />;
}
// ========== 渲染：庫存檢查 ==========
if (!isInStock && !isInCart) {
return<OutOfStockAlert />;
}
// ========== 渲染：主內(nèi)容 ==========
return (
<ProductContent
product={product}
isInCart={isInCart}
onAddToCart={() => setIsInCart(true)}
/>
);
}
// ========== 獨立的業(yè)務(wù)邏輯函數(shù) ==========
function checkProductAccess(user, config) {
if (!user) returnfalse;
const isVipUser = user.role === 'vip';
const isNotLocked = !config?.locked;
return isVipUser || isNotLocked;
}
function checkInventory(productId, inventoryMap) {
return inventoryMap?.[productId] > 0;
}
// ========== 數(shù)據(jù)獲取Hook ==========
function useProductDetail(productId, shouldFetch) {
const [product, setProduct] = React.useState(null);
const [isLoading, setIsLoading] = React.useState(false);
const [error, setError] = React.useState(null);
React.useEffect(() => {
if (!shouldFetch || !productId) return;
setIsLoading(true);
fetch(`/api/product/${productId}`)
.then(response => {
if (!response.ok) thrownewError('Failed to fetch');
return response.json();
})
.then(data => {
setProduct(data);
setError(null);
})
.catch(err => {
setError(err.message);
setProduct(null);
})
.finally(() => setIsLoading(false));
}, [productId, shouldFetch]);
return { product, isLoading, error };
}對比：
- Before: 嵌套7層，權(quán)限邏輯混在effect里，狀態(tài)不清楚
- After: 嵌套2層，權(quán)限邏輯獨立，狀態(tài)和副作用分離
四、JSX布局——代碼的視覺設(shè)計
格式塔心理學(xué)的應(yīng)用
人的大腦會自動將空間上靠近的元素視為一個整體。這叫"接近性原則"。
// ? 雜亂 - 大腦需要手動分組
<Form name="user" label="用戶" onChange={onChange}
onBlur={onBlur} value={value} error={error}
required={true} disabled={false} />
// ?? 好一點 - 開始有了分組
<Form
name="user"
label="用戶"
value={value}
onChange={onChange}
onBlur={onBlur}
error={error}
required={true}
disabled={false}
/>
// ? 更好 - 清晰的邏輯分組
<Form
// 身份和標簽
name="user"
label="用戶"
// 值和狀態(tài)
value={value}
error={error}
// 事件處理
onChange={onChange}
onBlur={onBlur}
// UI控制
required={true}
disabled={false}
/>大腦處理第三版本的速度比第一版本快30%（有研究數(shù)據(jù)支持）。
真實場景：訂單表單
// ? 難以理解的排列
export function OrderForm({
orderId, orderDate, customer, email, phone,
items, total, tax, discount, shipping,
paymentMethod, cardNumber, expiryDate, cvv,
notes, coupon, trackingId, onSubmit
}) {
// ...
}
// ? 分組清晰的排列
export function OrderForm({
// 訂單基礎(chǔ)信息
orderId,
orderDate,
// 客戶信息
customer,
email,
phone,
// 訂單項和計費
items,
total,
tax,
discount,
shipping,
// 支付信息
paymentMethod,
cardNumber,
expiryDate,
cvv,
// 元數(shù)據(jù)
notes,
coupon,
trackingId,
// 回調(diào)
onSubmit
}) {
// ...
}第二個版本，新人一眼能看出這個組件涉及多少個"業(yè)務(wù)模塊"。
五、可預(yù)測性——建立隱性契約
什么是隱性契約
隱性契約是：通過代碼風(fēng)格和文檔，讓使用者對組件行為有穩(wěn)定的預(yù)期。
// ? 破壞隱性契約
exportfunction UserAPI() {
return {
getUser: () => {
// 有時返回對象，有時返回null
// 有時同步，有時異步
// 不一致！
}
};
}
// 使用時需要防御
const user = await UserAPI.getUser();
if (user) {
const name = user?.name; // 還要optional chain
}// ? 建立清晰的契約
exportconst UserAPI = {
/**
* 獲取用戶信息
*
* @returns {Promise<User>} 總是返回Promise
* 即使出錯也會reject，而不是返回null
*
* @throws {APIError} 當用戶不存在或網(wǎng)絡(luò)錯誤時
*
* @example
* try {
* const user = await UserAPI.getUser(userId);
* console.log(user.name); // 安全，不需要optional chain
* } catch (error) {
* // 處理錯誤
* }
*/
async getUser(userId: string): Promise<User> {
const response = await fetch(`/api/users/${userId}`);
if (!response.ok) thrownew APIError('User not found');
return response.json();
}
};
// 使用時可以更放心
const user = await UserAPI.getUser(userId); // 類型安全，不會是null
console.log(user.name); // 沒有問題常見的隱性契約破壞
// ? 返回值不一致
function getValue() {
if (condition) return data; // 返回對象
if (error) returnnull; // 返回null
returnundefined; // 返回undefined
}
// 使用時地獄
const val = getValue();
if (val) { /* ... */ } // 但如果val是0或empty string呢？
// ? 建立清晰的返回規(guī)則
function getValue() {
if (condition) return { success: true, data };
return { success: false, error: err, data: null };
}
// 使用時清楚
const result = getValue();
if (result.success) {
console.log(result.data);
}Props的隱性契約
// ? 模糊的props
exportfunction List({
data, // data可以是什么？數(shù)組？對象？null？
onLoad, // 什么時候調(diào)用？成功？失??？
loading // 什么時候為true？
}) {}
// ? 清晰的props定義和文檔
interface ListProps {
/**
* 列表項數(shù)組
* @type {Item[]} 永遠是數(shù)組，即使為空也是 []
* @default []
*/
items: Item[];
/**
* 當列表完成加載后的回調(diào)
* 無論成功還是失敗都會調(diào)用
* @callback
*/
onLoadComplete?: (success: boolean, error?: Error) =>void;
/**
* 是否正在加載
* true: 顯示加載中
* false: 加載完成或未開始
* @type {boolean}
*/
isLoading: boolean;
}
exportfunction List({
items = [],
onLoadComplete,
isLoading = false
}: ListProps) {}六、實戰(zhàn)對比：表單組件的完整改造
Before版本（50行，糟糕的結(jié)構(gòu)）
export function Form({fields, onSubmit, loading, error, initValues, v, cb, cfg}) {
const [formData, setFormData] = React.useState(initValues || {});
const [errs, setErrs] = React.useState({});
const handleChange = (e) => {
const {name, value, type, checked} = e.target;
setFormData({
...formData,
[name]: type === 'checkbox' ? checked : value
});
};
const handleSubmit = async (e) => {
e.preventDefault();
if (v && !v(formData)) {
setErrs(v.errors || {});
return;
}
await onSubmit?.(formData);
};
return (
<form onSubmit={handleSubmit}>
{loading && <Spin />}
{error && <Alert message={error} type="error" />}
{fields?.map((field, i) => (
<div key={i}>
<label>{field.label}</label>
<input
name={field.name}
type={field.type}
value={formData[field.name]}
onChange={handleChange}
{...field.attrs}
/>
{errs[field.name] && <span style={{color: 'red'}}>{errs[field.name]}</span>}
</div>
))}
<button type="submit" disabled={loading}>提交</button>
{cb?.onCancel && <button onClick={cb.onCancel}>取消</button>}
</form>
);
}問題：
- Props 縮寫（v, cb, cfg, errs）
- 邏輯和渲染混一起
- 驗證邏輯不清楚（v是什么？v.errors怎么來的？）
- 沒有TypeScript，無法自動完成
- 修改需求時不知道從哪里下手
After版本（結(jié)構(gòu)清晰，80行）
/**
* 通用表單組件
*
* 特性：
* - 自動處理表單狀態(tài)
* - 集成表單驗證
* - 支持異步提交
* - 清晰的錯誤提示
*/
interface FormField {
name: string;
label: string;
type: 'text' | 'email' | 'password' | 'checkbox' | 'select';
required?: boolean;
placeholder?: string;
options?: Array<{label: string; value: any}>;
}
interface FormProps {
/** 表單字段定義 */
fields: FormField[];
/** 表單初始值 */
initialValues?: Record<string, any>;
/** 提交處理 */
onSubmit: (data: Record<string, any>) =>Promise<void>;
/** 取消處理 */
onCancel?: () =>void;
/** 表單驗證器 */
validator?: (data: Record<string, any>) => ValidationResult;
/** UI配置 */
config?: {
submitButtonText?: string;
submitButtonLoading?: boolean;
};
}
interface ValidationResult {
isValid: boolean;
errors?: Record<string, string>;
}
exportfunction Form({
fields,
initialValues = {},
onSubmit,
onCancel,
validator,
config = {}
}: FormProps) {
// ========== 狀態(tài)管理 ==========
const [formData, setFormData] = React.useState(initialValues);
const [validationErrors, setValidationErrors] = React.useState<Record<string, string>>({});
const [isSubmitting, setIsSubmitting] = React.useState(false);
const [submitError, setSubmitError] = React.useState<string | null>(null);
// ========== 事件處理 ==========
const handleFieldChange = (fieldName: string, value: any) => {
setFormData(prev => ({
...prev,
[fieldName]: value
}));
// 清除該字段的錯誤提示
if (validationErrors[fieldName]) {
setValidationErrors(prev => ({
...prev,
[fieldName]: undefined
}));
}
};
const handleSubmit = async (e: React.FormEvent) => {
e.preventDefault();
setSubmitError(null);
// 第一步：驗證
if (validator) {
const validationResult = validator(formData);
if (!validationResult.isValid) {
setValidationErrors(validationResult.errors || {});
return;
}
}
// 第二步：提交
try {
setIsSubmitting(true);
await onSubmit(formData);
} catch (error) {
setSubmitError(error instanceofError ? error.message : 'Submit failed');
} finally {
setIsSubmitting(false);
}
};
// ========== 渲染：錯誤提示 ==========
if (submitError) {
return<ErrorAlert message={submitError} onDismiss={() => setSubmitError(null)} />;
}
// ========== 渲染：表單 ==========
return (
<form onSubmit={handleSubmit} className="form-container">
{/* 表單字段 */}
<div className="form-fields">
{fields.map(field => (
<FormField
key={field.name}
field={field}
value={formData[field.name]}
error={validationErrors[field.name]}
onChange={(value) => handleFieldChange(field.name, value)}
/>
))}
</div>
{/* 操作按鈕 */}
<div className="form-actions">
<Button
type="primary"
htmlType="submit"
loading={isSubmitting}
disabled={isSubmitting}
>
{config.submitButtonText || '提交'}
</Button>
{onCancel && (
<Button onClick={onCancel}>
取消
</Button>
)}
</div>
</form>
);
}
/**
* 獨立的表單字段組件
* 易于單元測試和復(fù)用
*/
function FormField({
field,
value,
error,
onChange
}: {
field: FormField;
value: any;
error?: string;
onChange: (value: any) => void;
}) {
return (
<div className="form-field">
<label>
{field.label}
{field.required && <span className="required">*</span>}
</label>
{field.type === 'checkbox' ? (
<input
type="checkbox"
checked={value || false}
onChange={(e) => onChange(e.target.checked)}
/>
) : field.type === 'select' ? (
<select value={value || ''} onChange={(e) => onChange(e.target.value)}>
<option value="">選擇...</option>
{field.options?.map(opt => (
<option key={opt.value} value={opt.value}>
{opt.label}
</option>
))}
</select>
) : (
<input
type={field.type}
placeholder={field.placeholder}
value={value || ''}
onChange={(e) => onChange(e.target.value)}
/>
)}
{error && (
<span className="error-message">{error}</span>
)}
</div>
);
}使用示例：
function UserRegistrationForm() {
const handleSubmit = async (data) => {
const response = await fetch('/api/register', {
method: 'POST',
body: JSON.stringify(data)
});
if (!response.ok) thrownewError('Registration failed');
};
const validator = (data) => {
const errors: Record<string, string> = {};
if (!data.email?.includes('@')) {
errors.email = 'Invalid email';
}
if (data.password?.length < 8) {
errors.password = 'Password too short';
}
return {
isValid: Object.keys(errors).length === 0,
errors
};
};
return (
<Form
fields={[
{ name: 'email', label: 'Email', type: 'email', required:true },
{ name: 'password', label: 'Password', type: 'password', required:true },
{ name: 'agree', label: 'Iagreetoterms', type: 'checkbox' }
]}
initialValues={{email: '', password: '', agree:false }}
onSubmit={handleSubmit}
validator={validator}
config={{submitButtonText: '注冊' }}
onCancel={() => window.history.back()}
/>
);
}改進對比：
維度 | Before | After |
總行數(shù) | 50 | 80（但分層明確） |
Props含義清晰度 | 20% | 95% |
可測試性 | 低 | 高 |
改需求時間 | 45分鐘 | 10分鐘 |
新人理解時間 | 30分鐘 | 5分鐘 |
支持新功能的易用度 | 困難 | 簡單 |
TypeScript支持 | 無 | 完整 |
七、為什么"聰明的代碼"是毒藥
一行代碼的真實成本
// ? 聰明，但危險
const isEligible = !!(user?.isAdmin || user?.permissions?.includes('edit') ||
(department?.lead === user?.id && !user?.archived));
// 一年后，某個凌晨3點的修復(fù)現(xiàn)場：
// "這行代碼到底在判斷什么？"
// "為什么要加 !! ？"
// "three條件的優(yōu)先級對嗎？"
// "這里漏掉了什么條件嗎？"vs
// 冗長，但清晰
const isAdmin = user?.isAdmin === true;
const canEdit = user?.permissions?.includes('edit') === true;
const isDepartmentLead = (
department?.lead === user?.id &&
user?.archived !== true
);
const isEligible = isAdmin || canEdit || isDepartmentLead;
// 任何人都能快速理解：
// 1. 這三個變量分別判斷什么權(quán)限
// 2. 最終結(jié)果是"任何一個權(quán)限都可以"可讀性成本：
- 聰明版本：第一次寫 = 5分鐘
- 清晰版本：第一次寫 = 8分鐘
維護成本：
- 聰明版本：每次看 = 2分鐘（思考、猜測、驗證）
- 清晰版本：每次看 = 15秒（直接理解）
五年內(nèi)：
- 代碼被看 = 至少 1000 次
- 聰明版本：1000 × 2分鐘 = 2000分鐘 ≈ 33小時
- 清晰版本：1000 × 15秒 = 250分鐘 ≈ 4小時
節(jié)省 = 29小時 = 近4個工作日
八、團隊實施建議
第一步：建立認知
在團隊周會上講這個話題：
- 展示"糟糕命名vs清晰命名"的對比
- 統(tǒng)計過去bug中，有多少是因為代碼不清楚引起的
- 說出真實成本：code review時間 × 人數(shù) × 迭代次數(shù)
第二步：制定規(guī)范
為團隊建立簡單的檢查清單：
Code Review 檢查清單
===================
□ Props 名字是否清晰？能否看名字就知道含義？
□ 嵌套層數(shù) ≤ 3 層？
□ 復(fù)雜邏輯是否提取到獨立函數(shù)？
□ 返回值是否一致且可預(yù)測？
□ 是否有必要的類型定義？
□ 狀態(tài)是否按邏輯分組？
□ 錯誤處理是否明確？第三步：漸進式改進
不要一下子改所有代碼，而是：
- 新代碼嚴格按規(guī)范
- 每次修改時順便改進相關(guān)的舊代碼
- 定期重構(gòu)容易出bug的組件
總結(jié)
React的性能優(yōu)化（虛擬DOM、memo、useMemo）已經(jīng)做得很好了。
但代碼的可理解性往往被忽視，而這正是最容易積累技術(shù)債的地方。
一個簡單但深刻的事實：
開發(fā)者閱讀你的代碼的總時間，遠遠超過機器執(zhí)行你的代碼的時間。
所以問問自己：我是在為機器優(yōu)化，還是為人優(yōu)化？
好的答案是：同時為兩者優(yōu)化，但優(yōu)先考慮人。
責(zé)任編輯：武曉燕
來源：
前端達人
