1.?行為準則

文章來源地址http://www.zghlxwxcb.cn/news/detail-749128.html

2.?變更代碼

2.1.?變更代碼和在新代碼庫中寫代碼完全不一樣，你必須在不破壞現(xiàn)有行為的情況下進行這些修改

2.1.1.?必須理解其他開發(fā)者的想法，堅持原有的代碼風格和設計模式

2.1.2.?必須在工作中溫和地改進代碼庫

2.2.?善于利用現(xiàn)有代碼

2.2.1.?安全地在現(xiàn)有代碼庫中修改代碼的步驟

2.2.1.1.?定義變更點

2.2.1.2.?尋找測試點

2.2.1.3.?打破依賴關系

2.2.1.4.?編寫測試

2.2.1.5.?進行修改和重構

2.2.2.?找到你需要修改的代碼，并想出如何測試它

2.2.2.1.?如果需要的話，為了讓測試成為可能，可以對代碼進行重構

2.2.2.2.?針對現(xiàn)有的軟件行為也要添加測試用例

2.2.2.3.?一旦豎起柵欄，你的修改點周圍的區(qū)域就得到了很好的保護，然后就可以在里面修改代碼了

2.2.3.?一旦你定位了代碼，就要找到它的測試點

2.2.3.1.?測試點是你想要修改的代碼的入口，也就是測試用例需要調用和注入的區(qū)域

2.2.3.2.?測試點揭示了代碼在被你變更之前的行為，你需要使用這些測試點來測試你自己的變更

2.2.4.?依賴關系不是指類庫或服務的依賴關系，而是指測試你的代碼時所需要的對象或方法

2.2.4.1.?打破依賴關系意味著改變代碼結構，使其更容易測試

2.2.4.1.1.?將一個大的、復雜的方法拆分成多個小的方法，這樣就可以分別去測試獨立的特性片段

2.2.4.1.2.?引入一個接口（或其他中介），為測試提供一個復雜對象的簡單實現(xiàn)——不完整，但要滿足測試需要

2.2.4.1.3.?注入明確的控制點，允許你模擬難以控制的執(zhí)行的切片，如時間的推移

2.2.4.2.?你只有改變代碼，才能將你的測試掛起來，并提供合成的輸入

2.2.4.2.1.?這些代碼變更一定不要改變原有的代碼行為

2.2.5.?不要為了方便測試去改變訪問聲明

2.2.5.1.?將私有(private)方法和變量公開以讓測試用例訪問代碼，但同時也破壞了封裝，這是一種糟糕的方式

2.2.5.2.?破壞封裝會增加你在項目的生命周期內必須保證的原有行為一致性的覆蓋面積

2.2.6.?當你重構和打破依賴關系時，應該添加新的測試來驗證舊的行為

2.2.6.1.?在迭代過程中要頻繁地運行測試套件，包括新的和舊的測試用例

2.2.6.2.?考慮使用自動測試工具來生成捕獲現(xiàn)有行為的測試用例

2.3.?過手的代碼要比之前更干凈

2.3.1.?幫助你的代碼隨著時間的推移而變得更好

2.3.2.?在不影響整個項目持續(xù)運轉的情況下要持續(xù)地重構工程，這樣重構的成本就會平攤在多次的版本更迭中

2.3.3.?當你修復錯誤或增加新的特性時，只清理有關聯(lián)性的代碼

2.3.4.?不要不顧一切地去找“臟”代碼，要“隨緣”一些

2.3.5.?盡量將清理代碼的提交和改變行為的提交各自分開

2.3.5.1.?分開提交可以讓你在不會丟失針對代碼清理的提交的基礎上，更容易地去恢復代碼變更

2.3.5.2.?較小的提交也更容易針對變更的部分進行評審

2.3.6.?代碼異味(code smell)

2.3.6.1.?要隨時定位有異味的代碼

2.4.?做漸變式的修改

2.4.1.?使用較小規(guī)模的提交

2.5.?對重構要務實

2.5.1.?重構是指在不改變軟件行為的情況下改進內部代碼結構

2.5.1.1.?經(jīng)常發(fā)生在添加新特性的時候，因為它使新特性可以更容易地被添加

2.5.1.2.?在修復bug的過程中，則經(jīng)常刪除代碼

2.5.1.3.?使用重構以打破依賴關系是工作中風險最大的部分

2.5.1.3.1.?采取小步前進的方式，在這個階段不要引入任何新特性

2.5.2.?重構并不總是明智的選擇

2.5.2.1.?因為團隊的工作有截止日期和排他的優(yōu)先事項，重構需要花費時間

2.5.2.2.?你的團隊可能會決定忽略重構，而去開發(fā)新特性

2.5.3.?重構的成本也可能超過其價值

2.5.3.1.?正在被替換的舊的、廢棄的代碼不需要被重構

2.5.3.2.?低風險或很少被觸及的代碼也不需要

2.6.?善用IDE

2.6.1.?IDE在重構時特別有幫助

2.6.2.?IDE使重構變得如此容易

2.7.?代碼變更都應該被提交到版本控制系統(tǒng)(VCS)

2.7.1.?在開發(fā)過程中，盡早并頻繁提交你的修改

2.7.2.?頻繁地提交可以顯示出代碼隨著時間的推移而發(fā)生的變化，方便你撤銷修改，并將之作為一份遠程備份

3.?避“坑”指南

3.1.?現(xiàn)有的代碼都多多少少地背負歷史包袱

3.2.?繼承原有的代碼標準可以保持代碼的可讀性，但前后的不統(tǒng)一將使開發(fā)人員難以理解代碼

3.3.?如果你想重構代碼或重定義標準，你的改進就必須是一個數(shù)量級層面的改進

3.3.1.?小的收益是遠遠不夠的，因為成本太高了

3.3.2.?大多數(shù)工程師低估了慣例的價值，而高估了忽視慣例的收益

3.4.?保守一些的技術選型

3.4.1.?成功的公司留用舊的代碼，比如舊的類庫和舊的模式的原因是成功需要時間，而在技術上大動干戈會讓人分心

3.4.2.?新技術的問題是它不太成熟

3.4.2.1.?所有的技術都會發(fā)生故障，但舊的東西以可預測的方式發(fā)生故障，新東西往往會以令人驚訝的方式發(fā)生故障

3.4.2.2.?缺乏成熟度意味著更小的社區(qū)、更低的穩(wěn)定性、更少的文檔，以及更差的兼容性

3.4.2.3.?新技術的收益必須超過其成本

3.4.3.?一種語言可能具有很大的優(yōu)勢：一種特定的編程范式，更易于實驗，或消除某些類型的代碼錯誤

3.4.3.1.?一種語言的優(yōu)勢必須與它的劣勢保持平衡

3.4.3.2.?價值數(shù)十億美元的公司都是建立在成熟但有些無聊的編程語言之上的，偉大的軟件基本都是用C、Java、PHP、Ruby和.NET編寫的

3.4.3.3.?除非某種語言正在消亡，否則它的年齡和缺乏吸引力都很難成為反對使用它的理由

3.5.?不要特立獨行

3.5.1.?要因為你不喜歡你公司（或行業(yè)）的標準就忽視它們，編寫非標準的代碼意味著它將無法適應公司的環(huán)境

3.5.2.?改變被廣泛采用的東西肯定進展很緩慢，但并不意味著不值得這樣做

3.6.?不要只分叉而不向上游提交修改

3.6.1.?分叉(fork)是對一個代碼庫進行完整的、獨立的復制，分叉之后的代碼庫有自己的主干、分支和標簽

3.6.2.?分叉操作可以讓那些對主代碼庫沒有寫入權限的人仍然可以對項目做出貢獻，這是一種正常而健康的做法

3.6.3.?不太健康的做法是只分叉代碼庫而不打算回饋修改

3.6.3.1.?這種情況發(fā)生在對項目的方向有分歧的時候，原來的項目被廢棄了，或者是很難把修改的代碼合并到主代碼庫里

3.6.4.?分叉公司內部的代碼庫并進行維護特別有害

3.6.5.?沒有及時貢獻到上游代碼庫的小調整會隨著時間的推移而變得復雜

3.7.?克制重構的沖動

3.7.1.?重構工作常常升級為全方位的重寫

3.7.2.?不要以為重構工作會很輕松，這將是一個艱難的過程

到了這里，關于讀程序員的README筆記03_變更代碼的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！