程序員開始處理遺留代碼的時候

❶ 什麼是代碼走讀和代碼機械化

(1) 代碼走讀都有哪些內容？

代碼走讀根據目的的不同，可以分為四個層次：

1、檢查是否符合編程規范；
2、尋找編譯器中的設計陷阱；
3、快速理解源代碼，找出流程設計中的問題；
4、對原有代碼的重構；

這四個層次可以按照從簡單到復雜的順序進行。

(2) 這四個層次都有什麼區別和意義？

1、 檢查是否符合編程規范；

編程規范融合並提煉了許多人多年開發編程語言程序積累下來的成熟經驗，幫助編程者形成良好的編程風格，提高源程序的可讀性和可維護性，降低出錯的機會，迅速跨入業已存在的且具有相當高度的技術層次，並能夠為提高代碼的復用性提供積極的參考。

2、 找編譯器中的設計陷阱；

術語「陷阱」的發展歷史並不明確，而且它有多種定義方法。本文定義為編程和設計過程中常見的和可防止的問題，能順利通過編譯，沒有任何警告和錯誤信息，而且計算機嚴格按照作者寫明的代碼執行，但是結果卻不是作者期望的。許多IT人士都知道，現在市場上有很多新的編譯器，它們可以捕獲大部分程序錯誤，但遺憾的是，仍有許多錯誤是編譯器不能發現的。打個比方，拼寫檢查程序是用來查找拼寫錯誤的，但是，如果單詞DOG被錯誤地寫為CAT，您能指出單詞CAT（實際是DOG）中的拼寫錯誤嗎？很顯然，不能。因為這個單詞可順利通過拼寫檢查程序。

這里描述的陷阱所包括的范圍廣泛，從較容易的語法問題，基本設計缺陷，到完全錯誤的行為。利用正確的使用方法來說明這些常見的誤解和誤用，可以防止編程者出現類似的問題，並防止新一代程序員重復過去的錯誤。

3、 快速理解源代碼，找出流程設計中的問題；

無論是溝通程序的操作，還是將知識存儲為可執行的形式，軟體的源代碼都是最終的介質。我們可以將源代碼編譯成可執行程序，也可以閱讀代碼來了解程序的功能及其工作方式，還可以修改源代碼來改變程序的功能。大多數編程課程和書籍都將重點放到如何從零開始編寫程序上。然而，在軟體系統的工作投入中，40％～70％是用在系統首次編寫完整之後，這些工作一定涉及到閱讀、理解、以及修改最初的代碼。另外，遺留代碼持續不斷、不可避免的累積；對軟體重用的強調；軟體行業中人員的高流動性；同時，開放源代碼開發工作和協同開發過程（包括外包、代碼走查和極限編程）日益重要，使得代碼閱讀成為當今軟體工程師的一項基本功能。此外，閱讀實際的、編寫良好的代碼，可以更加深入地了解如何改造與編寫重要的系統，僅僅編寫小型的程序學不到這種能力。

有時，閱讀代碼是一件不得不去做的事，比如：為了修復、檢查或改進現存的代碼，都必須去閱讀相關的代碼。有些時候，閱讀代碼也許是為了了解程序是如何工作的，對於任何能夠「打開蓋子」的事務，作為工程技術人員，我們總是傾向於分析一下它的內部結果。您閱讀代碼可能是想提取可供重用的材料，或者僅僅是出於個人興趣，將代碼作為一種文獻。每種原因的代碼閱讀都有自己的一套技術，強調不同方面的技能。

代碼走讀中的閱讀源代碼強調的是通過快速理解源代碼，找出流程設計中的問題這個目的。

4、 對原有代碼的重構；

重構的含義是：在不破壞可觀察功能的前提下，藉由搬移、提煉、打散、凝聚……，改善事務的體質、強化當前的可讀性、為將來的擴充性和維護性做准備、乃至於在過程中找出潛在的「臭蟲」，就成了大受歡迎的穩步前進的良方；

(3) 編程規范、設計模式和設計陷阱是什麼關系？

模式是避免陷阱或從特定陷阱中恢復的一種方法；

從陷阱的角度來看，設計模式有兩個重要屬性。首先，他們描述了經過實踐證明的成功的設計技術，而且可以用上下文相關的方法定製它們，以適應新的設計情況。其次，更加重要的是，提及特定的模式時，不僅說明了所應用的技術，而且說明了應用的原因以及結果；

當需要時，適合設計或者編碼上下文的模式、慣例、編程規范，將「自然地」從自己的潛意識中冒出來，這說明正確使用了模式、慣例、編程規范的一種跡象；

識別陷阱與對條件的反射類似，一朝被蛇咬，十年怕井繩。然而與比賽和打仗一樣，為了學習如何識別和避免危險情況，並不需要一定被燒傷或者被槍傷。一般情況下，必要條件就是提前警覺；

(4) 設計模式和重構是什麼關系？

設計模式給我們的，不僅僅是一些問題的解決方案，更有追求完美「模型」的渴望，但是，Joshua Kerievsky在那篇著名的《模式與XP》中明白地指出：在設計前期使用模式常常導致過度過程。這是一個殘酷的現實，單憑對完美的追求無法寫出實用的代碼，「實用」是軟體壓倒一切的要素。

(5) 快速理解源代碼和重構是什麼關系？

進行重構時，您從一個能夠正常工作的系統開始做起，希望確保結束時系統能夠正常工作。一套恰當的測試用來可以幫助您滿足此項約束，所以重構應該從編寫測試用例入手。一種類型的重構專注於修復一種已知的問題點。在此，您必須理解老的代碼、設計新的實現、研究新的實現對相關其它代碼造成的影響（多數情況下，新代碼能夠「無聲無息」地完成替換）並實現更改，所以重構需要先快速理解老的代碼。

(6)快速理解源代碼查找缺陷和尋找設計陷阱查找缺陷有什麼不同？

快速理解源代碼找出的代碼中的問題一般是流程設計上和軟體需求滿足上的特定的問題，需要讀者翻很多頁（發現前後的關聯），而尋找設計陷阱找出的代碼中的問題一般是普遍性的問題，一般不需要讀者翻頁，就在這一行的上下文中就可以找到。

（7）這幾個層次的代碼走讀和單元測試是什麼關系？

只有快速理解了源代碼才可以完成單元測試，或者說快速理解源代碼是完成單元測試的前提；

利用單元測試可以幫助更好地重構；

代碼走讀發現的問題比單元測試發現的更多、更快和更早；

單元測試發現不了不滿足編程規范的問題

（8）代碼走讀都有哪些方法？

形式上可以遵從同行評審的結構化的正規檢視、走查、單人復審等；

人工走讀時，檢查單可以按照頭腦風暴、親和圖、魚骨圖方法形成系統化的檢查樹和處理機制；

工具走讀可以藉助一些商用的測試工具和自己開發的輔助工具進行走讀。

（9）代碼走讀聽起來是不錯，如何才能達到效果嗎？

代碼走讀中使用的檢查單（或檢查樹）是很多人提煉和總結出來的結晶，市場和業界這方面的資料比較缺乏，因為多是個別大公司或個人的心血，所以很少在外面流傳，自己研究和總結有點得不償失，不如參考行業的優秀實踐，所以最好接受有經驗的專家的培訓或向有經驗的同行請教，在指導下開展推行，避免浪費自己的寶貴時間。

（10）代碼走讀和同行評審是什麼關系？

同行評審是一種比較偏管理的方法，評審的材料可以包括文檔和代碼，對於代碼的同行評審就是代碼走讀，本文講的代碼走讀偏重於技術層面的方法，兩者只有有效地結合才能更大地發揮它們的威力！

❷ 程序員都有祖傳代碼，就不會有問題了嗎

程序員被戲稱為“碼農”，天天與代碼打交道的他們按理說應該對代碼有著深厚的感情基礎，但在每個科技公司都有這樣一種代碼：多數程序員們都怕遇到，有經驗老碼農有時候也束手無策，往往一步錯、步步錯，動了一小行，改大半月。相信很多程序員都被這種代碼折磨過，就是大名鼎鼎的“祖傳代碼”

傳統觀點認為，工程技術團隊應該為代碼庫（也就是技術債務的所處環境）建立一種直觀的感受，了解其對公司的影響，而後在組織內建立信任。如果首席架構師強調重構核心代碼，那麼，開發者通常就得按照指示行動。誠然，如果公司可以對技術債務建立起一種共識與信任文化，這將有利於挽留優秀的工程師，並保持業務良好運作，但這往往需要多年努力。

❸ 系統程序員怎樣把代碼寫得又快又好

很多初學者包括一些有經驗的程序員，在敲完代碼的最後一個字元後，馬上開始編譯和運行，迫不急待的想看到自己的工作成果。快速反饋有助於滿足自己的成就感，但是同時也會帶來一些問題：

讓編譯器幫你檢查語法錯誤可以省些時間，但程序員往往太專注這些錯誤了，以為改完這些錯誤就萬事大吉了。其實不然，很多錯誤編譯器是發現不了的，像內存錯誤和線程死鎖等等，這些錯誤可能逃過簡單的測試而遺留在代碼中，直到集成測試或者軟體發布之後才暴露出來，那時就要花更大代價去修改它們了。

修改完編譯錯誤之後就是運行程序了，運行起來有錯誤，就輪到調試器上場了。花了不少時間去調試，發現無非是些低級錯誤，或許你會自責自己粗心大意，但是下次可能還是犯同樣的錯誤。更嚴重的是這種debug&fix的方法，往往是頭痛醫頭腳痛醫腳，導致低質量的軟體。

讓編譯器幫你檢查語法錯誤，讓調試器幫你查BUG，這是天經地義的事猛灶，但這確實是又慢又爛的方法。就像你要到神知行離家東邊1000米的地方開會，結果你往西邊走，又是坐車又是搭飛機，花了一周時間，也繞著地球轉了一周，終於到了會議室，你還大發感慨說，現代的交通工具真是發達啊。其實你往東走，走路也只要十多分鍾就到了。不管你的調試技巧有多高，都不如一次性寫好更高效。

下面是我在閱讀自己代碼時的一些方法：

檢查常見錯誤

第一遍閱讀時主要關注語法錯誤、代碼排版和命名規則等等問題，只要看不順眼就修改它們。讀完之後，你的代碼很少有低級錯誤，看起來也比較干凈清爽。第二遍重點關注常見編程錯誤，比如內存泄露和可能的越界訪問，變數沒有初始化，函數忘記返回值等等，在後面的章節中，我會介紹這些常見錯誤，避免這些錯誤可以為你省大量的時間。如果有時間，在測試完成之後，還可以考慮是否有更好的實現方法，甚至嘗試重新去實現它們。說了讀者可能不相信，在學習編程的前幾年，我經常重寫整個模塊，只我覺得能做得更好，能驗證我的一些想法，或提高我的編程能力，即使連續幾天加班到晚上十一點，我也要重寫它們。

模擬計算機執行

常見錯誤是比較死的東西，按照檢查列表一條一條的做就行了。有些邏輯通常不是這么直觀的，這時可以自己模擬計算機去執行，假想你自己是計算機，讀入這些代碼時你會怎麼處理。北大青鳥http://www.kmbdqn.cn/認為這種方法能有效的完善我們的思路，考慮不同的輸入數據，各游嘩種邊界值，這能幫助我們想到一些沒有處理的情況，讓程序的邏輯更嚴謹。

❹ 程序員都有祖傳代碼，是真的嗎

首先，基本上大部分都是有祖傳代碼的，幾乎每個公司都會存在祖傳代碼。在代碼界，有一個令程序員聞之心驚、談之色變的存在——祖傳代碼（legacy code）。相信很多接觸編程的人都對祖傳代碼有著難以言表的恐怖體驗。如果不改這個祖傳代碼，就難以實現新的需求，支撐新的業務。但是一旦改了這個代碼，改之後新出現的bug絕對能讓人失去理智。
祖傳代碼，前人程序員留下的“寶藏”代碼，這種代碼多多少少都會存在些問題。運氣好點的會碰到by xxxx多少年的注釋，運氣差的連注釋都沒有，各種奇葩的邏輯，甚至直接一大段看不懂的代碼。這一般就是程序員們所說的祖傳代碼，祖傳代碼又稱作“屎山”、“歷史遺留代碼”。碰到這種代碼，程序員們最好不要去優化去動它，因為可能會引發後續一系列的問題。所以遇到這種代碼，一般程序員會有兩種應對方法。

❺ 大廠程序員提倡「防禦性編程」：故意把代碼寫得很爛，萬一自己被裁，要確保留下的代碼不可維護......

在面對大廠裁員潮時，有部分程序員採取了「防禦性編程」的策略，以確保自己的代碼難以維護，甚至在被裁後，公司可能需要花費更多時間和資源去理解或修改這些代碼。這種做法看似是一種自我保護手段，但實際上卻反映了行業環境的嚴峻性和職場壓力。

「防禦性編程」主要是指程序員故意編寫一些復雜、難以理解的代碼，使得代碼的可讀性和可維護性大大降低。這種策略旨在提高自己的不可替代性，因為在被裁員後，留下的代碼會成為一個潛在的「絆腳石」，公司可能需要額外的時間和資源來解決遺留問題。

這一現象的產生，與互聯網行業巨頭裁員潮有關。在經濟壓力和市場波動的影響下，大廠紛紛尋求成本控制和效率提升，這在一定程度上加劇了職場的不確定性。在這種背景下，程序員們開始探索如何在被裁員時保護自己，而「防禦性編程」正是這種嘗試的一種表現。

然而，這種做法存在爭議。有人認為，這不僅對公司的長期發展不利，也損害了程序員自身的專業形象。實際上，編寫清晰、簡潔、可維護的代碼才是行業發展的正道，因為它不僅有利於團隊協作，還能提高軟體的質量和穩定性。在面對經濟挑戰時，更應該尋求提升自身技能、增強專業價值的途徑。

理性的看待「防禦性編程」，我們可以理解為是一種生存策略，但其潛在的負面影響不能被忽視。長遠來看，這種做法可能對個人和行業都產生不利影響。因此，作為行業和公司，應該關注員工的福祉和職業發展，提供支持和培訓，幫助他們提升技能，而不僅僅是依賴於這種短期的「自救」策略。

實際上，程序員們更希望編寫出優美、無誤、易於維護的代碼。在面對壓力時，他們應該關注提升個人能力、適應行業變化，而不是依賴於「防禦性編程」的策略。作為個人，持續學習和專業成長是應對職場挑戰的更可持續的方法。同時，公司也應該採取積極措施，維護員工權益，創造一個有利於個人和公司共同成長的環境。