鍍金池/ 教程/ iOS/ 代碼審查的藝術:Dropbox 的故事
與四軸無人機的通訊
在沙盒中編寫腳本
結構體和值類型
深入理解 CocoaPods
UICollectionView + UIKit 力學
NSString 與 Unicode
代碼簽名探析
測試
架構
第二期-并發(fā)編程
Metal
自定義控件
iOS 中的行為
行為驅動開發(fā)
Collection View 動畫
截圖測試
MVVM 介紹
使 Mac 應用數據腳本化
一個完整的 Core Data 應用
插件
字符串
為 iOS 建立 Travis CI
先進的自動布局工具箱
動畫
為 iOS 7 重新設計 App
XPC
從 NSURLConnection 到 NSURLSession
Core Data 網絡應用實例
GPU 加速下的圖像處理
自定義 Core Data 遷移
子類
與調試器共舞 - LLDB 的華爾茲
圖片格式
并發(fā)編程:API 及挑戰(zhàn)
IP,TCP 和 HTTP
動畫解釋
響應式 Android 應用
初識 TextKit
客戶端
View-Layer 協作
回到 Mac
Android
Core Image 介紹
自定義 Formatters
Scene Kit
調試
項目介紹
Swift 的強大之處
測試并發(fā)程序
Android 通知中心
調試:案例學習
從 UIKit 到 AppKit
iOS 7 : 隱藏技巧和變通之道
安全
底層并發(fā) API
消息傳遞機制
更輕量的 View Controllers
用 SQLite 和 FMDB 替代 Core Data
字符串解析
終身學習的一代人
視頻
Playground 快速原型制作
Omni 內部
同步數據
設計優(yōu)雅的移動游戲
繪制像素到屏幕上
相機與照片
音頻 API 一覽
交互式動畫
常見的后臺實踐
糟糕的測試
避免濫用單例
數據模型和模型對象
Core Data
字符串本地化
View Controller 轉場
照片框架
響應式視圖
Square Register 中的擴張
DTrace
基礎集合類
視頻工具箱和硬件加速
字符串渲染
讓東西變得不那么糟
游戲中的多點互聯
iCloud 和 Core Data
Views
虛擬音域 - 聲音設計的藝術
導航應用
線程安全類的設計
置換測試: Mock, Stub 和其他
Build 工具
KVC 和 KVO
Core Image 和視頻
Android Intents
在 iOS 上捕獲視頻
四軸無人機項目
Mach-O 可執(zhí)行文件
UI 測試
值對象
活動追蹤
依賴注入
Swift
項目管理
整潔的 Table View 代碼
Swift 方法的多面性
為什么今天安全仍然重要
Core Data 概述
Foundation
Swift 的函數式 API
iOS 7 的多任務
自定義 Collection View 布局
測試 View Controllers
訪談
收據驗證
數據同步
自定義 ViewController 容器轉場
游戲
調試核對清單
View Controller 容器
學無止境
XCTest 測試實戰(zhàn)
iOS 7
Layer 中自定義屬性的動畫
第一期-更輕量的 View Controllers
精通 iCloud 文檔存儲
代碼審查的藝術:Dropbox 的故事
GPU 加速下的圖像視覺
Artsy
照片擴展
理解 Scroll Views
使用 VIPER 構建 iOS 應用
Android 中的 SQLite 數據庫支持
Fetch 請求
導入大數據集
iOS 開發(fā)者的 Android 第一課
iOS 上的相機捕捉
語言標簽
同步案例學習
依賴注入和注解,為什么 Java 比你想象的要好
編譯器
基于 OpenCV 的人臉識別
玩轉字符串
相機工作原理
Build 過程

代碼審查的藝術:Dropbox 的故事

Dropbox 的 iOS 應用中的每一行代碼,都是開始于被添加到 Maniphest 中的一個 bug 或者功能任務,Maniphest 是我們的任務管理系統。當一位工程師在上面接受一個任務,那么在開始寫代碼前相應的責任就已經賦予他。Phabricator 這個平臺包含了我們的代碼審查工具,這個代碼審查工具有很多很好的功能,但它在評估對象之間的相互協作上不是做的很好。為了彌補這點,我們的工程師在開始他們的工作之前需要知道審查他們的任務的人是誰[1]。對于被審查代碼的工程師來說,這樣能確保在他們的團隊中有一個橡皮鴨,這個橡皮鴨知道項目中一些改動代碼的背景和原因,并且對代碼的設計決策上起到協助的作用。對于審查者來說,這有助于他們將一些變化考慮進他們的開發(fā)周期評估中,這樣有助于開發(fā)周期評估的準確。如果不出意外的話,我們的經驗會告訴我們提前做好計劃可以有效地避免審查代碼過程中的重復勞動。針對項目中的變化做計劃可以像在白板前做交流一樣簡單,也可以像寫一篇建設性文檔一樣深入。這都取決于我們自己的選擇。

[1] 我的團隊中每個人都要審查代碼。新來的同事在可以獨立審查較大的任務之前,會先被分配一些比較少的代碼量。

隨著任務的展開,工程師需要一直謹記我們的代碼規(guī)范。這個規(guī)范是一個最佳實踐和一致規(guī)范的大融合,它的存在使我們不用去猜測我們應該怎樣編碼,也使審查變得更容易[2]。因為這是一個大項目,開發(fā)團隊中沒有一個人能對整個項目有完美的映射或理解。所以我們的工程師需要依賴團隊中其他工程師的幫助,將這些代碼的功能表現拼成一個整體,這有助與我們在閱讀代碼時能理解其中的邏輯。

[2] 即使這樣,每當一個新成員加入時,總還是不免要展開一次關于使用 property 還是 ivar 的辯論。

當這個任務的工作進行到某個階段時,我們的工程師很可能會做出一些明顯不合理的或者不受歡迎的決定。捕獲這個心理的最佳時間就是發(fā)生這一刻 -- 為將來向審查者做好解釋的準備。去解釋這些變化,說起來容易做起來難,我們的工程師被鼓勵使用 //TODO,//HAX,和 //FIXME 來在代碼中寫注釋。//TODO//FIXME 從字面上就可以理解它的意義,盡管后者會產生編譯警告,所以必須在下一次發(fā)布之前要被解決。//HAX 這個注釋比較有趣的地方。我們用它標注那些用來繞過 Apple 的 API 里的 bug 但又不容易一眼看明白的方法[3]。我們的注釋會寫上日期和寫這個注釋人的名字[4],在之后很多時候我們總會感激這些額外的上下文的[5]。

[3] 標注里通常是第三方來源或者 radar 的鏈接,還有特殊的重現步驟。

[4] 比如像 //HAX:(ashleynh) 2015-03-09

[5] Hello

上一篇:插件下一篇:收據驗證