為什么我在修改一個5萬行代碼的專案時，總有一種感覺，改著改著總感覺怕那里改錯，
心里就迫使自己從新解壓原始檔案，從新改
如此反復，
小專案可以。
為什么會這樣？難道我個人要求很完美？
uj5u.com熱心網友回復：
必須步步為營 ！uj5u.com熱心網友回復：
gai改一點順便測驗一下，不要全部改完再測驗，就不知道那步出問題
uj5u.com熱心網友回復：
這個還是因為自己對專案不夠熟悉。自信心不夠。只有不怕試錯，不斷提升uj5u.com熱心網友回復：
你這是病，要治。我真不是開玩笑，就像有些人，出門了，要回家確認是否忘記關門了一樣。都是病。uj5u.com熱心網友回復：
SVN或其他相關工具，改完一部分，測驗沒問題，提交并設定階段標識（方便恢復）uj5u.com熱心網友回復：
額。。。我總是認為自己忘記關門了，其實習慣已經保證我關門了，但是我總忍不住去再回去確認下。
強迫癥么？？？
uj5u.com熱心網友回復：
uj5u.com熱心網友回復：
那是因為你還沒吃透它uj5u.com熱心網友回復：
不，我已經吃透了，我可能是要求太完美，又特別擔心改錯哪里。
是我信心不足嗎？
uj5u.com熱心網友回復：
5萬行，也要分割為不同的檔案，不同的目錄，你不會說一個源代碼檔案有5萬行吧，從新解壓原始檔案，從新改，說明你已經在老去，在衰退，有老年健忘傾向，需要休息uj5u.com熱心網友回復：
樓主需要學會使用軟體：UltraCompare Professional或者Beyond Compareuj5u.com熱心網友回復：
uj5u.com熱心網友回復：
一個CPP有5萬行
uj5u.com熱心網友回復：
謝謝你的回復，猛然醒悟，可能我自己真的老了，累了
uj5u.com熱心網友回復：
一個CPP就有5萬行，膜拜...........
uj5u.com熱心網友回復：
一個CPP 5萬行代碼？你在跟我開國際玩笑嘛？這是哪個傻逼寫的？快把這個傻逼辭退了，這種人不適合做開發
uj5u.com熱心網友回復：
請牢記：源代碼本身的書寫是否結構化或面向物件或符合設計模式或敏捷…并不重要，重要的是你是否使用結構化或面向物件或符合設計模式或敏捷…的方法命名識別符號、閱讀、修改、檢查、測驗源代碼。意思是你程式結構看上去再合理，再簡潔，也不一定比看上去一團亂麻的程式結構在運行或修改時更不易出錯，更方便修改，出錯了更容易找到哪里出錯和具體出錯的原因，更容易改正錯誤。
試對比
圖書館（對圖書的分類夠結構化了吧）
和
搜索引擎（可看作是扁平化任何結構資料，僅支持全文檢索）
哪個處理資訊更方便、更高效。
所以
與其費勁去重構代碼讓其看上去更簡潔、更合理
不如費勁學習grep、sed、awk、……這類全文搜索和批處理編輯的工具。
結構越復雜，越難修改，越難除錯。
有時（甚至大多數時候），看上去越合理、越簡潔的代碼，運行起來性能越差，出錯時查找原因越難，找到出錯原因后改正越費勁。
程式員要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。Fred George
前微軟C#編輯器的開發主管Jay Bazuzi列出的一些有助于找到正確方向的問題；他覺得前同事們應該用這些問題來問自己；實際上不管在哪里作業的開發者們都應該經常問問自己這些問題：
◆“要保證這個問題不會再出現，我該怎么做？”
◆“要想少出些Bug，我該怎么做？”
◆“要保證Bug容易被修復，我該怎么做？”
◆“要保持對變化的快速回應，我該怎么做？”
◆“要保證我的軟體的運行速度，我該怎么做？”
如果大多數團隊都能不時問一下自己，必定會從中得益，因為這些都是真正強而有力的問題。
uj5u.com熱心網友回復：
我從來沒有改對的時候，就像排雷一樣，挖出來了，排除了，但是看著這個雷很礙眼，有找個地方埋下去了。這個世界干凈了。很久以后，有被踩到了，再來一次排雷工程。
這樣，你的老板才會繼續用你，如果。。。你就離離開不遠了。
uj5u.com熱心網友回復：
改著改著總會出現莫名其妙的問題，當發現解決不掉的時候就會產生從原檔案重新改的念頭。1、切記，有問題不能逃避，否則以后你還會遇到的
2、版本控制很有必要，svn、soucetree什么的都行，你就算代碼倒過來寫一遍，版本回滾也能輕松搞定
uj5u.com熱心網友回復：
臥槽，一個CPP 5萬行，黑人問號？？？？？uj5u.com熱心網友回復：
做好版本管理，放心大膽的改！uj5u.com熱心網友回復：
我以前也是這樣，現在看到了都是直接改，改的有問題再改唄。放心大膽試。uj5u.com熱心網友回復：
出門了，要回家確認是否忘記關門了一樣.我如此反復回家確認過幾次。。。。
uj5u.com熱心網友回復：
百度搜“如何治療強迫癥”！
uj5u.com熱心網友回復：
估計是你沒有使用版本控制吧.有版本控制, (比如git, svn). 那就想怎么改就怎么改, 根本不擔心改錯的問題.
當然, 正常情況下, 應該是修改一個功能, 就需要做相關的測驗, 確保沒有問題了, 提交版本. 再改下一個功能. 這樣才是正確的思路. 某一個功能錯了, 能隨時回歸代碼. 不擔心做無用功.
如果實在是沒有版本倉庫, 那就只能改一個功能, 自己復制保存一份代碼, 并作標記. 最侄訓得到修改結果. 這時候就可以把備份洗掉.
uj5u.com熱心網友回復：
一個CPP 5萬行！！！
如果是這樣的話，建議轉行吧。
uj5u.com熱心網友回復：
臥槽，真的？？嚇我呢？？一個cpp就五萬行？？樓主，這不怪你，是我的話真的沒心思看下去的
uj5u.com熱心網友回復：
請牢記：源代碼本身的書寫是否結構化或面向物件或符合設計模式或敏捷…并不重要，重要的是你是否使用結構化或面向物件或符合設計模式或敏捷…的方法命名識別符號、閱讀、修改、檢查、測驗源代碼。意思是你程式結構看上去再合理，再簡潔，也不一定比看上去一團亂麻的程式結構在運行或修改時更不易出錯，更方便修改，出錯了更容易找到哪里出錯和具體出錯的原因，更容易改正錯誤。
試對比
圖書館（對圖書的分類夠結構化了吧）
和
搜索引擎（可看作是扁平化任何結構資料，僅支持全文檢索）
哪個處理資訊更方便、更高效。
所以
與其費勁去重構代碼讓其看上去更簡潔、更合理
不如費勁學習grep、sed、awk、……這類全文搜索和批處理編輯的工具。
結構越復雜，越難修改，越難除錯。
有時（甚至大多數時候），看上去越合理、越簡潔的代碼，運行起來性能越差，出錯時查找原因越難，找到出錯原因后改正越費勁。
程式員要做的不是盡力避免錯誤，而是聚焦在快速發現并改正錯誤。真正以快速方式輕易解決錯誤，“快速的失敗”遠勝過“預防錯誤”。Fred George
前微軟C#編輯器的開發主管Jay Bazuzi列出的一些有助于找到正確方向的問題；他覺得前同事們應該用這些問題來問自己；實際上不管在哪里作業的開發者們都應該經常問問自己這些問題：
◆“要保證這個問題不會再出現，我該怎么做？”
◆“要想少出些Bug，我該怎么做？”
◆“要保證Bug容易被修復，我該怎么做？”
◆“要保持對變化的快速回應，我該怎么做？”
◆“要保證我的軟體的運行速度，我該怎么做？”
如果大多數團隊都能不時問一下自己，必定會從中得益，因為這些都是真正強而有力的問題。
uj5u.com熱心網友回復：
在我眼里，一個CPP五萬行，和500個CPP平均每個大約100行，沒有本質區別！
uj5u.com熱心網友回復：
在我眼里，一個函式五萬行，和500個函式平均每個函式100行，沒有本質區別！
uj5u.com熱心網友回復：
5樓的方法可以解決你的問題,還有修改是分模塊的吧,為什么需要從原始檔案開始從頭來,哪里出問題,就改對應模塊唄轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/75370.html
標籤：基礎類