據維基百科記載：“Redis是一個使用ANSI C編寫的開源、支援網路、基於記憶體、可選永續性的鍵值對儲存資料庫。根據月度排行網站DB-Engines.com的資料顯示，Redis是最流行的鍵值對儲存資料庫。”

Redis 之父 Salvatore Sanfilippo，一名義大利程式設計師，大家更習慣稱呼他 Antirez。本文為Salvatore所寫，CSDN編譯，具體講述了其心目中成就一名“野獸級”程式設計師的可貴品質。

坊間流傳著“十倍程式設計師”的傳說，所謂“十倍程式設計師”是指在同樣時間內可以做“普通”程式設計師十倍的工作的程式設計師，而所謂“普通”是指那些擅長自己的領域，但不具有“十倍程式設計師”那樣特殊魔力的程式設計師。更準確地說，普通程式設計師就是指那些具有平均程式設計效率的專業程式設計師。

在程式設計師群體中，對於“十倍程式設計師”的存在持有極度分化的觀點：一些人認為這樣的人絕不存在，另一些人則認為不僅存在，而且甚至存在“百倍程式設計師”。

如果你認為程式設計是一項線性工作（產出與勞動時間成正比的工作），那麼顯然“十倍程式設計師”是一種不合理的存在。一個跑步運動員不可能比對手跑得快十倍，一個建築工人也不可能在同等時間建造十倍於別人的東西。然而，程式設計實際上是一項特殊的“設計”工作。此處設計不單指架構師的工作。即便不是專案的整體設計，當工程師具體實現它的時候，依然需要低層的實現策略的設計。

在我看來，程式的設計和實現不是一項線性工作。經驗、程式碼能力、知識、對不重要事項的辨識能力都是不易量化的能力，這些能力的結合在程式開發中發揮重要作用，使程式設計師更高效。特別是當一個程式設計師需要全程參與到專案的設計與實現時，這些能力的優勢更加明顯。

越是以結果為導向的任務越能激發高效程式設計師的能力。因為在結果導向的任務中，高效的程式設計師能夠找到自己的方式，用更少的投入達到同樣的效果。他們可以從頂層改變目標的實現路徑，有時甚至直接去掉不必要的模組，來減少工作量而不影響目標的達成。而相對要求嚴格的專案，則會使這種效應減弱，因為程式設計師不得不受到諸如“使用某某工具”，“通過某某演算法”的限制。雖然如此，高效程式設計師在這種多限制的情況下仍有其優勢：他們可以發掘細節處優化實現的辦法。

在我二十年的程式設計生涯中，始終觀察我身邊的程式設計師，無論我的同事、學徒，還是Redis或者其他專案的貢獻者，以指導他們高效地達到既定目標。很多人說我是個很“快”的程式設計師。鑑於我不是個工作狂，所以我想以我為例來說明如何高效程式設計。

以下是我認為影響程式設計師工作效率的最主要因素：

純程式設計能力：不寫一行多餘程式碼

程式設計師的純程式設計能力是程式設計師水平的最直接表現。在解決實際問題時候，程式設計師經常會被要求實現專案的某一個子模組，一個函式或者一個演算法等等。令人驚訝的是，我發現在這個過程中，很少有人能夠做到用最少的命令高效地完成任務。我甚至發現在很多團隊中，竟然存在會忘記使用排序演算法的不稱職的程式設計師，這讓他們甚至無法勝過雖然缺乏實踐經驗但理論完備的畢業生。

經驗：踩在前人的肩膀上

所謂經驗，我指的是重複出現的任務的成熟解決方案。一個有經驗的程式設計師知道如何處理各種任務。這可以避免重複設計，更重要的是可以避免設計錯誤，設計錯誤是程式設計師效率的最大敵人。

專注：高效利用時間

對於任何事情，時間的有效利用都至關重要，許多內在和外在的因素都會導致程式設計師喪失專注度。內在因素包括拖延症、沒有興趣、缺乏經驗、睡眠短缺等。外在因素包括頻繁的會議、工作環境、同事的干擾等。提高專注度、避免打擾能夠提高程式設計效率，這很好理解。有時，為了專注，需要狠下心來，採取較為極端的措施。比如郵件，雖然都會看，但只回復很少的一部分。

不要吝惜時間設計：防止推倒重來

很多時候，程式設計師非常不情願看到的一種情況是，需要在一些無關緊要的功能上浪費大量的時間，但你又不得不去將這個無關緊要的功能實現，因為它牽扯著這個專案的主要功能。這種時候，就需要反思，在頂層設計的時候是否考慮周全。詳細而縝密的頂層設計能夠減少上述情況的發生，即降低模組間的耦合性。對於專案的設計者來說，意識到每一個細小的模組都有可能成為專案的瓶頸，這很重要。對於專案而言，最終的目標是合理的時間做最大的產出，那麼實施重點就應該放在專案最主要的模組上。拿我設計Disque（一個開源的分散式訊息佇列）為例，我意識到只要提供最優的訊息排列方式，至於專案其他錦上添花的方面都可以後續慢慢補充，例如，可用性、查詢語言、客戶端互動、簡易性及系統性能。

簡潔性：避免細節錯誤才是程式簡潔的根本

簡潔性意味著很多。為了理解什麼是簡潔性，首先來看看究竟可以多複雜？我相信導致複雜性有兩個罪魁禍首，除了上面所說的不願意花費過多的時間在設計上，還有一個是在設計過程中錯誤的累積。

思考一下程式實施的過程，所謂失之毫釐，謬以千里。一個初始的設計錯誤可能不會導致所在功能的重新設計，但可能會導致開發者需要在其他功能上做大量的工作來應對這個錯誤。因此，專案一步一步走向複雜和低效。

簡潔性需要一步一步實現。程式設計師可以從最直接可靠的解決方式開始入手，用盡可能簡單的方式實現功能，之後隨著經驗和程式設計能力的提高，程式設計師就有能力去優化設計了。

每次遇到不得不採取複雜的解決的方案的情況，開發者都應該花些時間想想如何避免這種情況的發生。只有在考慮了各種不同的方式，發現不得不走這條道路的時候，才繼續在這個方向上前進。

完美主義：高效產出的最大阻礙

完美主義有兩種型別，一種是追求至高效能的工程師文化，一種要符合個人趣向的執拗。兩種情況都妨礙到程式設計師快速釋出專案。完美主義和對外界評價的在乎會使程式設計師過多地將關注點放在一些細枝末節上，進而主觀忽視專案的關鍵特性，例如程式的穩健性、簡潔性、及是否能夠按時交付。

知識：某些關鍵問題還是要依靠理論解決

當處理複雜的任務時：資料結構知識、對計算能力的極限的瞭解、對針對某個任務最行之有效的小眾演算法的瞭解，會幫助我們解決這些任務。對於開發者而言，對所有問題的所有解決方案都瞭如指掌這不現實，但對於某類問題的多數潛在解決方案都有所瞭解是必須的。例如，容許一定錯誤率，考慮概率集合基數估計量，可以設計一個優化的流的元素計數演算法，避免複雜，緩慢，空間效率低下的缺點。

底層：熟悉計算機的脾性

即便我們使用的是高階語言，但不瞭解計算機的內部執行機制仍然會導致一些問題。有時系統會出現涉及到底層問題的工具或演算法錯誤，導致整個系統的重新設計實施。深入理解C語言、CPU運算機理和作業系統核心會避免我們遇到在專案後期“推倒重來”的情況。

Debug能力：無需多言

尋找Bug總是非常耗費時間的。擅長髮現、定位併合理地解決Bug，以及在程式設計過程中儘可能簡化程式以減少Bug，這些素質將極大地提高程式設計師的程式設計效率

總結

對於我來說，一個擁有以上素質的程式設計師，能表現出“十倍”於平庸程式設計師的效率是絕不意外的。往往，他們在專案開始的可行性研究階段就能做出正確的決策，這樣一來，數倍於常人的效率是很容易實現的。這種方式我稱之為“取巧程式設計”，意思是在開發過程中的每一步都選擇最優化的解決方案，花費最少的努力獲得最大的使用者體驗。