項目隨着時間的推移，開發人員換過了一波又一波，項目的代碼被一些代碼風格「狂野」的新同窗們「強姦」了一遍又一遍。咱們遊戲服務器代碼從09年時的50W行激增到如今的200W行，不得不讚嘆：「還真是能寫啊！」。代碼混亂的程度，簡直不忍直視：風格迥異的命名方式、得以米計算長度的函數、各類MagicNumber，讓人摸不着頭腦、缺乏封裝致使的大量重複代碼、各類奇葩的縮進方式、擁擠在一堆，就不知道敲個空格或空行會浪費多少時間啊...。程序員
更多內容：http://game-lab.org/posts/zoc-cleancode-1/服務器
是誰製造了混亂？
是程序員的做繭自縛，和項目對於規範的不重視。函數
遊戲開發對於策劃或產品他們來講，他們是不會看到代碼的，更不會關心代碼質量和整潔的。他們只會要求你實現了某個功能，這份代碼幫他們賺了多少錢，快速、保質保量地實現他們提出的各類需求。需求永遠不會中止，而且還都有嚴格的時間節點。最終致使的開發團隊，都疲於奔命，功能都寫不完，還有誰會在意規範這件事情。「能把功能實現就好了！」，這是多數人的想法。post
這樣的狀況，存在一個惡性循環：無止境的需求->趕時間些的缺少規範代碼->製造混亂->仿照混亂的代碼製造更多的混亂。 最終就是：更多的需求->更亂的代碼。優化
歸根結底，代碼是咱們本身寫的，經驗不足，缺少規範和前輩的指導，每每會養成很差的習慣。因爲：編碼
-
規範的缺失，在寫代碼的時候，沒有規則可依，只能按照本身的喜愛來，或者仿照前輩們的代碼風格，致使了各類風格迥異的代碼，第一眼看過去就不想再讀下去了。設計
-
沒有常常進行重構，致使了混亂的設計，和持續積累的惡臭代碼。code
混亂引發了很多麻煩
面對遺留系統，先輩的各類「神做」和本身作的孽，致使：遊戲
-
修改已有功能的時候，很容易摸不着頭腦，一頭霧水。要想在原有系統上修改點東西，邁出任何一步，都如履薄冰，不得不當心翼翼，一不留神就掉「坑」裏面了。每每很容易聽到，接受這樣任務的同窗們的嘆息和咒罵！遊戲開發
-
查BUG得時候，那叫一個大海撈針啊！沒有GDB，估計早都撞牆了，有些時候就算是有GBD也得折騰個半天才能有點眉目。不過你們戰鬥力均可以，通過幾番折騰，都仍是找獲得。
-
添加新功能的時候，特別是新同窗，看着前輩的神都看不懂的代碼，只知其一;不知其二，只能摸着石頭過河了，或者就照貓畫虎，再加點本身獨特的風格。恭喜，您又把代碼給「強姦」了一遍。
該是「救贖」的時刻了！
面對如此規模代碼，想作點重構，每每望洋興嘆，不知從何下手。曾經不知有多少次有此想法，又多少次放棄。
需求不止，混亂不息！打破這個惡性循環的槓桿就在：制定規範，和養成重構的習慣
- 添加新需求的時候，儘可能遵循規範和代碼整潔的編碼原則；在寫完代碼準備入庫的時候，能簡單的整理一遍是最好的了。
- 在修改BUG、優化功能的時候或抽空，找出混亂的代碼，來一次重構，養成回頭看的習慣。
小結
代碼就是程序員的孩子，也是程序員的一張臉，代碼是些給人看的，不是寫給本身孤芳自賞的，更不是寫給編譯器，讓編譯器認識就行的！
代碼的「救贖」是整個開發團隊的事情。制定規範，並遵照之；養成重構的習慣。只要造成這個良性循環，再混亂的代碼，也會向着一個整潔的方向在演化，
整潔代碼，指日可待！！(PS. 3周時間，咱們團隊已幹掉10W多行廢棄的代碼，這個數字對於手遊和一些APP，基本上算是所有代碼了)
究竟是誰在做惡？是咱們本身！！