Dropbox 的 iOS 應用中的每一行程式碼，都是開始於被新增到 Maniphest 中的一個 bug 或者功能任務，Maniphest 是我們的任務管理系統。當一位工程師在上面接受一個任務，那麼在開始寫程式碼前相應的責任就已經賦予他。Phabricator 這個平臺包含了我們的程式碼審查工具，這個程式碼審查工具有很多很好的功能，但它在評估物件之間的相互協作上不是做的很好。為了彌補這點，我們的工程師在開始他們的工作之前需要知道審查他們的任務的人是誰[1]。對於被審查程式碼的工程師來說，這樣能確保在他們的團隊中有一個橡皮鴨，這個橡皮鴨知道專案中一些改動程式碼的背景和原因，並且對程式碼的設計決策上起到協助的作用。對於審查者來說，這有助於他們將一些變化考慮進他們的開發週期評估中，這樣有助於開發週期評估的準確。如果不出意外的話，我們的經驗會告訴我們提前做好計劃可以有效地避免審查程式碼過程中的重複勞動。針對專案中的變化做計劃可以像在白板前做交流一樣簡單，也可以像寫一篇建設性文件一樣深入。這都取決於我們自己的選擇。
[1] 我的團隊中每個人都要審查程式碼。新來的同事在可以獨立審查較大的任務之前，會先被分配一些比較少的程式碼量。
隨著任務的展開，工程師需要一直謹記我們的程式碼規範。這個規範是一個最佳實踐和一致規範的大融合，它的存在使我們不用去猜測我們應該怎樣編碼，也使審查變得更容易[2]。因為這是一個大專案，開發團隊中沒有一個人能對整個專案有完美的對映或理解。所以我們的工程師需要依賴團隊中其他工程師的幫助，將這些程式碼的功能表現拼成一個整體，這有助與我們在閱讀程式碼時能理解其中的邏輯。
[2] 即使這樣，每當一個新成員加入時，總還是不免要展開一次關於使用 property 還是 ivar 的辯論。
當這個任務的工作進行到某個階段時，我們的工程師很可能會做出一些明顯不合理的或者不受歡迎的決定。捕獲這個心理的最佳時間就是發生這一刻 — 為將來向審查者做好解釋的準備。去解釋這些變化，說起來容易做起來難，我們的工程師被鼓勵使用//TODO，//HAX，和 //FIXME 來在程式碼中寫註釋。//TODO 和 //FIXME 從字面上就可以理解它的意義，儘管後者會產生編譯警告，所以必須在下一次釋出之前要被解決。//HAX 這個註釋比較有趣的地方。我們用它標註那些用來繞過 Apple 的 API 裡的 bug 但又不容易一眼看明白的方法[3]。我們的註釋會寫上日期和寫這個註釋人的名字[4]，在之後很多時候我們總會感激這些額外的上下文的[5]。
[3] 標註裡通常是第三方來源或者 radar 的連結，還有特殊的重現步驟。
[4] 比如像 //HAX:(ashleynh) 2015-03-09
[5] Hello