2017 移動端 iOS 年終工做總結-純乾貨請自備酒水

時間 2019-11-08

標籤移動 ios 年終總結乾貨自備酒水欄目無線简体版

原文原文鏈接

主題：發展

內容大綱

觀點：html

Swift 發展觀
ReactNative 發展觀

進階：前端

模塊化
Pods 依賴庫及組件化
環境自動切換 + 自動化打包測試 + 線上質量監控

管理：git

團隊核心組成架構
硬件設備投入
例會和文檔化
組織 CodeReview

工具：程序員

Gitlab 及 Git 相關規範
Sketch 設計工具 + Zeplin 標註工具

成果：github

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…

源碼：github.com/crazycodebo…

進階

模塊化

模塊化、組件化我後半年一直在調研的課題，對這些的研究也給我帶來了從量變到質變的提高。

什麼是模塊化？

那麼什麼是模塊化呢？《 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。爲了不各個業務團隊重複造輪子，團隊中也須要有必定的技術沉澱，所以組件化是必須的。如今咱們須要提供更多的、職能單1、性能更優的組件供業務團隊使用。根據業務相關性，咱們將這些組件分爲：基礎組件和業務組件。

阿里架構組一樣是組件化的先驅者，如下是阿里架構組 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 個