每個(gè)前端開發(fā)人員都應(yīng)該了解的軟件工程原理
作為前端開發(fā)人員,我們常常專注于創(chuàng)建漂亮的用戶界面。然而,我們必須牢記,美也在于內(nèi)在,完美像素的方法也應(yīng)轉(zhuǎn)化為我們的代碼組織和結(jié)構(gòu)。在本文中,我們將探討一些基本的軟件工程原則,每個(gè)前端開發(fā)人員都應(yīng)該了解并在自己的項(xiàng)目中應(yīng)用這些原則。
1. DRY(不要重復(fù))
DRY 原則強(qiáng)調(diào)代碼可重用性和維護(hù)的重要性。通過將通用功能提取到可重用組件、函數(shù)或模塊中來避免重復(fù)代碼。通過堅(jiān)持 DRY 原則,您可以減少代碼重復(fù),提高可維護(hù)性,并使您的代碼庫(kù)更加模塊化。React 鼓勵(lì)組件驅(qū)動(dòng)的架構(gòu),其中職責(zé)被隔離,以便于未來的開發(fā)和可擴(kuò)展性。
讓我們以一個(gè)簡(jiǎn)單的電子商務(wù)應(yīng)用程序的產(chǎn)品頁(yè)面為例。我們希望看到一個(gè)待售產(chǎn)品列表。我們可以將頁(yè)面分解成更小的、可重復(fù)使用的組件。
組件:
- ProductCard:顯示單個(gè)產(chǎn)品及其名稱、價(jià)格和描述。
- ProductList:顯示產(chǎn)品列表。
// ProductCard.js
import React from 'react';
const ProductCard = ({ product }) => {
return (
<div>
<h2>{product.name}</h2>
<p>Price: ${product.price}</p>
<p>Description: {product.description}</p>
</div>
);
};
export default ProductCard;
// ProductList.js
import React, { useState } from 'react';
import ProductCard from './ProductCard';
const ProductList = () => {
const [products, setProducts] = useState([
{ id: 1, name: 'Product 1', price: 9.99, description: 'Description 1' },
{ id: 2, name: 'Product 2', price: 19.99, description: 'Description 2' },
// ...
]);
return (
<div>
{products.map((product) => (
<ProductCard key={product.id} product={product} />
))}
</div>
);
};
export default ProductList;
在這個(gè)示例中,我們可以看到,通過將有關(guān)產(chǎn)品的邏輯分離到 ProductCard 組件中,我們可以在 ProductList 組件的 map 功能中重復(fù)使用這些邏輯,從而避免為列表頁(yè)面中的每個(gè)產(chǎn)品項(xiàng)目重復(fù)編寫代碼。
2. SOLID 原則
SOLID 是一個(gè)縮寫詞,代表面向?qū)ο笤O(shè)計(jì)的五個(gè)關(guān)鍵原則:
- 單一職責(zé)原則(SRP):每個(gè)模塊或類應(yīng)該只有一個(gè)更改的理由。
- 開放/封閉原則(OCP):軟件實(shí)體應(yīng)該對(duì)擴(kuò)展開放,對(duì)修改關(guān)閉。
- 里氏替換原則(LSP):子類型應(yīng)該可以替換其基本類型,而不改變程序的正確性。
- 接口隔離原則 (ISP):不應(yīng)強(qiáng)迫客戶端依賴于他們不使用的接口。
- 依賴倒置原則(DIP):高層模塊不應(yīng)該依賴于低層模塊。兩者都應(yīng)該依賴于抽象。
讓我們看一下如何在 React TypeScript 組件中應(yīng)用里氏替換原則 (LSP):
// Vehicle.ts
interface Vehicle {
drive(): void;
name: string;
}
// Car.ts
class Car implements Vehicle {
constructor(private name: string) {
this.name = name;
}
drive(): void {
console.log(`Driving a ${this.name}`);
}
}
// Motorcycle.ts
class Motorcycle implements Vehicle {
constructor(private name: string) {
this.name = name;
}
drive(): void {
console.log(`Riding a ${this.name}`);
}
}
// App.tsx
import React from 'react';
import { Vehicle } from './Vehicle';
import Car from './Car';
import Motorcycle from './Motorcycle';
function VehicleComponent(props: { vehicle: Vehicle }) {
props.vehicle.drive();
return <div>Driving a {props.vehicle.name}</div>;
}
const App = () => {
const car = new Car();
const motorcycle = new Motorcycle();
return (
<div>
<VehicleComponent vehicle={car} />
<VehicleComponent vehicle={motorcycle} />
</div>
);
};
export default App;
在此示例中,我們有一個(gè)定義 name 屬性和 drive 方法的 Vehicle 接口。然后我們有兩個(gè)具體的實(shí)現(xiàn):Car 和 Motorcycle ,它們都實(shí)現(xiàn) Vehicle 接口。
在 App 組件中,我們創(chuàng)建 Car 和 Motorcycle 的實(shí)例并將它們傳遞給 VehicleComponent。VehicleComponent 在傳入的車輛對(duì)象上調(diào)用驅(qū)動(dòng)方法。
LSP 確保我們可以用 Car 或 Motorcycle 替換 Vehicle 接口,而不會(huì)改變程序的正確性。VehicleComponent 與 Car 和 Motorcycle 實(shí)例無(wú)縫協(xié)作,展示了子類型對(duì)其基本類型的可替換性。
3. KISS(保持簡(jiǎn)單,笨)
KISS 原則提倡設(shè)計(jì)和實(shí)現(xiàn)的簡(jiǎn)單性。編寫易于理解、簡(jiǎn)單且能做好一件事的代碼。避免不必要的復(fù)雜性和過度設(shè)計(jì),因?yàn)閺拈L(zhǎng)遠(yuǎn)來看,這可能會(huì)導(dǎo)致混亂和維護(hù)挑戰(zhàn)。
讓我們看一下 Counter 組件的 2 個(gè)實(shí)現(xiàn)。
// Complex Counter
import React, { useState, useEffect } from 'react';
import { debounce } from 'lodash';
const ComplexCounter = () => {
const [count, setCount] = useState(0);
const [clicked, setClicked] = useState(false);
const [error, setError] = useState(null);
useEffect(() => {
if (clicked) {
setCount(prev => prev + 1)
setClicked(false)
}
}, [clicked, setClicked]);
const handleClick = (clicked: boolean) => {
setClicked(!clicked);
};
return (
<div>
<p>Count: {count}</p>
<button onClick={() => handleClick(clicked)}>Increment</button>
</div>
);
};
export default ComplexCounter;
// Simple Counter
import React, { useState } from 'react';
const SimpleCounter = () => {
const [count, setCount] = useState(0);
const handleClick = () => {
setCount(count + 1);
};
return (
<div>
<p>Count: {count}</p>
<button onClick={handleClick}>Increment</button>
</div>
);
};
export default SimpleCounter;
我們看到,ComplexCounter 的實(shí)現(xiàn)更難理解和維護(hù),也更容易出錯(cuò)。
它為 clicked 和 useEffect 鉤子引入了不必要的狀態(tài)變量。
這是一個(gè)如何不實(shí)現(xiàn) React 組件的示例。
4. YAGNI(你不需要它)
YAGNI 提醒我們避免基于推測(cè)的未來需求過早地添加功能。相反,應(yīng)專注于正確實(shí)現(xiàn)當(dāng)前所需的功能。當(dāng)您構(gòu)建一個(gè)非常以用戶為中心的產(chǎn)品時(shí),這一點(diǎn)變得非常重要。最好不要根據(jù)您認(rèn)為用戶可能想要的假設(shè)來引入新功能。使用適當(dāng)?shù)挠脩粞芯靠蚣芎驮驮O(shè)計(jì)方法。
通過遵循 YAGNI,您可以防止不必要的復(fù)雜性、減少開發(fā)時(shí)間并維護(hù)精簡(jiǎn)的代碼庫(kù)。
5. 干凈的代碼
干凈的代碼是可讀的、可理解的、可維護(hù)的。遵循編碼約定和最佳實(shí)踐,使用有意義的變量名稱,并編寫不言自明的代碼。保持函數(shù)和類小而集中,堅(jiān)持一致的格式,并努力使代碼庫(kù)清晰。
讓我們看一個(gè)簡(jiǎn)單的實(shí)用函數(shù),用于出于數(shù)據(jù)安全目的隱藏部分用戶的私人信息。
const hashUsersPrivateInformation = (privateInformation: string): string => {
// 計(jì)算私人信息的長(zhǎng)度,以確定需要屏蔽多少個(gè)字符
const maxLength = privateInformation.length > 4 ? privateInformation.length - 4 : privateInformation.length;
// 創(chuàng)建正則表達(dá)式模式,以匹配所需的字符數(shù)
const regexPattern = `.{1,${maxLength}}`;
const regex = new RegExp(regexPattern);
return privateInformation.replace(regex, (match) => '*'.repeat(match.length));
};
我們看到:
- 函數(shù)的名稱是自我描述的
- 它包含可以幫助其他開發(fā)人員的有用注釋。
- 它有一個(gè)可以理解的主要目的。
我們應(yīng)該以類似的方式構(gòu)建我們的代碼。
結(jié)論
將這些軟件工程原理融入您的前端開發(fā)工作流程中,您可以編寫質(zhì)量更高的代碼,改善與團(tuán)隊(duì)成員的協(xié)作,并構(gòu)建強(qiáng)大且可擴(kuò)展的應(yīng)用程序。軟件工程不僅僅是編寫代碼;還涉及編寫代碼。它是為復(fù)雜問題創(chuàng)建可靠、可維護(hù)且優(yōu)雅的解決方案。
原文:https://dev.to/gboladetrue/software-engineering-principles-every-frontend-developer-should-know-1ej7?ref=dailydev