從程式碼看一個程式設計師的筆力

從程式碼的整潔度上就可以看出一個程式設計師的實力，規範其實就是讓你養成一種良好習慣的標杆，在此面前我們應該順從。本篇我們以OC為例，統計了一些在編寫程式中需要注意的事項，共有20條，當然還有更多的規範，此處只是做個示例。

• 單頁程式碼最好控制在800行以內，每個方法最好不要超過100行，過多建議對程式碼進行重構.   見過一個2000+行的類,這酸爽

• 相同的邏輯方法定義避免在多個地方出現，儘量將公用的類、方法抽取出來

• 刪除未被使用的程式碼，不要大片註釋未被使用的程式碼，確定程式碼不會使用，請及時刪除

• 對其他專案中copy過來的程式碼，根據具體需要更新程式碼風格，及時刪除未被使用的程式碼

• 專案中所有Group或者檔名稱（圖片名字等），不要使用漢字命名，儘量使用英文命名，國內特有名詞可以使用拼音。

• 專案中所有Group都需要在專案目錄中存在一個真實的目錄，Group中的檔案與真實目錄中檔案一一對應。

• 請在專案中寫必要程式碼的註釋

• 請多使用 #pragma mark - Mark Name 對方法進行分組 。如:

• 針對不同檢視控制器，在末尾新增字尾，如： UIButton 字尾新增“Button"或大家皆知的簡寫，NSArray的變數命名為xxxArray等。

• 類、方法、屬性等命名，做到見名知意，採用駝峰式命名規則。

• 根據資源型別或者所屬業務邏輯對專案資源進行分組，使得整個專案結構清晰明瞭；整個專案保持一種程式碼書寫風格。

• 避免在程式中直接出現常數，使用超過一次的應以巨集定義的形式來替代。常數的巨集定義應與它實際使用時的型別相一致。如以3.0來定義浮點型別，用3表示整型。 常量的命名應當能夠表達出它的用途，並且用大寫字母表示。例如：

• 當使用條件語句編碼時，不要巢狀if語句，多個返回語句也是OK。  儘量避免業務邏輯寫在一個if巢狀裡,很難看,很難改,多個少個"}",讓你瘋狂

• 當引數過長時，每個引數佔用一行，以冒號對齊。如：

• 一行很長的程式碼應該分成兩行程式碼，下一行用兩個空格隔開

• 刪除多餘的空行，所有方法與方法之間空1行，所有程式碼塊之間空1行。變數聲明後需要空1行，如果需要分類區別，各類別之間空1行。條件、迴圈，選擇語句，整個語句結束，需要空1行。最後一個括弧之前不空行。註釋與程式碼之間不空行。

• 每行程式碼最多不得超過100個字。

• 圖片命名：採用單詞全拼，或者大家公認無岐義的縮寫(比如：nav，bg，btn等)；採用“模組+功能”命名法，模組分為公共模組、私有模組。公共模組主要包括統一的背景，導航條，標籤，公共的按鈕背景，公共的預設圖等等；私有模組主要根據app的業務；功能模組劃分，比如使用者中心，訊息中心等。建議背景圖採用以bg作字首，按鈕背景採用btn作字首。如：[email protected]，[email protected]等。

著手一個新專案條理

在著手一個專案前先讀文件（如果有文件的話）。儘管讀了文件你不一定知道每一個程式碼的細節，但是如果你瞭解那個問題的話，你一定知道怎麼寫可以寫出一個滿足文件的內容。這個時候大腦裡面就可以有個框架，先猜一猜，然後看程式碼，事半功倍。找不到好的文件，就看他的測試用例，也是有一樣的功效的。因為測試都是從文件出發編寫的，而不是從程式碼出發編寫的。找不到文件和測試用例？那就直接Gank吧。  

我接受的專案都沒有文件,怎麼看呢?  先隨手把玩一下這個app,看看有什麼功能,猜一猜上一任是怎麼寫的,然後從專案中找找相關程式碼,找的過程中就順道看了很多其他的程式碼.對整體的把握提高了.     

其實看程式碼和做英語閱讀感覺差不多, 都一定要帶著問題看程式碼(文章),然後找到答案,在找答案的過程中,對專案(文章)有了一定的整體把握了.

讀程式碼要層次化、帶著問題去閱讀。首先整體瞭解這個軟體是幹什麼？解決什麼問題？包含哪些大的模組，各個模組的作用是什麼，各個模組的呼叫關係怎麼樣？然後對於每一個模組，這個模組是幹什麼的？為什麼要有這個模組？這個模組怎麼實現的？最後細化到每一個包，每一個類，每一個函式方法。從上到下，一一擊破每一個問題，認真去思考他這樣設計、寫程式碼的好處，因為好的軟體都會滿足這種從抽象->具體的原則的。

在開始讀具體程式碼前定位好所有要讀的檔案，知道他們的位置和名字，設計良好的工程光看工程的目錄結構和檔名就能知道個大概功能了。    我的做法是用xmind做一個思維導圖,可以方便的找到每個類和整體的設計結構.特別剛開始的時候,可以快速熟悉工程.類似於這樣的.  這個工程比較小,類比較少,以前做的一個,類很多,用思維導圖可以清晰的把框架描述出來.

事實上閱讀程式碼的難易程度70%取決於程式碼書寫的規範程度，寫亂掉的程式碼，大師也讀不懂。之後根據你對目錄結構的理解確定檔案閱讀的順序（我反正都是從main函式開始讀的）。你最好對設計模式有一定了解，否則你讀面向物件的code時會經常無法理解code為啥要弄得這麼層層巢狀。閱讀程式碼一個最重要的提升水平的地方就是理解好的程式碼如何合理使用設計模式。基本的閱讀起點都會選擇main函式或者類的建構函式。然後把自己想象成cpu執行程式那樣去閱讀你的程式碼。遇到需要跳轉函式時，不要急於跳轉，以瞭解函式功能和輸入輸出為目標，讀程式碼最忌諱的是不抓結構抓細節，只見樹木不見森林，比起某個函式具體功能來說對結構的全域性把握更重要。功能瞭解清楚後繼續跳回來（這裡就可以區分程式碼寫的優不優秀，優秀的程式碼光看函式名字就知道功能，連跳轉都不用）。結構弄清楚了，知道程式怎麼跑了，source code的精華你已經讀了60%了，之後根據需要再對具體函式深入分析，到這裡整個程式碼已經被你扒光了，沒什麼神祕了。

閱讀程式碼有兩種模式：top-down 和 bottom-up。Top-down 模式，就是先設定一個 use case，比如說開啟一個檔案。然後靜態跟著程式碼看，或者用 debugger 跟著看。每次出現函式呼叫的時候，把函式的執行層次紀錄下來。大致如下：

這種圖表很隨意，你可以根據自己的需要增加資訊，可以把重要的「實際引數」一直標下來，畫函式呼叫圖，然後標註每個函式在幹什麼。不過這個圖無法清楚地表明一個變數的軌跡，需要另外的圖來標示變數的變化軌跡。要是想提高閱讀程式碼的速度，歸根結底要多讀多寫。熟悉程式的基本構成單元（例如迴圈、分支）的常見寫法，各種lib, api的呼叫方式。這樣閱讀深層次程式碼不用再回頭查形式引數到底指什麼。這個圖的基本作用是防止在閱讀深層次程式碼時忘記總體執行層次。Top-down 模式進行到一定層次，往往會發現雖然圖畫了出來，但還是無法瞭解程式在幹什麼。這時需要轉入 bottom-up 模式，一直深入到最底層，給能瞭解作用的底層函式一個一個的寫文件。當然這時的文件是完全底層的觀點。bottom-up的閱讀方法，有時候會一頭扎進去，出不來了。這種方式適合讀一些比較優秀的開源專案的程式碼，也會很好地提高內功。然後就是不斷在兩個模式之間轉換，不斷的細化兩種模式的理解。

最後，對於OC工程可以去GitHub找UIViewController-Swizzled這個庫，拉下來放到專案裡，他有什麼用呢？他可以把每個頁面的類名打出來。而且有層次結構，也就是說你只需要開啟專案點點點，就知道這個App執行的順序了。

iOS開發的細節及全域性觀

"好程式碼是廉價的"，這句話沒有歧義。中國的語言博大精深，其實這句話的真實含義是，優秀的程式碼使用起來毫不費力。通常我們對好程式碼的定義是優雅的使用各種設計模式，兼顧各種情況（異常或是正常），有效而且合理的使用優化演算法等。很好，這在開發中幫我們做了很多事，這也是在開發中值得發揚的。但是，這難免的會增加實現的複雜性，如果對某些技巧認識不清極有可能成為一種開發的阻礙。實際上，在日常的開發中，我們大多是為了實現功能，很多的都是在寫“廉價的程式碼”，以功能優先，先實現功能然後再根據需要在後期進行優化，這沒什麼不好。

其中一個誤區是，我們需要從邏輯著手而不是功能，這樣固然很好，但卻會影響開發的效率。好的程式設計師和偉大的程式設計師之間的區別就在於偉大的程式設計師理解他們的模式，讓程式碼廉價。當模式能夠給你帶來好處，而且為你省時時才去使用它們，如果不是這樣就不要使用它們。當框架能夠幫你提高開發速度時才使用它們，

在必要的時候重構，不要做一些超前性的開發。這些只是針對於日常開發，編寫SDK或框架是另一套邏輯，總之就是不要抱殘守缺，固守一種形態，學會因地制宜。

一個不好的現實是大多數程式設計師都是業務性程式設計師，每天重複著一樣的工作，寫著功能不同但形式上是一樣的程式碼，這就是普通程式設計師的宿命，因此上面才會為了快速構建而選擇“廉價的程式碼”。但是，這不是有進取精神的程式設計師所想要的，所以我們才會有進步，即使是一個小工也要像專家一樣思考。

那麼，所謂的專家們，在看一個專案時是如何思考的呢，我們下面做一些分析。

優秀的開發者會從架構的視角來看問題，一般而言，軟體系統的架構（Architecture）有兩個要素：

• 它是一個軟體系統從整體到部分的最高層次的劃分。

• 一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要資訊。

架構是一個約定，一個規則，一個大家都懂得遵守的共識。需要強調的是“架構因未來而存在”。架構的最終體現是一個軟體，是模組化，簡潔，可維護，可任意替換，人性化設計，可以把它全部打碎了重新從一個模型自由的再去組裝成另一個模型。是高內聚，低耦合，既可以作為一個完整的可交付模組，也可以“打碎”重組。架構需要考慮的是擴充套件性，安全和效能，如此才算是合理的架構。

在構建專案時，不管採用什麼方法，全域性觀、高度的程式碼審美能力、靈活使用各種設計模式一定都是貫穿其中的。首先，搞清楚業務邏輯，這決定了你的架構是否足夠易用。另外，傳的引數越少，耦合度相對而言就越小，你替換模組或者升級模組所花的的代價就越小。搞清楚業務之間的依賴關係，建立好模組交流規範並設計模組，關鍵在於建立一套統一的交流規範。推演預測一下未來可能的走向，必要時新增新的模組，記錄更多的基礎資料以備未來之需。軟體是有生命的，多一點考慮便會多一分健壯。

好的架構需要下面幾點：

• 程式碼整齊，分類明確 

• 不用文件，或很少文件，就能讓業務方上手

• 思路和方法要統一，儘量不要多元

• 沒有橫向依賴，萬不得已不出現跨層訪問

• 對業務方該限制的地方有限制，該靈活的地方要給業務方創造靈活實現的條件

• 易測試，易拓展

• 保持一定量的超前性

• 介面少，介面引數少

• 高效能

架構師的第一職責是關注非功能性需求，就是對技術的全面掌控，包括TCP/IP協議，加密解密，計算機原理（增補反碼），JPG碼，MPEG2-3協議，邏輯電子電路，計算機編譯器原理（堆、棧、佇列）等。一些底層的東西，才是技術的核心。“技術人材是當下企業的第一生產力”，在處理業務時學會思考，用架構師的思想去思考，即使是一個小工也要有偉大理想。