搜索引擎一直不收錄網(wǎng)站怎么辦

發(fā)布時間：2016-10-07 文章來源：瀏覽次數(shù)：2530

代碼審查(Code Review)是軟件開發(fā)中常用的手段，和QA測試比擬，它更輕易發(fā)現(xiàn)和架構(gòu)以及時序相關(guān)等較難發(fā)現(xiàn)的題目，還可以匡助團(tuán)隊成員進(jìn)步編程技能，同一編程風(fēng)格等。
　　1. 代碼審查要求團(tuán)隊有良好的文化
　　團(tuán)隊需要熟悉到代碼審查是為了進(jìn)步整個團(tuán)隊的能力，而不是針對個體設(shè)置的檢查“關(guān)卡”。
　　“A的代碼有個bug被B發(fā)現(xiàn)，所以A能力不行，B能力更好”，這一類的陷阱很輕易被擴散從而影響團(tuán)隊內(nèi)部的協(xié)作，因此需要避免。
　　另外，代碼審查本身可以進(jìn)步開發(fā)者的能力，讓其從自身犯過的錯誤中學(xué)習(xí)，從他人的思路中學(xué)習(xí)。假如開發(fā)者對這個流程有抵觸或者反感，這個目的就達(dá)不到。
　　2. 謹(jǐn)嚴(yán)的使用審查中題目的發(fā)現(xiàn)率作為考評尺度
　　高效代碼審查的十個經(jīng)驗
　　在代碼審查中假如發(fā)現(xiàn)題目，對于題目的發(fā)現(xiàn)者來說這是好事，應(yīng)該予以鼓勵。但對于被發(fā)現(xiàn)者，我們不主張使用這個方式予以懲罰。軟件開發(fā)中bug在所難免，過度苛求本身有悖常理。更糟的是，假如造成介入者怕承擔(dān)責(zé)任，不愿意在審查中指出題目，代碼審查就沒有任何的價值和意義。
　　3. 控制每次審查的代碼數(shù)目
　　根據(jù)smartbear在思科所作的調(diào)查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發(fā)現(xiàn)題目的能力就會下降.
　　高效代碼審查的十個經(jīng)驗
　　我們在實踐中發(fā)現(xiàn)，跟著開發(fā)平臺和開發(fā)語言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)目確實非常必要，由于這個過程是高強度的腦力密集型流動。時間一長，代碼在審查者眼里只是字母，無任何邏輯聯(lián)系，天然不會有太多的產(chǎn)出。
　　4. 帶著題目去進(jìn)行審查
　　我們在每次代碼審查中，要求審查者利用自身的經(jīng)驗先思索可能會遇到的題目，然后通過審查工作驗證這些題目是否已經(jīng)解決。一個竅門是，從用戶可見的功能出發(fā)，假設(shè)一個比較復(fù)雜的使用場景，在代碼閱讀中驗證這個使用場景是否能夠準(zhǔn)確工作。
　　使用這個技巧，可以讓審查者有代入感，真正的陶醉入代碼中，進(jìn)步效率。大家都知道看武俠小說不輕易瞌睡兒，而看專業(yè)書輕易瞌睡兒，原因就是武俠小說更輕易產(chǎn)生代入感。
　　有的研究建議每次樹立目標(biāo)，控制單位時間內(nèi)審核的代碼數(shù)目。這個方法在我們的實踐中顯得很機械和流程化，不如上面的方法效果好。
　　5. 所有的題目和修改，必需由原作者進(jìn)行確認(rèn)
　　假如在審查中發(fā)現(xiàn)題目，務(wù)必由原作者進(jìn)行確認(rèn)。
　　這樣做有兩個目的：
　　(1)確認(rèn)題目確實存在，保證題目被解決
　　(2)讓原作者了解題目和不足，匡助其成長
　　有些時候為了追求效率，有經(jīng)驗的審查者更傾向于直接修改代碼乃至重構(gòu)所有代碼，但這樣不利于進(jìn)步團(tuán)隊效率，并且會增加由于重構(gòu)引入新bug的幾率，通常情況下我們不予鼓勵。
　　6.利用代碼審查激活個體“能動性"
　　即使項目進(jìn)度比較緊張，無法完全的進(jìn)行代碼審查，至少也要進(jìn)行部門代碼的審查，此時隨即抽取一些樞紐部門是個不錯的辦法。
　　背后的邏輯是，軟件開發(fā)長短常有創(chuàng)造性的工作，開發(fā)者都有強烈的自我驅(qū)動性和自我實現(xiàn)的要求。閃開發(fā)者知道他寫的任何代碼都可能被其他人閱讀和審察，可以促使開發(fā)者集中留意力，尤其是避免將質(zhì)量糟糕，乃至有初級錯誤的代碼提交給同伴審查。開源軟件也很好的利用了這種心態(tài)來進(jìn)步代碼質(zhì)量。
　　7.在非正式，輕松的環(huán)境下進(jìn)行代碼審查
　　如前所述，代碼審查是一個腦力密集型的工作。介入者需要在比較輕松的環(huán)境下進(jìn)行該工作。因此，我們以為像某些實踐中建議的那樣，以會議的形式進(jìn)行代碼審查效果并不好，不僅由于長時間的會議輕易讓效率低下，更由于會議上可能泛起的爭議和思索不利于進(jìn)行如斯復(fù)雜的工作。
　　8.提交代碼前自我審查，添加對代碼的說明
　　所有團(tuán)隊成員在提交代碼給其他成員審查前，必需提高前輩行一次審查。這次自我修正形式的審查除了檢查代碼的準(zhǔn)確性以外，還可以完成如下的工作：
　　(1)對代碼添加注釋，說明本次修改背后的原因，利便其他人進(jìn)行審查。
　　(2)修正編碼風(fēng)格，尤其是一些樞紐數(shù)據(jù)結(jié)構(gòu)和方法的命名，進(jìn)步代碼的可讀性。
　　(3)從全局審閱設(shè)計，是否完整的考慮了所有情景。在實現(xiàn)之前做的設(shè)計假如存在考慮不周的情況，這個階段可以很好的進(jìn)行補救。
　　我們在實踐中發(fā)現(xiàn)，即使只有原作者進(jìn)行代碼審查，仍舊可以很好的進(jìn)步代碼質(zhì)量。
　　9.實現(xiàn)中記實筆記可以很好的進(jìn)步題目發(fā)現(xiàn)率
　　成員在編碼的時候應(yīng)做隨手記實，包括在代碼頂用注釋的方式表示，或者記實簡樸的個人文檔，這樣做有幾個好處：
　　(1)避免漏掉。在編碼時將考慮到的任何題目都記實下來，在審查階段再次檢查這些題目都確認(rèn)解決。
　　(2)根據(jù)研究，每個人都習(xí)慣犯一些重復(fù)性的錯誤。這類題目在編碼是記實下來，可以在審查的時候用作檢查的依據(jù)。
　　(3)在反復(fù)記實筆記并在審查中發(fā)現(xiàn)類似的題目后，該類題目泛起率會明顯下降
　　10. 使用好的工具進(jìn)行輕量級的代碼審查
　　“工欲善其事，必先利其器”。我們使用的是bitbucket提供的代碼托管服務(wù)。
　　每個團(tuán)隊成員獨立開發(fā)功能，然后利用Pull Request的形式將代碼提交給審查者。復(fù)審者可以很利便在網(wǎng)頁上閱讀代碼，添加評論等，然后原作者會自動收到郵件提醒，對審視的意見進(jìn)行討論。
　　即使團(tuán)隊成員分布在天南海北，利用bitbucket提供的工具也能很好的進(jìn)行代碼審查。

上一條：合肥網(wǎng)站建設(shè)公司解說如何...

下一條：合肥浪訊網(wǎng)絡(luò)：網(wǎng)站建設(shè)制...