Js程式碼整潔之道
一、前言
最近在做一些專案重構的工作,看了不少髒亂差的程式碼,身心疲憊。本文將討論如何編寫整潔的程式碼,不求高效執行,只求可讀性強,便於維護。
二、為什麼要寫簡潔的程式碼
作為一個合格的程式設計師,寫出簡潔的程式碼是基本的職業素養。相信絕大部分的程式設計師都不會故意寫噁心程式碼的,無論是對自己或者對別人都沒有任何好處。那麼,是什麼阻礙我們寫出優秀程式碼呢?有下面這麼幾種可能性:
- 時間緊任務重,沒那麼多時間考慮程式碼設計
- 偷懶圖方便,不過腦子機械式的寫程式碼
- 注意力只集中在功能的實現,不考慮後期的維護成本
- 知識儲備不夠,不知道怎樣寫出優雅的程式碼
出來混遲早要還的,無論是上述哪種原因,混亂程式碼一旦被寫出來,程式碼作者肯定是要為其買單的,只是買單的方式會各有不同。可能是後期維護的時候邊改邊抽自己,也可能是別人改程式碼的時候邊改邊罵你傻x。
那麼,程式碼寫好了會有什麼好處呢?起碼有以下幾方面:
- 後期維護更高效,無論是改 bug 還是新增功能,無論是自己改還是別人改
- 後期更少的加班
- 思考如何編寫整潔程式碼的過程中,技術能力會隨之提高
- 寫出優雅的程式碼,會更有成就感,更熱愛自己的工作
- 別人看到這麼優雅的程式碼,會讚不絕口,個人影響力會放大
既然有這麼多好處,那到底怎麼評判程式碼寫得好不好呢?是自己覺得好就是好嗎?顯然不是。程式碼寫得是否整潔是客觀的,是 code review 的人或後期維護的人覺得好才是真的好。所以加強 code review 也是倒逼寫出優秀程式碼的一種方式。
個人認為程式碼的優秀程度分以下幾個層次:
- 程式能正常執行
- 異常情況有應對方法
- 簡單明瞭,易於後期維護
- 團隊成員間能高效協作
- 能高效能執行
層次越高,難度越大,挑戰越大。作為一個有追求的程式設計師,我們應該不斷突破自己的邊界,追求卓越,更上一層樓。
三、程式碼設計原則
要想寫出優雅整潔的程式碼,就要遵循特定的設計原則。透徹理解這些原則後,還要結合具體的專案落地,不斷的練習和重構。下面總結出的一些通用原則供參考。
KISS(keep it simple, stupid)
業務邏輯要直截了當,不要引入各種依賴,多層次呼叫。以react為例,常見的錯誤是將props在state裡存一份,計算的時候再從state中取。這樣帶來的問題是要時刻監聽props的變化,然後再同步到state中。這完全是多此一舉,直接用props進行計算即可。
// bad
componentWillReceiveProps(nextProps) {
this.setState({num: nextProps.num});
}
render() {
return(
<div>{this.state.num * 2}</div>
);
}
/***************************/
// good
render() {
return(
<div>{this.props.num * 2}</div>
);
}
DRY (don’t repeat yourself)
不用做機械式的複製貼上,要鍛鍊自己抽象的能力,儘量將通用的邏輯抽象出來,方便日後重用。
Open/Closed (open to extension but closed to modification)
程式碼要對擴充套件開放,對修改封閉。儘量做到在不修改原有程式碼的基礎上,增加新的功能。react的容器元件和展示元件分離用的就是這種思想。當資料來源不同的時候,只需要修改或新增容器元件,展示元件維持不變。
function Comp() {
...
}
class ContainerComp extends PureComponent {
async componentDidMount() {
const data = await fetchData();
this.setState({data});
}
render() {
return (<Comp data={this.state.data}/>);
}
}
從架構層面說,微核心架構也是遵循這一設計原則。它能保證核心模組不變的情況下,通過外掛機制為系統賦予新的能力。我們常用的webpack就是一個很好的例子,它通過引入 loader 和 plugin 的機制,極大的擴充套件了其檔案處理的能力。
Composition > Inheritance
首先說一下類這個概念。本質上來說,定義類就是為了程式碼的複用,對於需要同時建立多個物件例項的情況下,這種設計模式是非常有效的。比如說連線池中就需要同時存在多個連線物件,方便資源複用。而對於前端來說,絕大部分的業務場景都是單例,這種情況下通過定義工具函式,或者直接使用物件字面量會更加高效。工具函式儘量使用純函式,使程式碼更易於理解,不用考慮副作用。這裡說的僅限於業務程式碼的範疇,如果是框架型的專案,場景會複雜得多,類會更有用武之地。
既然類都不需要用了,繼承就更無從談起了。繼承的問題是多級繼承之後,定位問題會非常困難,要一級一級往上找才能找到錯誤出處。而組合就沒有這種問題,因為多個功能都是平級的,哪裡出問題一眼就能看出來。比較一下下面 2 種風格的程式碼:
繼承的寫法:
class Parent extends PureComponent {
componentDidMount() {
this.fetchData(this.url);
}
fetchData(url) {
...
}
render() {
const data = this.calcData();
return (
<div>{data}</data>
);
}
}
class Child extends Parent {
constructor(props) {
super(props);
this.url = 'http://api';
}
calcData() {
...
}
}
組合的寫法:
class Parent extends PureComponent {
componentDidMount() {
this.fetchData(this.props.url);
}
fetchData(url) {
...
}
render() {
const data = this.props.calcData(this.state);
return (
<div>{data}</data>
);
}
}
class Child extends PureComponent {
calcData(state) {
...
}
render() {
<Parent url="http://api" calcData={this.calcData}/>
}
}
哪種更易於理解呢?
Single Responsibility
遵循單一職責的程式碼如果設計得好,組合起來的程式碼就會非常的清爽。舉一個註冊的場景,可以劃分為下面幾個職責:
- UI 展示
- 輸入合法性判斷
- 網路請求
- 聚合層
虛擬碼如下:
// UI.js
export default function UI() {
...
}
// api.js
export function regist(name, email) {
...
}
// validate.js
export function validateName(name) {
...
}
export function validateEmail(email) {
...
}
// Regist.js
export default class Regist extends PureComponent {
...
onSubmit = async () => {
const {name, email} = this.state;
if (validateName(name) && validateEmail(email)) {
const resp = await regist(name, email);
...
}
}
render() {
<UI onSubmit={onSubmit}>
}
}
可以看到聚合層的程式碼非常簡潔,哪裡出問題了就到相應的地方改就好了,即使是多人協作,也不容易出問題。
Separation of Concerns
關注點分離原則跟單一職責原則有點類似,但更強調的是系統架構層面的設計。典型的例子就是 MVC 模式,Model、View、Control 三層之間都有明確的職責劃分,做到了高內聚低耦合。
React 的原始碼設計也是基於這一原則,分為ReactElement, ReactCompositeComponent 和 ReactDomComponent 三層。ReactElement 負責描述頁面的 DOM 結構,也就是著名的 Virtual DOM;ReactCompositeComponent 處理的是元件生命週期、元件 Diff 和更新等邏輯;而ReactDomComponent是真正進行 DOM 操作的類。三層之間分工明確,緊密協作,共同組成了一個強大的前端框架。
Clean Code > Clever Code
提倡簡潔易懂的程式碼,而不是晦澀難懂的“聰明”程式碼,如下面這種:
leta, b=3, t = (a=2, b<1) ? (console.log('Y'),'yes') : (console.log('N'),'no');
單一程式碼檔案不超過 200 行
檔案一旦超過 200 行,說明邏輯已經有點複雜了,要想辦法抽離出一些純函式工具方法,讓主線邏輯更加清晰。工具方法可以放在另外的檔案裡面,減少讀程式碼的心理壓力。有一點需要說明一下,並不是所有的檔案都不能超過 200 行,像工具方法這種,都是各自獨立的邏輯,寫多少行都無所謂。需要控制的是緊密關聯的業務程式碼的行數。
廣州VI設計公司https://www.houdianzi.com
四、前端程式碼如何拆分
上面提到要合理的拆分程式碼,那到底怎麼拆呢?對於前端元件程式碼,有下面一些拆分點以供參考:
- UI
- 展現邏輯
- 事件處理
- 業務邏輯
- 網路請求
- 配置類純JSON物件
- 工具類純函式
需要說明的是展現邏輯和業務邏輯是兩回事,最好不要混在一起寫。比如元件的顯示隱藏是展現邏輯,而資料的校驗就是業務邏輯。
五、總結
本文討論了書寫整潔程式碼的必要性和重要性,結合例項列出了一些設計原則,還給出了元件程式碼拆分的方式。程式設計師的職業生涯是一個自我修煉的過程,時刻關注程式碼質量,是提高技術水平的重要一環。