嗨~ 歡迎閱讀 ExplainThis 全端開發雙週報。在開始之前,想先跟讀者們分享,ExplainThis 籌劃的 E+ 這週剛結束《Google 的軟體工程之道》直播工作坊。
《Google 的軟體工程之道》是 2020 年時,多位 Google 的資深主任工程師合寫的書,詳細地介紹了 Google 內部的軟體工程制度、規範、工具,以及軟體工程文化。這本書的原文電子版是免費的 (連結)
而這次 E+ 的直播,我們邀請到在美商資安獨角獸公司擔任資深全端工程師的 John 與大家分享重點摘要。John 寫的 《Google 的軟體工程之道》心得,是目前 Google 搜尋排行的第一篇,有興趣看直播回放的讀者,歡迎加入 E+
E+ 的詳細介紹可以看這邊 https://www.explainthis.io/zh-hant/e-plus
[前端] 寫程式時該用三元運算子 (ternary operator) 嗎?
前陣子看到一個在討論三元運算子 (ternary operator) 的討論串,覺得蠻有趣的。因此在這期雙週報,來跟大家談這個運算子。以前端開發來說,JavaScript 的三元運算子是蠻常用到的,但社群的人對使用三元運算子有不同的觀點。
先來看看 MDN 上怎麼定義三元運算子,MDN 的定義是「運算子 是 JavaScript 唯一用到三個運算元的運算子:在一個條件後面會跟著一個問號 (?
),如果條件是 truthy,在冒號(:
)前的表達式會被執行,如果條件是 falsy ,在冒號後面的表達式會被執行,這個運算子常常被用來當作 if
的簡潔寫法」。
舉個具體的例子,如果今天有一個 getFee
函式,會根據是不是會員,來回傳不同的價格。如果是會員,則需要 $2 塊錢,不是會員則需要 $10 塊錢。我們可以簡單地寫成
function getFee(isMember) {
if (isMember) {
return '$2.00';
} else {
return '$10.00';
}
}
如果用三元運算子,則可以變成這樣,原本四行的程式碼,被一行簡化。
function getFee(isMember) {
return isMember ? '$2.00' : '$10.00';
}
雖說上面的例子,三元運算子看起來比較簡潔,但在一些不同的情況下,三元運算子反而會讓可讀性變差,這也是為什麼 ESLint 當中甚至有條 no-nested-ternary
,禁止下面這種看過去讓人沒辦法一眼看懂的程式碼
foo ? baz === qux ? quxx() : foobar() : bar();
三元運算子究竟好不好用,其實很主觀。舉例來說,有人認為三元運算子會比用 &&
來的好,舉例來說,下面這種狀況,是在寫前端 JSX 元件很常會出現的問題,因為 members.length
如果是 0
的話, 0 && 某個東西
結果會直接渲染 0
<div>
{members.length &&
members.map((member) => (
<div key={member.id}> {member.name} </div>
))
}
</div>
因此有些人會認為,這時候用三元運算子比較好 (例如下面這樣)。但有人則認為三元運算子的可讀性會比較差,所以認為與其用三元運算子,不如確定 &&
前面會是布林值,例如檢查 members.length > 0
而不是檢查 members.length
<div>
{members.length ? members.map((member) => (
<div key={member.id}> {member.name} </div>
)) : null}
</div>
另外則有人說,與其用三元運算子,不如把這個抽成元件,然後在元件中引用,這樣的可讀性又更高一點。
function MemberList({ members }: MemberListProps) {
if (members.length === 0) {
return null;
}
return (
<div>
{members.map((member) => (
<div key={member.id}> {member.name} </div>
))}
</div>
);
}
不只在 JavaScript 中,三元運算子有爭議;在其他的程式語言中,三元運算子也有被大量討論過。JavaScript 的三元運算子語法是跟 C 比較類似的,是由 ?
與 :
所組成。
然而這種設計,有時看起來過於抽象,難以讓人一眼看懂,所以在其他的語言中,會看到不同的設計方式。舉例來說,Python 是把 if...else
直接化為一行的形式 '$2.00' if isMember else '$10.00'
。而 Go 語言則直接表示,因為三元運算子容易造成難以閱讀的程式碼,所以決定不支援這種語法。
總的來說,程式碼是種表達與溝通的工具,三元運算子雖然在某些狀況比較簡潔,但確實有時反而會導致程式碼比較難閱讀。回過頭來說,一個工具的使用,還是端看使用的人怎麼用;不要教條式的認為三元運算子比較簡潔,或者比較難閱讀,而是要看情況,在適合的情況使用,達到最好的效果。
[本期推薦]
過去一週因為 React Conf,社群中針對 React 19 將要有的更新,有廣泛的討論。其中一個更新是 React 提供了
use
這個函式。《How does use() work internally in React?》一文拆解了這個函式是如何運作的 (連結)最近 SolidStart 推出正式 1.0 版本,其中有特別感謝因為 Vite,讓 SolidStart 的開發上能省去很多時間 (連結)。《Visual Guide to the Modern Frontend Toolchain (Vite)》講解了 Vite 是如何運作的? (連結)
《How URLs work?》是一個介紹 URL 組成的網站,URL 組成牽涉到的概念 (例如 same site 或 same origin) 是面試蠻常見的題目。不熟的人推薦逛逛這網站 (連結)
在系統設計中有許多「高頻率會用上」的要件,而 Redis 是其中之一。《系統設計高頻率元件之 Redis》介紹了 Redis 與常見的使用場景 (連結)
近幾年前端界,有個叫「微前端」的架構模式越來越流行。然而,什麼是微前端? 前端前面加的這個「微」代表什麼? 這種架構方式有什麼好處? 又有什麼潛在問題? 在《為什麼要用微前端架構》一文有相關說明 (連結)
前幾天看到 Uber 的首席招募員 Samantha Shulman 在 LinkedIn 上面分享一個面試準備要訣,在面試前花 15 分鐘做三件事,讓你在面試官心中留下深刻印象,非常推薦要準備面試的人,可以參考這三件準備 (連結)
最近 ExplainThis 更新了先前寫的《科技業找人幫忙內推要注意的事》一文,如果你找工作時要找人內推,推薦一讀 (連結)