從鼬加入的那一周開始，四代就開始着手准備起草代碼規范了。
代碼規范不可少
很多人理直氣壯的認為，創業團隊，或者說人數少的團隊根本不需要代碼規范。
他們的口頭禪經常是：“沒辦法啊！我們需要快速的完成客戶的需求啊！客戶最重要啊！實行代碼規范只會拖慢項目的進度！而且時間太緊，我們也不能搞那么多的學習啊！”。
對於四代來講，不采用規范的做法其實無異於是“飲鴆止渴”，暫時的無限制的代碼提交確實很爽，在項目初期確實可能有助於快速完成需求的功能，但是這種鼠目寸光的做法，如果不盡早改正過來，一旦形成慣性，積重難返，對於只是玩玩的項目來說還沒什么太大的副作用，不過對於想要長期發展的項目來說，這幾乎就百分百會造成深遠的影響，甚至嚴重一點就是滅頂之災。
隨意提交的代碼導致的代碼隨意的堆砌，最后很可能是造成代碼修改起來無比的困難，越往后越難以維護，最后只能是在團隊一片哭爹喊娘的叫喊聲中，項目迎來壽終正寢。四代真的不知道這種不負責任的結論還會影響多少人，還會終結多少項目啊！
對於“沒時間，項目緊”這一點，四代覺的完全是扯淡，完全是借口，從四代的經歷來看，
任何的團隊都需要代碼規范，而且團隊熟練掌握代碼規范后，寫代碼並不會增加多少時間成本！對四代來說，許多的“清規戒律”之所以在很多的團隊執行不下去，完全是團隊管理者造成的，管理者的懶惰和不作為導致了團隊的低效。
代碼的作用
說到代碼規范，就必須要首先理解代碼的作用。扯淡！誰不懂代碼啊？這還用討論嗎！答案是：用！
在四代看來，
代碼存在兩個方面的作用，第一個作用是與機器對話，第二個作用是與團隊對話。第一個是從個人和技術角度講，第二個是從團隊和溝通上講。
對於四代來說，寫代碼存在有兩個層次，也就是說，在四代的眼中，軟件工程師至少存在兩個等級，一個是初級，一個是高級，初級軟件工程師能寫出機器能懂的代碼，也就是說編譯沒問題，運行很正確，但是
高級軟件工程師能寫出人能懂的代碼，也就是不僅編譯沒問題，運行很正確，關鍵是團隊其他人還能讀懂，這就是優秀的軟件工程師最牛逼的地方，沒有“之一”。
對於一個團隊來說，有什么會比代碼的傳承性更重要嗎？沒有！即使是只有一個人的團隊也是如此，誰能牛逼到面對自己一段雜亂不堪的代碼，在幾個月以后還了如指掌！時至今日，代碼在溝通上的容易與否，也就是代碼的溝通成本，或者說維護成本，是衡量代碼好壞的最重要的特征了，這里同樣沒有“之一”。
為了讓代碼便於溝通，為了讓團隊合作更加高效，確實應該制定團隊基本的代碼規范！
代碼規范那些事
代碼規范這個事，毋庸置疑，大家絕對是贊同的，盡管很多人目前不會執行，反正大家認為這個玩意兒應該有。但是這個東東嚴格來說是沒有標准的，不同的人有不同的看法。四代認為：對於一個團隊來說，不管采用何種規范，只要做好三件事就可以了
：第一件事是盡快執行下去，第二件事是堅決執行下去，第三件事是堅持執行下去。
首先得具有這個堅決的態度，這是做這件事的前提條件，否則說什么都是白扯，四代見過太多在團隊中扯淡的人和事了！說的很好聽，可實際上一旦談到落實，就閉口不言！
其次，四代覺得對於代碼規范本身，有幾點還是需要注意的。
第一點，代碼規范最好是明確的規范。
比如下面這些就是比較模糊的規范：
|
1. 變量應該不要太長。
2. 變量名應該清晰易懂。
3. 函數體不要太啰嗦。
4. 類不要太大。
|
如果把這些規范改成下面這樣，或許更能容易執行一點：
|
1. 變量不超過5個單詞。
2. 變量名要表達出變量的用途。
3. 函數體不要超過50行，函數復雜度不要超過10。
4. 類的公開成員不要超過20。
|
第二點，規范應該具有實用性。
至於實用性上，四代認同代碼規范不易太長，可以采用很多人建議的那樣，就搞個”程序員節操15條“，選取你認為團隊中最需要實行的15條放到里面就可以了。比如四代就會選擇如下一些簡單易行的一些規則：
|
元素類型
|
命名規范
|
實現規范
|
|
通用命名
|
使用英文單詞
表達出變量用途
不加變量類型
不使用縮寫
本地變量采用小駝峰命名
函數和類型采用大駝峰命名
|
|
|
表達式
|
語句體即使只有一句也不省略{}
if語句中的條件表達式的邏輯運算不要超過3個
|
|
|
函數
|
以“動詞”或者“動詞+名詞”組合
|
參數不多於5個
函數體不超過30行 (不含空行)
函數復雜度不超過7
|
|
類
|
類和屬性以“名詞”或者“形容詞+名詞”的方式命名
類實例變量以“m_”開頭，靜態變量以“s_”開頭，后面部分使用小駝峰命名
交互型控件變量結尾需加控件類型全稱
類常量/只讀變量不加前綴且使用大駝峰命名
|
類的成員函數(包括普通函數，索引，屬性)全部參照函數的規范
類不允許有非常量的公開字段，如果確實需要則用屬性代替
類公開成員不超過15個
類不超過800行 (所有行)
|
|
接口
|
以“I”開頭，以“形容詞”或“名詞”命名
|
接口的成員不超過5個
|
就這些，不管是重構還是正常寫代碼都用得上，姑且也把這些規則稱為”程序員的節操“吧，呵呵，這可是程序員的底線啊。
第三點，規范應該具有時效性。
隨着時間的不斷推進，隨着團隊成員水平的不斷提高，大家可以不斷的修訂這個規范的內容，比如每年一次，與時俱進嘛！
四代初步的規划是每年年初修訂一次，不求完美，但求符合團隊的實際情況。這個不需要多說了，一潭死水最容易臭掉，一切缺少發展特征的事物最終都會死掉，被淘汰，這是偉大的自然辯證法告訴我們的！在大學幾年中，自然辯證法和哲學是四代認為最重要的課了，也同樣沒有“之一”！
第四點，規范應該是大家一致認同的。
規范是整個團隊代碼提交的准則，所以只有大家一致從心里認同了，大家才會始終貫徹它們。
四代非常重視這一點，當后來規范建立起來以后，四代先是讓團隊中的所有人試着執行了幾個月，然后才正式的和所有的成員討論了規范中的所有細節，解答大家的疑惑，征求大家的意見，最終形成了當年執行的版本。
代碼審查那些事
有了代碼規范了，大部分人可能會認為，這下代碼審查的時候終於可以有話說了。不過四代個人覺得代碼規范更多的是大家自檢的項目，除了團隊新人需要提醒一下外，基本上不需要別人太操心。
代碼審查，這個大家同樣都是點贊的，姑且不管效果有多明顯，反正大家都覺得這個玩意兒有用，大概原因有如下一些：
|
1. 代碼審查能避免一些低級的錯誤，比如拼寫錯誤，比如簡單的邏輯錯誤等。
2. 代碼審查能使得大家互相學習一些新的知識。
3. 代碼審查能多熟悉一些代碼。
4. 代碼審查能避免一些對方代碼的失誤而影響到自己的功能。
5. 代碼審查能尋找到更加優化的方案。
|
但是一到實際的項目中，就會有各種問題導致不能貫徹執行下去，比如下面這些理由：
|
1. 時間不夠
“哥啊，軟件開發任務多的做不過來，那還有時間做代碼審查？這不是代碼審查好不好的問題，而是我沒時間做啊！”
2. 需求變化
“需求變得太快，代碼的生存周期比較短，不需要好的代碼，反正過兩天這些代碼就可能會被廢棄了！”
3. 態度問題
“別人的代碼，我又不懂，怎么審查啊！而且就算是自己寫的，寫好就行啦，干嘛精益求精啊！”
4. 結果最重要
“大佬們都說了，能運行的代碼最重要了，要那么漂亮干什么！”
5. 能力不足
“不好意思啊，我們都不知道怎么做代碼審查啊！”
|
乖乖，總結一下都能寫一篇論文。但是不管怎么樣，四代根據團隊實施代碼審查的過程，覺得有幾點是值得大家深入思考的：
第一點，任何提交到代碼庫的代碼必須是經過代碼審查的。
這個不用多說了吧，既然代碼審查那么的重要，無論時間多么的緊迫，謹慎一點都是必要的，尤其是對一些發布流程比較長，發布成本比較高的產品，如PC團隊研發的桌面版軟件。
第二點，代碼審查不僅僅檢查那些代碼規范，還要檢查代碼的邏輯是否合理。
雖然很多時候，代碼審查並不能如想象的那樣，發現代碼的很多問題，但是代碼審查會提升程序員的編程態度。試想如果一個人知道將會有同事檢查他的代碼，他編程態度就絕對會不一樣的。他寫出的代碼將更加整潔，有更好的注釋，更好的程序結構，因為他知道，大家將會查看他的程序。
在代碼審查中最常犯的錯誤幾乎每個新手都會犯的錯誤是，審查者根據自己的編程習慣來評判別人的代碼（當然，基本的代碼規范是需要大家共同遵守的，哈哈）。
對於一個問題，通常大家能找出十幾種方法去解決。對於一種解決方案，大家能有百萬種編碼方案來實現它。做代碼審查的時候，審查者的任務不是來確保被審查的代碼都采用的是自己習慣的編碼方式，因為大部分情況下，它不可能跟你自己寫的一樣。作為一段代碼的審查者的任務是確保由作者自己寫出的代碼是正確的。
第三點，代碼審查不一定非要說些什么。
代碼審查經常易犯的毛病是，人們覺得有壓力，感覺非要說點什么才好。當審查者知道作者用了大量的時間和精力來實現這些程序，不該說點什么嗎？不，大部分時候並不需要。大部分時候，只說一句：“哇，不錯呀”，會非常合適。
第四點，代碼審查要堅持執行，一定不要敷衍。
沒有什么事情能簡單的做下來的。依四代的經驗，在團隊能正確的進行代碼審查前，大家是需要花時間學習和實踐的。人們在代碼審查時經常會犯一些錯誤，導致不少麻煩，尤其在一些缺乏經驗的審查者中經常的出現。他們給了人們一個很遭的代碼審查的體驗，成為了人們接受代碼審查制度的一個障礙。
代碼規范和代碼審查是PC團隊最重要的幾件事之一，從規范討論的那天起，四代就征求了鼬關於這件事的意見，他們經歷過入職后修改部分代碼的痛苦的經歷后，一致認為這么做非常有必要，於是，就在某個月黑風高的夜晚，它終於被正式實施了。