0.1x工程師訪談：爆笑揭秘！前端大佬的奇葩日常與血淚史

軟體開發的黑暗面：一個反面教材

這篇文章彙集了一些在軟體開發中應避免的常見錯誤和不良習慣。這些例子涵蓋了從效能優化到安全實踐的各個方面，旨在提醒開發者注意潛在的問題並避免重蹈覆轍。

效能與環境假設

• 永遠假設使用者身處完美網路環境且擁有 64GB RAM？ 這種假設是錯誤的。軟體應在各種環境下都能良好運行。

• 曾經花費五天時間處理一個 404 頁面？ 這表明缺乏有效的錯誤處理和除錯能力。

• 不考慮伺服器問題，因為我們是「無伺服器」的？ 無伺服器架構仍然依賴底層伺服器，需要關注效能和配置。

程式碼品質與架構

• 將 .READMEs 的檔案大小最佳化作為主要任務？ 這過於注重細節，忽略了更重要的問題。

• 修改硬編碼的值就可以向後相容？ 這是一種危險的做法，容易導致程式碼混亂和錯誤。

• 像 Jupyter Notebook 一樣建構生產系統？ Jupyter Notebook 適合實驗，但不適用於穩定的生產環境。

• 能用 console.log 時為何要用 TypeScript？ TypeScript 可以提高程式碼的可維護性和可讀性。

• 監控系統？只要檢查網站是否載入即可？ 這是極其簡化的監控方式，無法發現深層次的問題。

• API 金鑰安全地隱藏在程式碼庫中？ 這不是安全的做法，應使用環境變數或密鑰管理系統。

• 修正記憶體洩漏？只要自動擴展 RAM 即可？ 這是治標不治本的方法，應找出並修復洩漏的根本原因。

開發流程與工具

• 「修正記憶體洩漏？只要自動擴展 RAM 即可，老兄！」 這顯然是一種不負責任的態度。

• 估計功能所需時間？「需要多久就多久。」 缺乏明確的規劃和時間管理。

• Git 沒有 GitHub 還有什麼意義？ Git 是一個版本控制系統，GitHub 是一個託管服務，兩者是不同的概念。

• 永遠使用最新的技術會議，指導新進人員？ 固然不錯，但也應注重基礎知識的掌握。

• z-index: -9000 才是最佳解？ 過度使用 z-index 可能導致樣式混亂。

• Commit 訊息沒有表情符號，怎麼知道我的感受？ Commit 訊息應清晰簡潔，表達程式碼的變更意圖。

• git pull -do-not-rebase -never-rebase？ 強行避免 rebase 可能會導致不必要的合併衝突。

• 所有影片檔案都儲存在 GitHub 上？ GitHub 不是為儲存大型二進位檔案而設計的。

• 還在使用 master 分支？ 應使用分支進行開發，避免直接提交到主分支。

• 移除所有註解以節省檔案大小？ 註解對於程式碼的可讀性和維護至關重要。

• 寧願切換框架也不願完成功能？ 這會導致項目進度延遲。

其他警訊

• 在程式碼中使用 !important？ 過度使用 !important 會破壞 CSS 的層疊規則。

• 認為測試只是為了懲罰開發者？ 測試是確保程式碼品質的重要手段。

• 變數名稱以漫威角色命名？ 變數名稱應具有描述性，便於理解。

• 「tempCalculation」、「tempCalculation1」？ 變數名稱應具體且有意義。

• AI 可以解決所有問題，無需上傳程式碼到 Stack Overflow？ AI 只是輔助工具，不能完全替代人工。

• 從未按時關閉 Trello 工單？ 反映時間管理能力不足。

• 「props to FFMPEG」？ 應正確引用和感謝開源專案。

• 「AI is taking our jobs」？ AI 是一種工具，應學習如何利用它來提高效率。

• 花費十年才讓 Web App 變得穩健，卻因一次深夜提交而崩潰？ 強調了測試的重要性。

• 主要的客戶是行動 Safari 瀏覽器？ 應考慮跨瀏覽器兼容性。

• DDoS 驅動開發？ 開發決策不應受 DDoS 攻擊的影響。

• 將整個 AWS 堆疊再次遷移到 Vercel？ 頻繁遷移架構會帶來不穩定性。

• 「優化了 AI」？ 需要明確具體地說明優化內容。

• 誰在測試？客戶！ 正式的測試流程是必需的。

總結

上述例子揭示了在軟體開發中可能出現的各種問題。透過避免這些不良習慣，開發者可以提高程式碼品質、改善開發流程並確保軟體的穩定性和可靠性。持續學習和反思是成為一名優秀開發者的關鍵。