iOS開發--從細節做起寫乾淨、清晰的代碼

     細節和架構一樣重要！

     耐住性子，這篇文章不會有代碼出現，要的無非兩個字，乾淨，一定要苛刻的要求乾淨
     你是否有時候自己的代碼自己都不想看？你是否有過改過幾次需求之後，你的工程已經完全負擔不起下一次改動了？
你有沒有見過幾百甚至幾千行的代碼，你有沒有看過一些代碼，裏面都是些a1,a2,a3這樣的變量或者方法？你有沒有和同事合作時，有些人的代碼你喜歡看，有的人的代碼你不敢看？你有沒有遇到過有的同事如果離職，他的代碼不會有人接手，只能廢棄重來？

     曾經我以爲是架構的問題，是經驗的問題，是技術水平的問題，我花了很多時間去學習框架，我覺得一個優美的框架可以解決一切問題，可惜最後發現，這遠遠不夠。

     把設計、架構這些暫且拋開，這裏只說一個詞，乾淨！
 
     一定要拼了命的乾淨！

     我是相當痛恨混亂無序的代碼，教訓太慘痛了。這裏我想借用 《代碼的整潔之道》 這本書裏面名家說的話。

1. 我喜歡優雅和高效的代碼。代碼邏輯應當直截了當，叫缺陷難以隱藏；儘量減少依賴關係，使之便於維護；依據某種分層戰略完善錯誤處理代碼；性能調至最優，省得引誘別人做沒規矩的優化，搞出一堆混亂來。整潔的代碼只做好一件事。
   
2. -Bjarne Stroustrup，C++語言發明者

複製代碼

1. 整潔的代碼簡單直接。整潔的代碼如同優美的散文。整潔的代碼從不隱藏設計者的意圖，充滿了乾淨利落的抽象和直截了當的控制語句。
   
2. -Grady Booch，Object Oriented Analysis and Design with Applications（中譯版《面向對象分析與設計》）一書作者。

複製代碼

     我無意做概念上的抄襲，只是今年在做去年開發的總結的時候，對代碼加入了一些自己的要求，這個要求對交給我現在的同事和以後組裏新來的人手裏，作爲項目組開發的基本規範執行。然後這個時候接觸了《代碼的整潔之道》這本書，有點醍醐灌頂的感覺。那些基本要求做了修改，現在是這個樣子，大家可以看一下，這個是我純主觀的想法，如果有不同的意見歡迎討論。

   1,命名，命名就是註釋。
        用駝峯法，比如 doSomething
        類名：頭字母大寫
        方法名：頭字母小寫
        局部的子方法裏允許 int i這種，但是常用的方法中，必須寫成 int xxxIndex
        臨時變量命名        tmpXXX
        然後，如果發現命名不對，或者後來發覺其他命名方式更好，用項目的命名修改工具修改

   2,方法（函數）
        方法名一定要能做註釋，如果必要，加方法註釋，如果IDE允許，一定是那種別人在引用你的方法的時候了可以直接看到的註釋（這裏解釋一下，      記得java中可以通過在函數前面加/**xxx*/加註釋，這樣當方法提示的時候，會自帶這種註釋提示，xcode,mono都有類型的功能）
        一個方法只做一件事，儘可能這樣，如果一個方法做了n多事，拆分。
        一個方法不允許出現大於100行的情況，正常50行以內(這個要求已經很寬泛了)，如果大於100，拆分，沒有時間，自己找時間拆分
        方法內，相關的代碼寫在一起，不要有空行，相關度小的，留一個空行
        良好的縮進，這裏不做強制要求，採用兩種縮進中的一種，根據個人習慣
        能私有的方法一定要私有，不要讓大家看到(OC是通過類別來實現的)
        多用代碼組的工具，並加入清晰的註釋
        （Xcode中，是通過 #define mark xxx註釋 來讓方法分組的）
        （Unity3d中的mono工具是 #region xxx註釋 #endregion）

   3,註釋
        如果命名能做註釋，就不要註釋
        如果不得不做註釋，儘量是那種別人調用的時候可以直接看到的註釋
        類的每一個和其他類有關聯的成員，都寫上註釋
        如果一個註釋已經過時了，刪掉或修改掉

//以上1,2,3 針對團隊所有人

   4，關於框架
        每一個類儘量只做一件事或一類事
        少用繼承，多用組合
        類內高內聚，類之間低耦合
       UI和數據分開，如果有足夠的時間，把處理邏輯也分開寫
    5，重構
        唯一不變的就是變化，遊戲開發尤其如此，適當的時候，提出重構
        頻繁，多次，自己抽時間做重構
    6，關於合作
        對每一個人做的東西，讓他有一個系統的概念，不要今天做這一塊，明天做那一塊
        合作尤其要求代碼的可讀性，一定要讓自己的代碼別人可讀
        如果你是一個程序員，做好自己的代碼，如果你負責很多人，讓每一個人寫好自己的代碼，然後，你寫好清晰的接口
        和策劃談需求時儘量搞清楚，開始做的時候去白班上畫圖，讓開發者都清晰的知道設計思路和每個人做什麼
        誘導爲主，拒絕依賴性的問問題，這個態度一開始就要讓問問題的人知道

      很多時候，需求的變動和時間的壓力會讓一個開始很乾淨的工程慢慢變得一塌糊塗，沒有捷徑，除了細節上的注意，就是一遍又一遍的重構。個人認爲項目中絕大多數時間是在維護代碼，而不是寫新代碼，既然要維護，能夠一眼看清的代碼是最好的，而團隊合作又會把代碼的可讀性問題無限制的放大，尤其是遇到一些很聰明常常自作主見和一些偷懶的人的時候。基本的規範是一定要遵守的，而這個習慣也會有助於程序員越走越遠。每一次重構都是一次脫胎換骨的涅槃，其中的痛，只有身在其中的人知道，很多時候都是自己在下班時間做的。
        

   補充內容 :
      補充一點，xcode裏面開發程序的時候，自己寫的代碼，warning，第三方的，warning處理到 個位數，或者全部處理掉
      繼續補充一點，咆哮同學說，這整篇文章說的都是微操，至於架構，那是大局觀的問題，打dota或者魔獸對戰或者星際的同學們一定懂的。大局觀神馬的，我還差蠻多呢