🔧 阿川の電商水電行
我從事軟體開發十多年了，我學到的最重要的一課來自職業生涯早期的一次談話。我告訴一位同事——一位才華橫溢的工程師——“你知道嗎，我們應用程式裡的程式碼有點糟糕。”
他微微一笑，像山上的老僧一樣點了點頭，說：
“到處都糟透了。”
說實話？
我從事這個行業的時間越長，就越發意識到這句話有多麼不可思議地真實。每個公司、每個團隊、每個專案——無論大小——最終都會形成自己獨特的混亂局面。然而，我們卻一直假裝在某個地方，也許是在谷歌，也許是在Netflix，也許是在某個神秘的北歐新創公司…有人在寫完美無瑕的程式碼。
劇透：他們不是🙃
這樣挺好。真的。
✨ 究竟什麼是「整潔程式碼」？ （老實說…沒有人能給出統一的定義）
這些年來，我聽過無數種定義。 「易讀的」、「簡潔的」、「一致的」、「可靠的」、「優雅的」、「如果我有更多時間、更少的截止日期，我會怎麼寫」。
一切都憑感覺。沒人能在任何事情上達成共識。
問十個開發者「整潔程式碼」是什麼意思，你會得到二十七個不同的答案。整潔程式碼其實不是一種標準，而是一種感覺。它是一種平靜的時刻，你的大腦會想：“好吧，至少這部分程式碼三個月後不會再困擾我了。”
一個普遍適用的定義？
嗯……找到的話告訴我一聲😌
🚧 真正的專案並非從零開始。
他們一開始就施加壓力。
經理們想要「在螢幕上」看到一些東西。
具備概念驗證能力。
有截止日期。
低年級的隊員們都在盡力而為。
凌晨兩點寫的程式碼，而那次衝刺本就不應該存在。
程式碼庫一開始並不混亂。
它們起初很脆弱——但現實會瞬間擊垮它們。
🔥 意外成為生產人員的有色人種
這玩意兒堪稱傳奇。當初幾個低年級的學生匆匆做了個原型，本來設計壽命不超過一周，基本上就是用膠帶黏起來的，還帶點兒感情。
這時，一位經理突然闖了進來，說道：“我們只需要再做一件事——加一個簡單的圖表，這樣我們就能拿下這份合約了！”
圖表是被駭客篡改的。
合約已簽訂。
概念驗證產品直接就投入生產了😭
開發人員花了數年時間修復這方面的漏洞。每個人都說“我們會盡快重構”，但總是有更重要的事情發生。這就是遺留問題的由來──不是因為開發人員水準差，而是因為一些成功的權宜之計。
⛏️ 五年重構計畫（目前仍「接近完成」）
還有一次，一個團隊開始重構一個大型模組。
負責任地。謹慎地。一步一步地。
一年過去了。
然後又一個。
還有一個。
過了一會兒，我碰到了經理，她自豪地說：“我們快要完成那個模組的重構了！”
幾乎。
五年後。
重構工作尚未結束。
它慢慢地變成了民間傳說。
🎻 完美主義高年級學生意外創造出義大利麵
我曾經和一位資深後端開發人員共事，他才華洋溢。他的程式碼審查就像寫論文一樣嚴謹。他會分析那些沒人問過的邊緣情況。他重寫變數名就像在編輯小說一樣。
然而……不知何故，申請卻以失敗告終。
到處都是洞。
前後矛盾。
不穩定。
為什麼？因為人們害怕向他提問。沒人想讓他審閱自己的公關稿。沒人想碰「他的程式碼」。
當開發者感到害怕時，他們不會改進問題，而是會悄悄地、秘密地、小心翼翼地繞過問題。
沒有什麼比義大利麵在寂靜中生長得更快了🍝
完美主義並不能創造出簡潔的程式碼。
完美主義會滋生恐懼。
恐懼會造成混亂。
😂 神奇的[enableSpecialMode]="true"功能本來就不該存在
好吧，這張照片是很久以前的了——但它仍然是我最喜歡的照片之一。
出現了一個漏洞。
修復這個問題又導致了另一個bug。
管理層之間就應該先解決哪些問題展開了激烈的政治博弈。
截止日期迫在眉睫。
最快、最安全的解決方法——而且不會損壞其他任何東西——就是把這個小玩意兒裝進一個元件裡：
[enableSpecialMode]="true"最搞笑的部分是什麼？
沒有「特殊模式」。
它並不存在。
這個名字是假的。
但是，嘿——它奏效了。問題立刻就解決了。
我們都答應過「以後」再重構。我們也都知道「以後」就等於「永遠不會」。結果不出所料——沒人重構過它😂
駭客的壽命比大多數工程師都長。
🤖 AI：你見過的最乾淨俐落的混亂
現在我們有了人工智慧。
人工智慧編寫的程式碼簡潔美觀。它格式優美、前後一致、整齊清晰、易於閱讀…
底部完全脫臼。
人工智慧樂於引入新的依賴項，只解決表面症狀而非根本原因，無視架構，並產生無人能懂的邏輯。這就像你有一個速度極快、自信滿滿的初級程式設計師，他從不問“為什麼”，卻能在三秒鐘內產生 300 行優美卻毫無意義的程式碼。 ✨
遺產的未來是機器生成的——而且是精心設計的。
📊 商業模式 vs 簡潔程式碼：一場簡潔程式碼永遠敗北的戰鬥
開發者需要穩定性、清晰度、可維護性和結構性。
企業需要的是速度、功能、截止日期和演示。
不是因為生意不好，而是因為生意就是這樣運作的。
簡潔的程式碼太棒了。
但簡潔的程式碼並不能贏得訂單。
簡潔的程式碼並不能打動投資人。
簡潔的程式碼並不能神奇地戰勝競爭對手。
Excel 總是贏家。
🤔 所以……寫整潔程式碼真的值得嗎？
是的。
當然，沒錯。
但不是書中所描繪的那種神話般的版本。不是那種聖杯般完美、閃閃發光、一塵不染、多年來保持不變的程式碼庫。
整潔的程式碼不是終點，而是一個方向。
這是一種意願，一種心態，是對未來自己的一種善意，一種讓事情不那麼痛苦而非追求完美的方式。
盡可能編寫最簡潔的程式碼。在必要時進行重構。坦誠地分享你的臨時解決方案。理解你使用的捷徑。盡可能選擇清晰明了的表達方式。
但還有一點——這一點至關重要：
💛 不要因為做得不好的地方而懲罰自己。
💛 不要為不得不做出的妥協感到內疚。
💛 不要將你的實際程式碼與教科書中虛構的程式碼進行比較。
💛 不要以為別人都懂一切──他們不明白。
我們所有人的程式碼庫中都存在著一些不為人知的陰暗角落。
我們每個人的程式碼庫深處都隱藏著一些令人尷尬的檔案。
我們每個人都有類似的事情：
[enableSpecialMode]="true"潛伏在生產過程的某一環節。
你猜怎麼著？
我們仍然是優秀的開發者。
我們仍在學習。
我們仍在盡力而為。
程式碼整潔固然重要，但善待自己更重要💛✨
原文出處：https://dev.to/sylwia-lask/nobody-writes-clean-code-we-all-just-pretend-11d1
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
