Dropbox 的 iOS 應(yīng)用中的每一行代碼,都是開(kāi)始于被添加到 Maniphest 中的一個(gè) bug 或者功能任務(wù),Maniphest 是我們的任務(wù)管理系統(tǒng)。當(dāng)一位工程師在上面接受一個(gè)任務(wù),那么在開(kāi)始寫代碼前相應(yīng)的責(zé)任就已經(jīng)賦予他。Phabricator 這個(gè)平臺(tái)包含了我們的代碼審查工具,這個(gè)代碼審查工具有很多很好的功能,但它在評(píng)估對(duì)象之間的相互協(xié)作上不是做的很好。為了彌補(bǔ)這點(diǎn),我們的工程師在開(kāi)始他們的工作之前需要知道審查他們的任務(wù)的人是誰(shuí)[1]。對(duì)于被審查代碼的工程師來(lái)說(shuō),這樣能確保在他們的團(tuán)隊(duì)中有一個(gè)橡皮鴨,這個(gè)橡皮鴨知道項(xiàng)目中一些改動(dòng)代碼的背景和原因,并且對(duì)代碼的設(shè)計(jì)決策上起到協(xié)助的作用。對(duì)于審查者來(lái)說(shuō),這有助于他們將一些變化考慮進(jìn)他們的開(kāi)發(fā)周期評(píng)估中,這樣有助于開(kāi)發(fā)周期評(píng)估的準(zhǔn)確。如果不出意外的話,我們的經(jīng)驗(yàn)會(huì)告訴我們提前做好計(jì)劃可以有效地避免審查代碼過(guò)程中的重復(fù)勞動(dòng)。針對(duì)項(xiàng)目中的變化做計(jì)劃可以像在白板前做交流一樣簡(jiǎn)單,也可以像寫一篇建設(shè)性文檔一樣深入。這都取決于我們自己的選擇。
[1] 我的團(tuán)隊(duì)中每個(gè)人都要審查代碼。新來(lái)的同事在可以獨(dú)立審查較大的任務(wù)之前,會(huì)先被分配一些比較少的代碼量。
隨著任務(wù)的展開(kāi),工程師需要一直謹(jǐn)記我們的代碼規(guī)范。這個(gè)規(guī)范是一個(gè)最佳實(shí)踐和一致規(guī)范的大融合,它的存在使我們不用去猜測(cè)我們應(yīng)該怎樣編碼,也使審查變得更容易[2]。因?yàn)檫@是一個(gè)大項(xiàng)目,開(kāi)發(fā)團(tuán)隊(duì)中沒(méi)有一個(gè)人能對(duì)整個(gè)項(xiàng)目有完美的映射或理解。所以我們的工程師需要依賴團(tuán)隊(duì)中其他工程師的幫助,將這些代碼的功能表現(xiàn)拼成一個(gè)整體,這有助與我們?cè)陂喿x代碼時(shí)能理解其中的邏輯。
[2] 即使這樣,每當(dāng)一個(gè)新成員加入時(shí),總還是不免要展開(kāi)一次關(guān)于使用 property 還是 ivar 的辯論。
當(dāng)這個(gè)任務(wù)的工作進(jìn)行到某個(gè)階段時(shí),我們的工程師很可能會(huì)做出一些明顯不合理的或者不受歡迎的決定。捕獲這個(gè)心理的最佳時(shí)間就是發(fā)生這一刻 -- 為將來(lái)向?qū)彶檎咦龊媒忉尩臏?zhǔn)備。去解釋這些變化,說(shuō)起來(lái)容易做起來(lái)難,我們的工程師被鼓勵(lì)使用 //TODO,//HAX,和 //FIXME 來(lái)在代碼中寫注釋。//TODO 和 //FIXME 從字面上就可以理解它的意義,盡管后者會(huì)產(chǎn)生編譯警告,所以必須在下一次發(fā)布之前要被解決。//HAX 這個(gè)注釋比較有趣的地方。我們用它標(biāo)注那些用來(lái)繞過(guò) Apple 的 API 里的 bug 但又不容易一眼看明白的方法[3]。我們的注釋會(huì)寫上日期和寫這個(gè)注釋人的名字[4],在之后很多時(shí)候我們總會(huì)感激這些額外的上下文的[5]。
[3] 標(biāo)注里通常是第三方來(lái)源或者 radar 的鏈接,還有特殊的重現(xiàn)步驟。
[4] 比如像 //HAX:(ashleynh) 2015-03-09
[5] Hello