去年年末，爲我所在的技術團隊編寫了Java編碼規範。其執行過程還算順利，因爲團隊不大，並且大家都希望能夠有這麼一個可供參考的東西。但是在我與其他的團隊交流的時候，有些程序員卻跟我道出了不同的意見。現在我摘出幾條：
1、團隊應該在設計上追求一致，比如一致的業務邏輯、一致的算法，但是在編碼風格上應該帶有些個人色彩，否則就沒有樂趣了。
2、我們每天都有那麼多東西約束我們，比如：上下班要打卡，工作任務即使加班也要按時完成，漲工資不隨心願，頭頭並不能理解我的願望和思想等等。爲什麼還要在編碼風格這麼小的事情上進行約束呢？
3、開發團隊裏規範太多了，連編碼規範都要統一麼？開發組長和技術經理就不應該過多的干涉細節，這樣還讓我們怎樣工作？
聽到這些言語，我很感嘆，因爲我曾經也有過類似的想法。但是我現在想說的是：
1、我們是一個團隊，需要協作、需要共事。項目開發的工作並不是一起玩過家家，更不是一個人自娛自樂。一個標準的編碼規範，有利於團隊的協作，包括代碼共享、交互學習、結對編程、交叉測試、代碼審查等等，更有利於提高大家的工作效率和團隊精神。它就像實現模式一樣讓大家不必爲細小的瑣事而浪費精力，直接按照經過檢驗的慣例來做。它更像設計模式一樣，使大家有一個共同的參考，共同的標準做法。
2、人活在世上，除非有能力和勇氣做一個獨一無二的、創造歷史的牛人，否則就需要遵守社會國家、家庭、公司、團隊的各種規範和制度。但即使是上述的那種牛人也是需要先虛心學習、融入環境，而後才能去創造歷史。所以，我認爲一個組織是需要它自己的規矩的，它的合理與否可以經過商榷和探討，但是它的存在必要性是可以完全肯定的。我相信，一個希望和團隊一起共事、有團隊精神的成員是不會對一般性的規範和制度產生質疑的。
3、就開發工作而言，我所提倡的是：編碼風格的統一，設計風格的自由。每一個項目的設計理念和架構是需要項目技術負責人自己去把控的，只有這樣才能讓大家真正的思考怎樣才能做好軟件設計，這樣才能讓大家真正的在項目中獲得經驗和鍛鍊。然而，對於編碼的風格、父包命名規則、縮進規定等等這類細小的地方不需要、也不值得讓每個程序員去費心選擇，這既不利於工作重點的明確也不利於代碼可讀性的提高。
4、其實，從實現模式和設計模式的概念中，我們可以映射出編碼風格統一和設計風格自由的真正含義。
實現模式，是一些久經歷史驗證的一些慣例和原則。雖然可以根據具體的情況進行調整，但是大多數情況下它已經成爲了大多數開發者們的習慣性行爲。毫無理由的改變，就意味着在交互和溝通過程中需要花費額外精力去解釋和理解。編碼規範就類似於實現模式。
設計模式，也同樣是業界精英們總結出來的好的設計方法。然而，每個項目都有它的特殊性和獨立性。我們需要根據項目需要來做出我們的設計，教科書似的完全照搬設計模式並沒有什麼好處。我很少看到完全照搬的代碼能夠成爲一個好的設計。好的設計是什麼？我認爲，好的設計是開發者根據實際要處理的問題，選擇、組合、演化、應用衆多設計方法和技巧，在滿足各類客觀指標的情況下，構建出高效靈活的解決方案實現。注意，我這裏說的並不是在一個類中所運用的那一小塊模式代碼，而是至少針對於模塊的系統化設計。設計的自由開放是爲了什麼，這就是原因，根據問題求解，發揮出我們的生產力和創造力，構建出優秀的解決方案。
以上的所有，歡迎大家共同探討和合理拍磚。
附件中有文章中提到的我先前編寫的《Java編碼參考規範》（已變更爲1.0版本），僅供參考。當然也希望大家對其中的細節提出自己的建議和意見。