Categories
程式開發

最好的代碼是沒有代碼


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

一整個週末,我都一頭扎進源代碼裡,很快就發現了問題:這個項目太混亂了,亂成一鍋粥。項目中有有很多不必要的、冗餘的和緊密耦合的代碼。我所說的混亂,並不是指代碼看起來很業餘或充斥著快代碼(捷徑代碼)。事實上恰恰相反,項目裡有太多“魔法”,我看到了很多聰明而宏偉的設計技巧,但它們與項目要解決的問題毫無關係。像反射、面向切面編程、自定義註解一個都不少。這個項目是一隻被過度設計的怪獸。經過我的一番重構,模塊規模減少到原來的一半不到。

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

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

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

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

不要重複發明輪子。

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

if (event.type == THE_ONE_TYPE_THIS_SYSTEM_CAN_HANDLE) {
  process_the_event_and_return_result;
}

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

最後,我以Jeff的一句名言結束本文:

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

參考鏈接:https://codeahoy.com/2016/06/03/write-less-code