主題：發展
內容大綱
觀點：
- Swift 發展觀
- ReactNative 發展觀
進階：
- 模組化
- Pods 依賴庫及元件化
- 環境自動切換 + 自動化打包測試 + 線上質量監控
管理：
- 團隊核心組成架構
- 硬體裝置投入
- 例會和文件化
- 組織 CodeReview
工具：
- Gitlab 及 Git 相關規範
- Sketch 設計工具 + Zeplin 標註工具
成果：
- Github 原創開源專案 90+，共計 400+ 貢獻力
- 參與維護開源專案 fastlane 20.5k（至2018.02.08）
- 完成 Swifter 功能展示應用研發
觀點
Swift 發展觀
Apple 在 WWDC 2017 大會上釋出 Swift 4，Swift 4 帶來了更快、更容易使用的 String 實現，可以保持 Unicode 的正確性，並增加對建立、使用廣告管理子串的支援，它提高了開發者建立、使用和管理集合型別的能力，它支援結構化列舉型別的歸檔並允許對外部格式進行型別安全的序列化，包括 JSON 和 plist。
既然提到了 WWDC（developer.apple.com/wwdc/），相信 Swift 的發展觀就沒有太多爭議了，近幾年所有的官方演示視訊都是基於 Swift 來演示的，作為 iOS 的開發人員可能會繼續使用 Objective-C，但是如果對 Swift 是持抗拒心理的，那無疑對自身發展是不負責任的。
Apple 於 2017 年宣佈 Swift 5 後會鎖定 ABI，也就標誌著這門語言會正式作為 iOS、macOS 的主流語言。同年 12 月，Apple 宣佈會著手計劃 iOS 和 macOS 的應用層面合併。配合 Apple 一直以來的對 Swift 幼兒教育以及在 AI、AR 等領域的推進，不難看出這門語言未來的發展潛力。
ReactNative 發展觀
提到 ReactNative 就不得不說 FaceBook，其實現在主流的移動端開發規範就是這家公司設計的。當然除了 React 社群生態圈的加持和 Facebook 的大力推廣以外，另外一個最主要的原因就是其在開發效率和應用效能方面取得了一個比較好的平衡：
- 開發效率通過 JS 工程實踐，邏輯跨平臺複用得到極大提升
- 效能則通過全 Native 的 UI 層得到滿足
跨平臺這一特性對於小公司的吸引力則更體現在節約用人成本上，對簡單的需求能做到一端多用，隨時變更線上內容。
對於已經正在運營的專案，完全切 ReactNative 總是不太現實，其實大多數廠商的方法是對運營引流有影響的關鍵性頁面（如：首頁）進行 ReactNative 改版，這裡可能就會引入一個 模組化 的概念，後面會有講到。
對於想要入門的朋友，慕課網上一個入門級 ReactNative 教學還不錯。
教學視訊：coding.imooc.com/class/89.ht…
進階
模組化
模組化、元件化我後半年一直在調研的課題，對這些的研究也給我帶來了從量變到質變的提升。
什麼是模組化？
那麼什麼是模組化呢？《 Java 應用架構設計：模組化模式與 OSGi 》一書中對它的定義是：模組化是一種處理複雜系統分解為更好的可管理模組的方式。
我們可以把軟體看做是一輛汽車，開發一款軟體的過程就是生產一輛汽車的過程。一輛汽車由車架、發動機、變數箱、車輪等一系列模組組成；同樣，一款大型商業軟體也是由各個不同的模組組成的。
汽車的這些模組是由不同的工廠生產的，一輛 BMW 的發動機可能是由位於德國的工廠生產的，它的自動變數箱可能是 Jatco（世界三大變速箱廠商之一）位於日本的工廠生產的，車輪可能是中國的工廠生產的，最後交給華晨寶馬的工廠統一組裝成一輛完整的汽車。這就類似於我們在軟體工程領域裡說的多團隊並行開發，最後將各個團隊開發的模組統一打包成我們可使用的 App 。
一款發動機、一款變數箱都不可能只應用於一個車型，比如同一款 Jatco 的 6AT 自動變速箱既可能被安裝在 BMW 的車型上，也可能被安裝在 Mazda 的車型上。這就如同軟體開發領域裡的模組重用。
到了冬天，特別是在北方我們可能需要開著車走雪路，為了安全起見往往我們會將汽車的公路胎升級為雪地胎；輪胎可以很輕易的更換，這就是我們在軟體開發領域談到的低耦合。一個模組的升級替換不會影響到其它模組，也不會受其它模組的限制；同時這也類似於我們在軟體開發領域提到的可插拔。
20180906 更新 再談模組化、元件化、外掛化定義
- 模組化：一個可實現的單元，核心是內聚和分離，如登入模組的抽離
- 元件化：也稱構件，最理想情況下是與業務無關，強調複用，如可複用 Library
- 外掛化：與元件化不同，元件化在編譯時合併模組，外掛化在執行時合併模組，如可實現遠端替換功能
模組化分層設計
上面的類比很清晰的說明的模組化帶來的好處：
-
多團隊並行開發測試；
-
模組間解耦、重用；
-
可單獨編譯打包某一模組，提升開發效率。
在《安居客 Android 專案架構演進》這篇文章中，作者介紹了安居客 Android 端的模組化設計方案，這裡作者還是拿它來舉例。但首先要對本文中的元件和模組做個區別定義：
-
元件：指的是單一的功能元件，如地圖元件（MapSDK）、支付元件（AnjukePay）、路由元件（Router）等等；
-
模組：指的是獨立的業務模組，如新房模組（NewHouseModule）、二手房模組（SecondHouseModule）、即時通訊模組（InstantMessagingModule）等等；模組相對於元件來說粒度更大。
針對模組化作者的團隊也定義了一些自己的遊戲規則:
-
對於 Business Module Layer，各業務模組之間不允許存在相互依賴關係，它們之間的跳轉通訊採用路由框架 Router 來實現（後面會介紹 Router 框架的實現）;
-
對於 Business Component Layer，單一業務元件只能對應某一項具體的業務，個性化需求對外部提供介面讓呼叫方定製;
-
合理控制各元件和各業務模組的拆分粒度，太小的公有模組不足以構成單獨元件或者模組的，作者先放到類似於 CommonBusiness 的元件中，在後期不斷的重構迭代中視情況進行進一步的拆分;
-
上層的公有業務或者功能模組可以逐步下放到下層，合理把握好度就好；
-
各 Layer 間嚴禁反向依賴，橫向依賴關係由各業務 Leader 和技術小組商討決定。
自從 Oasis Feng 在去年的 MDCC2016 上分享了模組化的經驗後，模組化在 Android 社群越來越多的被提起。作者自然也不落俗的去做了一些研究和探索。安居客現在面臨很多問題：例如全量編譯時間太長（我這臺13款的 MacBook Pro 上打一次包得花十多分鐘）；例如新房、二手房、租房等等模組間耦合嚴重，不利於多團隊並行開發測試；另外在17年初安居客重新將租房 App 撿起推廣，單獨讓人來開發維護一個三年前的專案並不划算，所以作者希望能直接從現在的安居客使用者端中拆分出租房模組作為一個單獨的 App 釋出上線。這樣看來模組化似乎是一個不錯的選擇。
所以作者做模組化的目的大致是這樣的：
-
業務模組間解耦
-
單個業務模組單獨編譯打包，加快編譯速度
-
多團隊間並行開發、測試
-
解決好租App需要單獨維護的問題，降低研發成本
關於模組化元件化的生動解讀來自安居客 Android 組組長張磊的部落格 baronzhang.com
Pods 依賴庫及元件化
元件化與模組化 安居客的 Android 團隊內部成立了技術小組，基礎元件的開發是技術小組很重要的一部分工作；模組化更多的是現有的方案受到來自業務上的挑戰以及受到了 Oasis Feng 在 MDCC 上的分享和整個大環境的啟發，現在正處於設計規劃和 Demo 開發的階段。
元件化 元件化不是個新概念，通俗的講元件化就是基於可重用的目的，將一個大的軟體系統拆分成一個個獨立元件。
元件化的帶來的好處不言而喻：
-
避免重複造輪子，節省開發維護成本；
-
降低專案複雜性，提升開發效率；
-
多個團隊公用同一個元件，在一定層度上確保了技術方案的統一性。
現在的安居客有是三個業務團隊：安居客使用者 App、經紀人 App、集客家 App。為了避免各個業務團隊重複造輪子，團隊中也需要有一定的技術沉澱，因此元件化是必須的。現在我們需要提供更多的、職能單一、效能更優的元件供業務團隊使用。根據業務相關性，我們將這些元件分為：基礎元件和業務元件。
阿里架構組同樣是元件化的先驅者，以下是阿里架構組 Evans 對元件化的觀點：
首先，我的理解分塊化應該是有四種，元件化+模組化+外掛化+解耦
第一，元件和元件其實是沒有什麼鬼明確的約束 ，因為元件一般都是單獨開發、單獨測試，不能直接放到主專案中開發，測試也是單獨針對性的測試 （裡面涉及到短鏈+元件的生命週期+....）
第二，模組化我的理解是，怎麼做好project的模組化的拆分，我們內部一直在說越底層的模組，應該越穩定，越抽象，越具有高複用度，但是其實有一個壁壘就是怎麼去提升模組的複用度，怎麼去快速具備複用性高於程式碼複用性，這我們就要做好每個模組只做好一件事情，模組化結構要更加清晰，每個模組都只做一件事情，具有良好的延展性和擴充性，但願不要出現下層模組依賴上層模組的現象，業務模組之間也儘量不要耦合。好處是同樣的功能模組，可以在多個app中複用，業務隔離了跨團隊開發程式碼控制和版本風險都變小了。
第三，解耦其實理解很簡單就是在基於模組設計原則上, 讓模組之間沒有迴圈依賴, 讓業務模組之間解除依賴，不相互呼叫。
概況的理解就是
- 元件化：單獨開發、測試、維護的開發模式
- 模組化：對 Project 進行拆分，根據業務、功能進行分類
- 解耦：模組設計原則上, 讓模組之間沒有非必要依賴
而元件化現在主流的做法是通過 CocoaPods 對要包裝的內容進行打包，提交到公司的私有庫（開源專案是公有庫），進行日常維護及開發。
環境自動切換 + 自動化打包測試 + 線上質量監控
環境自動切換
Debug 和 Release 僅僅是編譯選項的不同，那麼為什麼要區分 Debug 和 Release 版本呢？
Debug 和 Release，主要是針對其面向的目標不同的而進行區分的。
Debug 通常稱為除錯版本，通過一系列編譯選項的配合，編譯的結果通常包含除錯資訊，而且不做任何優化，為開發人員提供強大的應用程式除錯能力。
而 Release 通常稱為釋出版本，是為使用者使用的，一般客戶不允許在釋出版本上進行除錯。所以不儲存除錯資訊，同時，它往往進行了各種優化，以期達到程式碼最小和速度最優。為使用者的使用提供便利。
對於一些企業版應用或者有內部測試的需求其實還可以新增 Beta 版，收集核心使用者的建議或者測試新開發的功能模組，對反饋做出迅速反應，靈活控制。
由於之前引入了元件化開發模式，所有我又加入了 UnitTest（單元測試）模式，只要用於對元件的分離化測試，快速定位問題。
切換環境的同時會對應切換應用的圖示，能有效避免測試環節中的環境混淆和降低辨別成本。
自動化打包測試
關於自動化打包就不得不說在創業公司的經歷，那時開發任務重，提測前常常加班到晚上 12 點，就算 bug 修完，也要等半個小時看著 Xcode 不慌不忙的打包完成上傳測試平臺發郵件才能安心回家。
鑑於這種慘痛經歷，利用閒暇時間就搞了個自動打包指令碼，後期又整理一遍並適配 Xcode 8.2 之後的版本。 做的了三步配置，杜絕汙染，一行命令自動上傳。
也是鑑於 Xcode 版本升級後的苦逼適配經歷，最終選擇了開源的 fastlane 包，從此搭上了組織的小火車，配合 Testflight 終於可以放心的玩耍了...
FastLane 是一種配置 iOS 和 Android 自動化 Beta 部署和釋出的最簡單的方法之一。它可以簡化一些乏味、單調、重複的工作，像截圖、程式碼簽名以及釋出 App。也能無縫銜接蒲公英、Fir等測試平臺，這酸爽...
-
省時：每次將新版本推送到商店或Beta測試服務時，都可節省時間。
-
整合：整合當前開發環境中所有存在的工具和服務。
-
開源：100%基於MIT許可開源。
-
簡單：簡單的設定助手，幾分鐘配置即可使用。
-
執行：基於你的app和資料，執行在本地機器上。
-
CI：整合幾乎所有CI系統。
-
支援：支援iOS、Mac以及Android 應用。
-
自定義：根據自身需要擴充套件和定製fastlane，不依賴任何人。
-
命令列：不需要記住除fastlane以外的任何命令。
-
配置：可以在任何電腦上配置，包括CI伺服器。
對於 Testflight，就像沒故事的卓同學所說的。
Testflight 有個較大的使用門檻，需要收集使用者的郵箱，之後在 Testflight 裡輸入蘋果發出的邀請碼才能開始測試。很多使用者嫌麻煩就退出了，運營認為這樣會給測試帶來很大的不便。但是冷靜了心態後其實事情並沒有那麼糟糕。真正對這個產品有興趣的使用者不會因為要填個郵箱就放棄了。那些流失的只是普通的使用者。使用者使用了 Testflight 後，後續的測試包的釋出也會收到更新。不會像企業版那樣，只能手動的告訴使用者我們有新的測試包。當 beta 測試活躍使用者超過 100 個會有一個質變。這些都是積極的重度使用者，一群重度使用者使用你的新版本幾天，至少可以保證核心業務邏輯是沒有紕漏的。
這裡推薦配合測試的 SDK 質量監控服務——Bugtags，Bugtags 可以通過懸浮窗或者搖一搖的方式進行截圖，並將捕獲的 bug 圖片上傳到測試平臺，其自身也包括 Crash 的自動上傳。
線上質量監控 Crashlytics 成立於2011年，是專門為移動應用開者發提供的儲存和分析應用崩潰資訊的工具。
- Crashlytics 不會漏掉任何應用崩潰資訊。在發生崩潰後，使用者再次進入 APP 並聯網情況下，日誌自動上傳。
- Crashlytics 可以象 Bug 管理工具那樣，管理這些崩潰日誌。例如：Crashlytics 會根據每種型別的 Crash 的出現頻率以及影響的使用者量來自動設定優先順序。對於每種型別的 Crash，Crashlytics 除了會像一般的工具提供 Call Stack 外，還會顯示更多相關的有助於診斷的資訊，例如：裝置是否越獄，當時的記憶體量，當時的 iOS 版本等。對於修復掉的 Crash 日誌，可以在 Crashlytics 的後臺將其關掉。
- Crashlytics 可以每天和每週將崩潰資訊彙總發到你的郵箱。
- 提供線上的報告，解釋崩潰原因，甚至能給出是哪一行程式碼導致的崩潰。
Crashlytics 有配套的 macOS 應用 Fabric 使用者體驗值得國內 SDK 服務商學習。
2013 年 Twitter 對 Crashlytics 進行人才和服務的多重收購，一年後 Google 收購 Firebase，從此 Fabric 和 Firebase 這對好基友就成為了應用崩潰報告的黃金搭檔。
管理
團隊核心組成架構
關於團隊的觀點，我基本和沒故事的卓同學看法一致，除了技術的硬指標，在早期團隊還有一個工程團隊文化的問題。一個幾十個人的專案，裡面某個特定的人的積極性對於專案其實是不太重要的。他只要完成應該完成的工作。甚至和其他人不說話也影響不大。一個大的專案也不能因為任何一個人不在了就執行不下去。
我之前思考過團隊文化是什麼，怎麼形容團隊文化。後來看到一個說法感覺挺貼切。文化是空氣，無處不在。公司沒有規定下班後社交平臺上看到使用者反饋需要你去回應，也不會規定你發現其他部門的產品有問題是不當回事還是應該去和其他部門的人溝通，又或者看到一個更好的建議是不是要和公司提出來。這些行為背後的支撐就是團隊文化。在團隊裡的人決定了價值觀。
技術團隊做事就像古代的八抬大轎，公司業務就像轎子裡的小娘子，團隊文化就像抬轎子時喊的號子，團隊裡的每個人就像是抬轎子的車伕。抬轎子的大多數人走的快，每個人的步子齊，那轎子裡的小娘子就坐得很舒服，如果哪個環節出現問題都會對坐轎子的人有影響。
所以，車伕水平要挑好，號子要響亮提氣，每個人的步伐要協調，轎子就能平穩上路，可是如果想快點趕路，那可能就要嘗試不同的抬轎姿勢，換更響亮的號子，排練更協調步子，甚至換個更輕的轎子、換個輪子...
硬體裝置投入
接著上面的“花轎”說，硬體投入的重要性就不言而喻了，別人已經換上了帶輪子的馬車了，當然跑的飛快。
拿 Swift 的編譯速度講，MacBook Air 和 MacBook Pro 的處理器晶片和記憶體容量決定了兩種電腦的編譯耗時可能相差1倍左右，而一塊外接螢幕能節省的頻繁操作更是以少積多。
如果把一個工程師的薪資換算成時薪，配合硬體裝置浪費掉的時間，將是一筆不那麼明智的開銷，當然如果你的工程師每天只是喝涼水看新聞，那請配給他一個保溫杯和老花鏡~
例會和文件化
有哪些會？
當我打算寫這個主題時，反思了下過去都參加過哪些會議，發現有時會莫名其妙的就參加了一些完全無意義的會議。下面我們先看看一般程式設計師都會碰到哪些會議。
需求會
這類會議一般是產品或專案經理召集，組織參與專案的程式設計師一起討論需求並確定排期。這類會議容易出的問題是，程式設計師到了會上才第一次知道需求，並陷入到需求細節的無休止討論中。更好的方式是提前讓程式設計師詳細瞭解需求，會上只需敲定排期並讓互相有協作依賴的程式設計師之間達成一致和形成承諾。
討論會
這類會議的場景比較廣泛，比如：專案進行過程中同組程式設計師之間就設計或實現的討論，或與其他組專案合作人之間的討論等等。這類會議容易出現的問題是臨時把一堆人拉到會上，然後陷入混亂的自由討論，失去焦點。
還有一類討論會叫頭腦風暴會，也是容易把一堆人拉到會上，開動頭腦風暴。如今遺憾的領悟到這是最沒效率也沒效果的方式。頭腦風暴會需要就待解決的問題讓參與人員提前準備，蒐集或閱讀材料，不同人從不同角度各自提出自己的觀點或方案，然後到了會上將所有觀點和方案列出來，再開動頭腦，碰撞連線一下，看看能不能風暴出一些新的觀點或方案去有效解決問題。
周例會
一般來說一個部門或小組都會每週開個例會，例會容易被當作日常的例行工作而不被重視。例會應該有固定的時間和議程，而且例會是一群經常一起工作並熟悉的人開會。雖然開例會的人都在同一個部門，但並不意味著他們都會相互合作完成同一個專案或事情。所以，例會是通過了解各自工作來完成了解整個部門或小組工作進展的機會，而不是每週固定的休閒時光。當然我們也可以在每週的例會留出一段自由討論時間，可以暢所欲言，增加工作之外交流。
除了周例會，有些實施敏捷方法的團隊也會開每日站立會，每日站立會的一般內容是：
- 昨天干了什麼
- 今天計劃幹什麼
- 遇到了什麼障礙
每日站立會議的主要目的是讓團隊成員互相交流互通工作情況，而不是為了讓經理們瞭解情況而召開的會議。每日站立會不是一個團隊的人站一圈各自說下工作情況，因為曾經發現彼此並不關心對方工作內容的人站一圈開這個站立會，其意義何在？
分享會
部門內、公司內或行業內都會有各類不同規模分享會，想清楚你為什麼要去參加一個分享會？一般來說我只有兩個原因，我對分享的內容感興趣，這應該是大部分人蔘會的原因。另一個，即使分享內容我已經很熟悉，那麼參會的原因一般就是對分享人感興趣，想要去通過這個分享瞭解分享人。
還有一種情況可能是礙於面子參加一些完全沒興趣的分享會，恩，這種還是儘量規避吧。
臨時會
總會碰到這種情況，突然有個人過來叫你臨時去參加個會，然後你就一臉懵逼的去了。這種會似乎屬於身不由己，不好規避，這類會議多是非計劃性的任務驅動型會議。英特爾前 CEO 安迪·葛洛夫說過：
在現實中，有 20% 的情況還得靠任務導向會議來解決。但如果經理人將超過 25% 的時間用在應急的任務導向會議上，這個組織就一定有了毛病。 這種型別的會議隨時召開，而且會針對具體情況產生決策，若這種臨時緊急的任務驅動會議太多了，那問題肯定出在平時的工作中。
總結會
可能是專案上線或產品釋出後的總結會，也可能是線上故障後的經驗教訓總結會。我以前開過的很多總結會都變成了領導的總結會，關於這類會大家有什麼好想法嗎？
對於以上這些千奇百怪的會議，於是有人制作了這幅漫畫：
其實呢，凡事都有兩面性，最難把控的永遠是人，作為有效的討論活動，會議本事沒有問題，精耕細作也會在一定程度上保證質量。重要的是會議的氣氛、主題以及控場力。
高效會議的三個要訣： 1.提前通知議題併發給參會人相關資料，不要求可參加可不參加的人 2.會議必須有主持人，引導大家時刻盯住會議主題 3.要有會議紀要，會後對會議結論、行動計劃、負責人、進度表和考核目標的提煉總結
我之前遇到一個專案領導就很有特色，由於採取封閉式敏捷開發模式，需要每天確定工作內容，調節各部門間工作進展，所以需要每天做午會，但是當時並不枯燥而且團隊協作融洽，因為在例會過後有組織抽籤買飲料、零食和懲罰倒黴鬼的活動，如今想來，他確實是一個優秀的組織者。
以上這些會議內容來自部落格園的 mindwind，讓我們同情他一刻鐘~
文件化 文件化和例會一樣是充滿爭議的舉措，本質上是為了讓一切有據可查，方便後期查閱和減少交接工作負擔。但也不乏反對者，認為是在浪費時間，形勢主義。
還是一樣的道理，穩定的方法不會錯，難把握的是個人。把每一個賬號密碼整理儲存也是文件化。保持會議記錄、工作聊天日誌也能在必要時不接受飛來的橫“鍋”~
組織 CodeReview
還是引用沒故事的卓同學的話，Code review 是一件神奇的事情。所有有素養的工程師都覺得 code review 好，據我們所知國外很多優秀的 IT 企業都很注重 code review，但是在國內卻很少看到有團隊執行 code review。或者中小團隊裡很少看到 code review。
作為一個 leader，在 review 的時候幫助成員成長，和只是看下程式碼是不是能完成功能最後會引向不同的結果。看過一句很有觸動的話，現在很多 leader 知道自己的工作裡需要管理其他人，但是卻忽略了還需要 lead 。 老實說推進 code review 確實遇到很多阻力。有團隊裡的也有團隊外的。團隊外的看法是 code review 拖慢了專案進度。我作為一個核心的開發成員，每天超過 20% 的時間是沒有可見的工作產出的。有時別人寫的有問題被我打回去改，一個已經完成的功能又多花了幾個小時。團隊內遇到的問題是，很多成員不理解這項工作背後的價值。
同樣的感觸來自上面提到的那家公司，負責我們的小組組長是一名有著 6 年移動端開發經驗的優秀工程師，在一套嚴格的程式碼規範要求和 code review 的鍛鍊下，我的成長几乎是肉眼可見的（對比回看之前的程式碼），他對我們的指導也是無私且專業的，以至於我現在依然在感謝著他。
CodeReview 的方式
- 開 Code Review 會議
- 團隊內部會整理 Check List
- 團隊內部成員交換程式碼
- 找出可優化方案
- 多問問題，例如：“這塊兒是怎麼工作的？”、“如果有XXX 情況，你這個怎麼處理？”
- 區分重點，優先抓住設計，可讀性，健壯性等重點問題
- 整理好的編碼實踐，用來作為 Code Review 的參考
CodeReview 的內容
[1]架構/設計/常規 1.單一職責原則 這是經常被違背的原則。一個類只能幹一個事情，一個方法最好也只幹一件事情。比較常見的違背是一個類既幹UI的事情，又幹邏輯的事情，這個在低質量的客戶端程式碼裡很常見 2.行為是否統一，例如： 1)快取是否統一 2)錯誤處理是否統一 3)錯誤提示是否統一 4)彈出框是否統一 5)…… 3.程式碼汙染 程式碼有沒有對其他模組強耦合 4.重複程式碼-->應該抽取 5.開閉原則 6.面向介面程式設計 7.健壯性 1)是否考慮執行緒安全 2)資料訪問是否一致性 3)邊界處理是否完整 4)邏輯是否健壯 5)是否有記憶體洩漏 6)有沒有迴圈依賴 7)有沒有野指標 8)是否檢查了陣列的“越界“錯誤 9)…… 8.錯誤處理 9.改動是不是對程式碼的提升 新的改動是打補丁，讓程式碼質量繼續惡化，還是對程式碼質量做了修復 10.效率/效能 1)關鍵演算法的時間複雜度多少？有沒有可能有潛在的效能瓶頸 2)客戶端程式對頻繁訊息和較大資料等耗時操作是否處理得當
[2]程式碼風格 1.可讀性 衡量可讀性的可以有很好實踐的標準，就是 Reviewer 能否非常容易的理解這個程式碼。如果不是，那意味著程式碼的可讀性要進行改進 2.命名 1)命名對可讀性非常重要 2)是否跟系統屬性命名造成衝突 3)英語用詞儘量準確一點，必要時可以查字典 3.函式長度/類長度 1)函式太長的不好閱讀 2)類太長了，檢查是否違反的 單一職責 原則 4.註釋 恰到好處的註釋,不是註釋越多越好 5.引數個數 不要太多，一般不要超過 3 個
工具
Gitlab 及 Git 相關規範
Gitlab 對於程式碼倉庫開源首選 GitHub，不開源現在也有許多服務商，如：Gitee 等，如果有錢任性 GitHub 普通的團隊套餐每個月每人 9 刀，但我相信大多數中小企業會選擇 Gitlab。
還有就是服務端如果要自己配置 CI 服務不太方便。如果部署在自己的伺服器上，其他一些服務指令碼也部署在一起，會有很大的自主權。 綜合之後選擇了主流的 Gitlab。
第三方倉庫都可能遇到父愛如山般的維護時期。
Git 相關規範 Git 相比 SVN 能避免大多數非人為問題，這點相信已經不需要論證了。但是那些人為的問題怎麼辦，那當然需要規範了。
-
首先，做好分工，特別是 Storyboard 和 XIB 多種，儘量避免出現多人修改同一個檔案。
-
每個人的所有開發工作都只在自己的分支開發。例如小明開發，你就在本地切換到自己的 xiaoming_gittutorial 分支然後進行開發。
-
每個人只允許在自己的分支直接push遠端分支。
合併的時候必須遵循以下條件：
-
首先，本地切換到develop分支。
git pull -
例如你是小明，那麼在 pull 到遠端的 develop 最新的內容之後。
git merge xiaoming_gittutorial -
如果出現 conflict 那麼清除 conflict 之後，commit 然後把本地 develop push 到遠端的 develop。
-
每完成一個功能就提交一次，不要累計程式碼。
-
保證主分支程式碼永遠可執行，版本完整（用於指令碼自動化發測試包）。
這樣的流程有什麼好處呢？
-
幾乎不會出現 conflict。
-
你永遠也不會汙染 develop 分支。
每次都是在本地 merge 完清除了 conflict 之後再 push 會遠端，那麼別人更新本地 develop 分支，再合併的時候，就算出現 conflict 也只會是自己最新程式碼產生的 conflict。
Sketch 設計工具 + Zeplin 標註工具
移動端也屬於前端，是做直接和使用者打交道的事情，當然也包括設計獅，設計獅是一種很厲害的貓科動物，他們有著令人恐懼的畫素眼和血統中的強迫症。（以上我喝多了說的，不要當真哈~）
Sketch 作為一款移動時代設計師新寵，自然有其存在的道理。
- 自動儲存和版本管理
- 向量編輯和完美畫素
- 智慧參考線
- 自由編輯元素
- 布林運算
- 單圖層多重混合模式
- 四捨五入畫素數值取整
- 共享樣式和元件
- 優秀的輸出
- 分配間距
- 移動裝置模版
- 自帶格柵
- 出色的文字渲染
- 豐富的外掛（標註、內容填充）
- 多種軟體高度配合
- 旋轉複製
- 手機實時預覽
Zeplin 面向的使用者是設計師和前端（Web、Mobile）工程師，相當於做的是中間橋樑這一塊，核心功能為標註、Style Guide、備註文件與簡單的團隊協作。
- sketch支援多畫板，便於同時預覽，佔用記憶體較ps小很多
- sketch支援匯出flinto，便於製作互動動效原型
- zeplin解放設計師的雙手，從此告別切圖和標註
- zeplin降低工程師的溝通成本，提高設計還原度
Abstract 就是一個藉助 Git 對 Sketch 檔案進行版本控制的軟體。
詳情參見《Git 與 Sketch 的神奇邂逅：Abstract》 （sspai.com/post/40595）
成果
年終總結
- Github 原創開源專案 90+，共計 400+ 貢獻力
- 參與維護開源專案 fastlane 20.5k（至2018.02.08）
- 完成 Swifter 功能展示應用研發
Swifter 是一款基於 Swift 開發的，採用 MVVM 模式、RxSwift 函式式響應程式設計、元件化和 ReactNative 等技術的技術示例應用。