關(guān)于“編碼參考規(guī)范”的探討

去年年末，為我所在的技術(shù)團隊編寫了Java編碼規(guī)范。其執(zhí)行過程還算順利，因為團隊不大，并且大家都希望能夠有這么一個可供參考的東西。但是在我與其他的團隊交流的時候，有些程序員卻跟我道出了不同的意見?，F(xiàn)在我摘出幾條：

1、團隊應該在設計上追求一致，比如一致的業(yè)務邏輯、一致的算法，但是在編碼風格上應該帶有些個人色彩，否則就沒有樂趣了。

2、我們每天都有那么多東西約束我們，比如：上下班要打卡，工作任務即使加班也要按時完成，漲工資不隨心愿，頭頭并不能理解我的愿望和思想等等。為什么還要在編碼風格這么小的事情上進行約束呢？

3、開發(fā)團隊里規(guī)范太多了，連編碼規(guī)范都要統(tǒng)一么？開發(fā)組長和技術(shù)經(jīng)理就不應該過多的干涉細節(jié)，這樣還讓我們怎樣工作？

聽到這些言語，我很感嘆，因為我曾經(jīng)也有過類似的想法。但是我現(xiàn)在想說的是：

1、我們是一個團隊，需要協(xié)作、需要共事。項目開發(fā)的工作并不是一起玩過家家，更不是一個人自娛自樂。一個標準的編碼規(guī)范，有利于團隊的協(xié)作，包括代碼共享、交互學習、結(jié)對編程、交叉測試、代碼審查等等，更有利于提高大家的工作效率和團隊精神。它就像實現(xiàn)模式一樣讓大家不必為細小的瑣事而浪費精力，直接按照經(jīng)過檢驗的慣例來做。它更像設計模式一樣，使大家有一個共同的參考，共同的標準做法。

2、人活在世上，除非有能力和勇氣做一個獨一無二的、創(chuàng)造歷史的牛人，否則就需要遵守社會國家、家庭、公司、團隊的各種規(guī)范和制度。但即使是上述的那種牛人也是需要先虛心學習、融入環(huán)境，而后才能去創(chuàng)造歷史。所以，我認為一個組織是需要它自己的規(guī)矩的，它的合理與否可以經(jīng)過商榷和探討，但是它的存在必要性是可以完全肯定的。我相信，一個希望和團隊一起共事、有團隊精神的成員是不會對一般性的規(guī)范和制度產(chǎn)生質(zhì)疑的。

3、就開發(fā)工作而言，我所提倡的是：編碼風格的統(tǒng)一，設計風格的自由。每一個項目的設計理念和架構(gòu)是需要項目技術(shù)負責人自己去把控的，只有這樣才能讓大家真正的思考怎樣才能做好軟件設計，這樣才能讓大家真正的在項目中獲得經(jīng)驗和鍛煉。然而，對于編碼的風格、父包命名規(guī)則、縮進規(guī)定等等這類細小的地方不需要、也不值得讓每個程序員去費心選擇，這既不利于工作重點的明確也不利于代碼可讀性的提高。

4、其實，從實現(xiàn)模式和設計模式的概念中，我們可以映射出編碼風格統(tǒng)一和設計風格自由的真正含義。

實現(xiàn)模式，是一些久經(jīng)歷史驗證的一些慣例和原則。雖然可以根據(jù)具體的情況進行調(diào)整，但是大多數(shù)情況下它已經(jīng)成為了大多數(shù)開發(fā)者們的習慣性行為。毫無理由的改變，就意味著在交互和溝通過程中需要花費額外精力去解釋和理解。編碼規(guī)范就類似于實現(xiàn)模式。

設計模式，也同樣是業(yè)界精英們總結(jié)出來的好的設計方法。然而，每個項目都有它的特殊性和獨立性。我們需要根據(jù)項目需要來做出我們的設計，教科書似的完全照搬設計模式并沒有什么好處。我很少看到完全照搬的代碼能夠成為一個好的設計。好的設計是什么？我認為，好的設計是開發(fā)者根據(jù)實際要處理的問題，選擇、組合、演化、應用眾多設計方法和技巧，在滿足各類客觀指標的情況下，構(gòu)建出高效靈活的解決方案實現(xiàn)。注意，我這里說的并不是在一個類中所運用的那一小塊模式代碼，而是至少針對于模塊的系統(tǒng)化設計。設計的自由開放是為了什么，這就是原因，根據(jù)問題求解，發(fā)揮出我們的生產(chǎn)力和創(chuàng)造力，構(gòu)建出優(yōu)秀的解決方案。

以上的所有，歡迎大家共同探討和合理拍磚。

附件中有文章中提到的我先前編寫的《Java編碼參考規(guī)范》（已變更為1.0版本），僅供參考。當然也希望大家對其中的細節(jié)提出自己的建議和意見。