我在做什么

曾經，我試過接到一些需求。一眼帶過后，腦袋馬上隨著高昂的斗志沉溺在代碼的世界中 ，馬不停蹄地敲著鍵盤直到最后測試的完成。我從思緒中恢復過來，乍一看自己寫的功能，和需求差了十萬八千里，我TM都在干嘛？

除此之外，我還見過類似的很好笑的事情。有一個程序員，經理提了需求，然后他在那里折騰了一天。結果不但沒做出來，而且和實際需求都是完全搭不上調。經過詢問發現，他不知道經理說了什么，也不知道自己到底在做什么。

代碼的世界可能是昏天暗地的，但是我們的思維不能這樣隨之混亂，否則一切都會前功盡棄。所以我現在編寫程序的時候，經常會想一下：我要做什么，我在做什么。更好的方法是把詳細需求落實到文檔，并時刻核對文檔。

大局為重

2-8法則告訴我們，一個項目核心的功能只有很少，其它大部分都是對核心功能輔助或增強的。但當任務分發下來，我手頭總有一些自己很想開發的模塊，不過它們不屬于那20%。我以前經常會在這些感興趣的模塊上花費很多時間和精力。

結果項目快要到上線期限，主要的功能卻沒開發完成，其它一些不起眼的功能卻做得很好，但為此項目不得不延期了。如果反過來，只要對整體功能預期不會有太大偏差，可以將就的先上線。重要一點是：即使功能還有遺漏，但項目可以上線了，老板自然不會太追究，自己工作也能圖個安心。如果不知道那些功能模塊是最重要的，先問問經理。

人總是喜歡做一些自己感興趣或者有挑戰的事。不過在這方面，為了項目和團隊著想，應該盡量壓制這種誘惑。

性能永遠不是優先考慮的問題

我從來不會一開始就考慮性能問題。如果項目成本很低，甚至到項目結束時，如果沒有感覺到明顯的性能問題，也不會去管。要知道現在已經不是DOS的年代，CPU的計算能力很高，但成本很低了。重要一點是，如果只針對提升性能對代碼做改動，很容易破壞代碼的復用性和可維護性。而返過來，提高了代碼的復用性和可維護性，則很容易提高性能。

下面有一個PHP的代碼實例，功能是幫助用戶重置密碼（代碼為了簡單說明問題，請不要太在意一些無關的細節）

requestResetPassword是接收用戶重置密碼的請求并且做了相應的檢查。為了更好的復用性，我將重置密碼的操作單獨分配到一個新的resetPassword的函數，更改完密碼的后再調用sendEmail向用戶發送一封通知郵件。

/**  
 * 用戶請求重置密碼的接收器  
 */ 
function requestResetPassword() {  
    //檢查用戶是否存在  
    if( !checkUserExists( $_GET['userid'] ) ) {  
        exit('抱歉，用戶不存在，請確認用戶帳號。');  
    }  
    resetPassword( $_GET['userid'] );  
    //最后向用戶發送一封郵件  
    sendEmail( $_GET['userid'], '重置密碼成功', '新的密碼是xxxx' );  
    exit('新密碼已經發送到你的郵箱。');  
}  
 
 
/**  
 * 幫助用戶重置密碼  
 */ 
function resetPassword( $userid ) {  
    //檢查用戶是否存在  
    if( !checkUserExists( $userid ) ) {  
        return false;  
    }  
 
    //進行重置用戶密碼的操作  
    //略...  
    return true;  
}  
 
 
/**  
 * 向用戶發送一封郵件  
 */ 
function sendEmail( $userid, $title, $content ) {  
    //檢查用戶是否存在  
    if( !checkUserExists( $userid ) ) {  
        return false;  
    }  
 
    //發送郵件操作  
    //略...  
    return true;  
}  
 
 
/**  
 * 檢查某個用戶是否存在  
 */ 
function checkUserExists( $userid ) {  
    $user = getUserInfo( $userid );  
    return !emptyempty( $user );  
}  
 
 
/**  
 * 獲取某個用戶的數據  
 */ 
function getUserInfo( $userid ) {  
    //假設我有一個query的函數，它用來查詢數據庫并返回數據  
    $user = query( "SELECT * FROM `user` WHERE `uid`=" . intval( $userid ) );  
    return is_array( $user ) ? $user : array() ;  
} 

現在問題是，這三個函數都同時使用checkUserExists這個函數來檢查用戶不存在，數據庫查詢了三次，這樣帶來了一些額外的開銷。

如果要去掉三者之間任意一個checkUserExists，看上去是可能的。但是如果之后有某些功能要調用resetPassword或者sendEmail，用戶不存在時，系統可能會發生錯誤。

還有一個解決方法是，將resetPassword的邏輯寫到requestResetPassword里，再過一點，把sendEmail的邏輯也寫進去。這樣函數調用減少，數據庫查詢也變成一次了，性能得到了提高。但是重置密碼和發送郵件的功能將不能得到復用，并且違背了單一責任的原則，代碼復雜度也提高了。

不過，因為函數分離和復用性都很好，如果實際性能受到影響，可能考慮用緩存的方法減少數據庫查詢，我改動了它們共用的checkUserExists函數：

/**  
 * 檢查某個用戶是否存在  
 */ 
function checkUserExists( $userid ) {  
    //增加一個緩存，用以記錄檢查用戶的結果  
    static $cache = array();  
 
    //檢查當前用戶是否已經檢查過一次  
    if( isset( $cache[ $userid ] ) ) {  
        return $cache[ $userid ];  
    }  
 
    $user = getUserInfo( $userid );  
    //把結果記錄到緩存中  
    $cache[ $userid ] = !emptyempty( $user );  
 
    return $cache[ $userid ];  
} 

也可以用同樣的方法改動getUserInfo函數。

這里可以看到，當代碼的復用性提高時，想提高性能是很簡單的，性能的瓶頸也很容易被發現和修改。

盡管這個例子對性能影響還不夠大，還有一些影響更大的，比如說遍歷，我可能為了復用而將遍歷封裝到一個函數中，并且多次使用它。這些開銷對我的項目根本沒有預想中那樣有太大的影響，或者說是微乎其微的。所以我更愿意把時間花在如何提高代碼的復用性和維護性方面，而不是糾結于浪費多這一點性能。實際性能如果真的達不到要求，也可以權衡增加硬件配置。

#p#

名字長一點好

函數名和變量名等除了給機器看，也要給人看的，有時一個簡單直接的好名字實在是很難想，這時不妨用長一點的名字更好。可讀性更好：

//好名字  
class ErasedTypeEquivalence {  
}  
 
//壞名字  
class ErdTypeEqe {  
}  
 
//好名字  
function checkUserExists () {  
}  
 
//壞名字  
function ckUserExt() {  
}  
 
//好名字  
$result;  
 
//壞名字  
$ret; 

我見過一些代碼，由于簡單寫過多，整遍代碼很多都是4個字母或以下的，可讀性非常差，當然不排除是為了偷懶。

但如果想有更多的時間騰出來偷懶，不應該在這上面玩小聰明，否則這時我現在應該在思考前幾天的代碼是在寫什么。

什么？短名字會讓代碼執行得更快？ 那證明給我看，如果真的快，快了多少？

自說明代碼很重要，但注釋同樣重要

代碼本身可以說明問題的確是很棒的，但并不是說注釋不重要，有時候我更喜歡先看注釋，因為它總比我看代碼更快的了解這程序是做什么的。

如果我把本文前面說性能的例子去掉注釋，哪個能讓你更快了解代碼的意圖？或者說，你更愿意看哪個？

function requestResetPassword() {  
    if( !checkUserExists( $_GET['userid'] ) ) {  
        exit('抱歉，用戶不存在，請確認用戶帳號。');  
    }  
    resetPassword( $_GET['userid'] );  
    sendEmail( $_GET['userid'], '重置密碼成功', '新的密碼是xxxx' );  
    exit('新密碼已經發送到你的郵箱。');  
}  
 
 
function resetPassword( $userid ) {  
    if( !checkUserExists( $userid ) ) {  
        return false;  
    }  
 
    //進行重置用戶密碼的操作  
    //略...  
    return true;  
}  
 
 
function sendEmail( $userid, $title, $content ) {  
    if( !checkUserExists( $userid ) ) {  
        return false;  
    }  
 
    //發送郵件操作  
    //略...  
    return true;  
}  
 
 
function checkUserExists( $userid ) {  
    static $cache = array();  
 
    if( isset( $cache[ $userid ] ) ) {  
        return $cache[ $userid ];  
    }  
 
    $user = getUserInfo( $userid );  
    $cache[ $userid ] = !emptyempty( $user );  
 
    return $cache[ $userid ];  
}  
 
 
function getUserInfo( $userid ) {  
    $user = query( "SELECT * FROM `user` WHERE `uid`=" . intval( $userid ) );  
    return is_array( $user ) ? $user : array() ;  
} 

所以，即使代碼本身很清晰，但是加上注釋的話，可讀性也能提高很多！

適當抽象

編程就是為了解決實際中的問題，在思考如何編碼的時候，把問題抽象到一定的高度去思考，更容易把握問題所在。不過更多時候，我發現從代碼抽象到現實的例子是有一定難度的，同時我也相信，編程高手也是抽象高手，他們很容易把問題反映到真實生活中去。

不過如果經常留意和思考生活中的細節，會提升自己的抽象能力。

舉一個螺絲刀的例子，如果叫你造一個螺絲刀，你會做成什么樣子？我這里有三把不同的螺絲刀：

[[75101]] 

顯然第一種螺絲刀是最簡單的，比較中規中矩。

第二種螺絲刀中間可以旋轉刀柄，讓刀柄和刀頭成90度，這樣的設計讓擰螺絲更加輕松。

第三種螺絲刀則可以更換刀頭，如果以后有其它類型的螺絲，則只要造一個適合這種螺絲的刀頭就可以了。

那反映到編程中的問題，如果項目要增加一個工具類庫。

第一種方法，可以直接把類庫的所需功能寫出來就可以了。

第二種方法，不但把類庫寫出來，而且針對項目的一些情況做特殊改進，使得在這個項目中更好用。

第三種方法，根據類庫的特性，把公共部分的邏輯做成接口，特殊的部分分離出來單獨實現，如果以后要增加相同類型的類庫，則實現特殊部分的邏輯，然后接入接口即可。

但是在抽象的時候，要避免不合理的抽象，有時也可能造成過渡設計，現在只需要一種螺絲刀，但你卻把更多類型的螺絲刀都做出來了（而且還是瑞士軍刀的樣子。。）：

[[75102]] 

 #p#

一致性

團隊開發中，可能每個人的編程風格都不一樣，拿花括號來說，有些人喜歡和代碼在同一行，而有些喜歡獨自一行

//例一  
function func() {  
}  
 
//例二  
function func()  
{  
} 

命名風格也都不一樣，比如說聲明變量接收一個函數返回的數據，有些喜歡用result，有些喜歡用data。

它們可能都很好，不過在團隊開發中，盡量統一用同一種風格能夠很好的減少交叉開發的成本。

將錯就錯

面對項目一些無關緊要的分歧或錯誤，應該要接受和理解。承接上面的問題，如果團隊中已經有人大量用了data的變量命名，但你認為result的更符合當前狀況的描述。這種情況，我優先選擇data命名，因為如果再使用result的話，會破壞項目的一致性，對開發沒有任何好處。

這只是很少的一方面，如果項目規范沒有很好的落實，實際工作中會有大量的一致性問題，必須靠團隊每個人的決心和責任心去把它做好。通常，加入一個正在開發中的項目，編寫功能前，我都會首先看項目之前的類似的代碼，并盡量模仿他們的寫法。不過，如果有明顯的錯誤，應該及時指出和修正。

只要堅持把一致性做好，很多方法會成為團隊甚至業界的標準，即使它們不是最好的，但是有什么關系呢？

適當休息

編程的時候如果沒有思路或者感到混亂，到外邊休息10分鐘，或者看一下風景，讓腦袋清醒一下是很好的。這招很管用，親測。

至少把代碼完整運行一次

有時函數的邏輯過于簡單，以至于會認為這個不可能發生錯誤，但事實上最容易發生錯誤的通常就是這些代碼，常見的單詞拼寫錯誤，參數錯誤，還有一些意料之外的問題。所以無論什么情況，我都會把代碼完整運行一遍。

當然更好的做法是用一些系統的測試方法，比如說單元測試。

編程不是藝術

從一開始，編程語言的出現和發展，都是為了解決現實生活中的問題，包括它自身產生的問題。

面向對象、設計模式的出現，是用來解決編程語言自身帶來的可讀性和維護性等問題，而不是為了讓編程語言上升到藝術的層面。盡管編程中有‘優雅’一詞，但我更認為它只是用來形容代碼更容易讓人讀懂和維護。

我拒絕一切看起來很‘優雅’，卻不能為編程工作帶來一點好處的代碼。如果你喜歡玩弄語言，應該去當作家。

甘于平凡

程序員真的很高傲，在我接觸過的人中，包括我自己也是。我以前經常對一些簡單的代碼感到不屑，而總想在項目中寫一些犀利的代碼，讓人看起來很NB，但結果總是和想象差太遠，代碼總是寫的很差，邏輯也不夠清晰。歸根到底，是我帶著這樣的思想去寫代碼，而忽略了編程的根本：解決問題?，F在我改掉了這個壞毛病，以解決問題為目的去編程，以簡單為主。出乎意料的是別人有時會對我說，這里的代碼寫得很棒。

踏實的做事，會有意想不到的收獲。

承認錯誤

不要懷疑，當別人用自己的程序或者代碼無法運行時，首先考慮是否是自己的邏輯哪里有問題。一來別人會覺得我謙虛，二來實際大多數情況的確是自己的問題。

有原則，有決心

做任何事情都堅持原則，并有決心是最好的。有很多道理我們都明白，但經常做不到，沒有任何人能幫到自己，未來也是自己爭取的。

所以，如果知道什么是好，就盡量去做，什么是不好，就盡量避免。

即使是在公司面對經理和領導，也要堅持自己的做法，一些不合理的需求應該指出或拒絕。我還年輕，大不了換一家公司，而不愿意做一個受欺壓的碼農。

我在做什么

文章寫完了，現在來回想一下，我是在分享自己現在編程的一些習慣，總算沒偏離開始的主題。本文的思想都是來自實際工作和一些書籍，想了解更多的話，推薦閱讀《整潔代碼之道》《代碼大全》《重構》這幾本書。

如果你有一些認為好的編程方法，不妨拿出來和大家分享一下。

原文鏈接：http://my.oschina.net/u/867608/blog/138002