最好的代碼是沒有代碼

雲栖号資訊：【 點選檢視更多行業資訊

】

在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！

不久前，我開始着手清理一個接手過來的項目。因為項目有一些 bug，是以我有足夠的自由來重構它。但修複舊 bug 會引入新 bug，于是乎我就陷入了惡性循環。

一整個周末，我都一頭紮進源代碼裡，很快就發現了問題：這個項目太混亂了，亂成一鍋粥。項目中有有很多不必要的、備援的和緊密耦合的代碼。我所說的混亂，并不是指代碼看起來很業餘或充斥着快代碼（捷徑代碼）。事實上恰恰相反，項目裡有太多“魔法”，我看到了很多聰明而宏偉的設計技巧，但它們與項目要解決的問題毫無關系。像反射、面向切面程式設計、自定義注解一個都不少。這個項目是一隻被過度設計的怪獸。經過我的一番重構，子產品規模減少到原來的一半不到。

我相信原先開發這個項目的人的出發點是好的，但聰明反被聰明誤，他們使用的技巧給自己帶來了麻煩。是以他們隻得花很多時間在維護和修複 bug 上，而使用者對滿是 bug 的軟體也會感到不滿。開發者自己感覺就更糟糕，因為每個人都在抱怨這個項目。但是誰該為他們承受的這些痛苦負責呢？他們不得不花很長時間來修複 bug，卻無法從工作中獲得滿足感。除了開發者自己，還能責怪誰呢！Jeff Atwood 在一篇博文中提到過：“最好的代碼是沒有代碼”：

對于大多數軟體開發者來說，要讓他們承認這一點是很痛苦的，因為他們愛他們的代碼。你寫的每一行新代碼都需要經過調試，需要具備可閱讀性和可維護性。每次寫新代碼時，你都要在這種壓力之下不情願地這麼做，而你已經無計可施了，不得不這麼做。代碼成了我們的敵人，因為有太多程式員寫了太多該死的代碼。如果你一定要寫代碼，那最好一開始就簡潔。

Jeff 的觀點很有道理。作為開發者，我們喜歡想出各種聰明的解決方案，認為這會讓我們看起來更專業，或者有助于我們學習新的工具或技術。于是我們抛棄簡單，層層疊加各種方案，并證明它們是“實際需要的”。但我們必須認識到，我們寫的代碼越多，在代碼中使用的“魔法”也越多，為 bug 留下的機會也就越多。

這些 bug 會回頭過來給我們或接手我們代碼的人造成困擾，我們需要加班來修複它們。顯然，我們不是在讨論如何使用技巧來減少代碼行數。相反，我們應該問問自己是否需要寫這麼多代碼。在我的職業生涯中，我見過一些自己開發的 ORM 架構和線程池，這讓我想起了一句話：

不要重複發明輪子。

這句話不隻是想想而已。在開發這些架構之前請先思考一下是否真的有必要。我參與過的一個項目使用 Hibernate 和 DAO/DTO 來執行一個簡單的查詢。另一個項目有一個事件處理系統，它使用反射 API 根據事件類型來調用具體的類方法。這個解決方案看起來很“巧妙”，我花了很長時間才搞清楚 IDE 标記未被使用的方法原來是通過反射來調用的。更搞笑的是，這個系統隻處理一種類型的事件。實際上，這些代碼可以被壓縮成一個簡單的 if 語句：

最好的代碼是沒有代碼，而最快的代碼是永遠不會被執行的代碼。我們的目标應該是讓解決方案盡可能保持簡單，避免過度工程，避免使用讨巧的技巧和設計模式，除非它們對于解決問題來說是絕對有必要的。複雜性是我們最大的敵人，不必要的複雜性更是如此。大多數時候，我們不需要這些複雜性。

最後，我以 Jeff 的一句名言結束本文：

如果你真的喜歡寫代碼，那就要喜歡到盡可能少寫代碼。

【雲栖号線上課堂】每天都有産品技術專家分享！

課程位址：

https://yqh.aliyun.com/zhibo

立即加入社群，與專家面對面，及時了解課程最新動态！

【雲栖号線上課堂 社群】

https://c.tb.cn/F3.Z8gvnK

原文釋出時間：2020-03-24

本文作者：Umer Mansoor

本文來自：“

InfoQ 微信公衆号

”，了解相關資訊可以關注“

InfoQ

”