「為什麼我們不應該慶祝美麗的程式碼」
我們都看過它——程式碼的結構如此複雜和原始，以至於它屬於博物館，而不是儲存庫。這是一種你會敬畏地盯著看一會兒的程式碼……直到你意識到你需要調試它。然後，就像我們其他凡人一樣，您會想知道為什麼有人決定寫 JavaScript，就像他們正在寫下偉大的美國小說一樣。
讓我們明白一點：漂亮的程式碼只有有用才算漂亮。如果您的團隊需要博士學位。用深奧的語法來弄清楚一個功能是如何運作的，恭喜你——你已經創造了一件無人能維護的傑作。
這就是為什麼你應該抵制創建過於聰明的程式碼的衝動以及該怎麼做。係好安全帶；例子即將到來。
過度設計的優雅的魅力
首先，讓我們來看看開發者為什麼要寫這種程式碼。
範例 1：「WTF」工廠函數
這是我最近偶然發現的寶石：
const createMultiplier = (x) => (y) => (z) => x * y * z; const multiply = createMultiplier(2)(3); console.log(multiply(4)); // Outputs 24
漂亮嗎？當然。但祝初級開發者好運，他們必須弄清楚這裡發生了什麼事。三層函數來乘三個數字？恭喜你，你已經把算術變成奧運項目了。
不要這樣做。這是為人類編寫的相同功能：
function multiplyThreeNumbers(x, y, z) {
return x * y * z;
}
console.log(multiplyThreeNumbers(2, 3, 4)); // Outputs 24
可讀。簡單的。維持大家的理智。
例 2：莎士比亞的承諾鏈
現在讓我們來談談看起來像是莎士比亞代寫的承諾鏈：
fetch(url)
.then((response) => response.json())
.then((data) =>
data.map((item) =>
item.isActive
? { ...item, status: "active" }
: { ...item, status: "inactive" }
)
)
.then((updatedData) =>
updatedData.reduce(
(acc, curr) =>
curr.status === "active"
? { ...acc, active: [...acc.active, curr] }
: { ...acc, inactive: [...acc.inactive, curr] },
{ active: [], inactive: [] }
)
)
.then((finalResult) => console.log(finalResult))
.catch((error) => console.error(error));
這段程式碼有效。但這也是對任何必須維護它的人的犯罪。為什麼資料轉換的每一步都像俄羅斯娃娃一樣嵌套在下一個步驟中？
讓我們重構一下：
async function processData(url) {
try {
const response = await fetch(url);
const data = await response.json();
const updatedData = data.map((item) => ({
...item,
status: item.isActive ? "active" : "inactive",
}));
const finalResult = updatedData.reduce(
(acc, curr) => {
if (curr.status === "active") {
acc.active.push(curr);
} else {
acc.inactive.push(curr);
}
return acc;
},
{ active: [], inactive: [] }
);
console.log(finalResult);
} catch (error) {
console.error(error);
}
}
processData(url);
將邏輯分解為步驟使程式碼可讀。它仍然在做同樣的事情，但現在每個階段發生的事情都很清楚。
為什麼簡單更好
說到軟體，請記住這條黃金法則：你的程式碼不是個人日記。它是一種溝通工具。如果您的團隊無法閱讀它，他們就無法使用它。如果他們無法與之合作，業務就無法前進。
這就是簡單獲勝的原因：
1 更快的入門：初級開發人員不需要 Rosetta Stone 來理解您的程式碼。
2 更輕鬆的調試：當錯誤出現時（它們一定會出現），清晰的邏輯使它們更容易找出來。
3 個更快樂的團隊：沒有人喜歡感到愚蠢。過於聰明的程式碼會疏遠你的隊友。
外帶
寫程式就像在經歷了一夜的艱難睡眠後向未來的自己解釋一樣。善待下一個必須閱讀您作品的開發人員 - 因為很有可能，那個開發人員就是您。
美麗的程式碼並不在於它看起來有多花哨，而在於它的外觀。這是關於它如何有效地解決問題。任何少的東西都只是虛榮心的表現。
以上是屬於博物館而不是儲存庫的程式碼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
