寫碼容易，讀碼難：工程師 千萬別重寫程式碼
(www.inside.com.tw)
「千萬別...」太言過其實，「別輕易...」比較中肯。隨著時代的演進，軟體實作的觀念就如同自然語言一樣，會演進的。就像現在人去理解幾千前年，孔子所說話，孟子所寫的文章一樣，難以理解。因此，我們用注釋來解決。軟體也是一樣，但有時侯重寫一次會更好。甚至固定頻率的部分重寫，就像房子需要整修一樣。最好是之前寫過、改過，對這部分程式很了解的人進行重寫。以更精確而易懂的方式(現代人)重新描述，把那些討人厭的補丁給抹平、抹掉。否則，經過幾手之後，現在流行的表達方式退潮之後，後來者就像看到甲骨文一般。
iapyeh
積分 0
重寫未必難，難在於老闆支不支持，願不願意先苦後甘，還是一樣繼續拖下去越來越苦。重不重寫是決策問題，不是技術問題。
在台灣普遍的想法是這樣，因此什麼都看上司怎麼說，於是什麼也不想堅持。這也使的台灣工程師相對的被動，整個軟體產業自然起不來。根據幾年來的觀察，米國的工程師相對比較主動，認為該做的事就會去做(當然工程師百百款，至少在敝公司大部分的情況是這樣)，除非老闆主動阻止他。相對於台灣的工程師，預設是什麼事都不要做，除非老闆說 GO~ 太過自動有時還會遭白眼。一來一往，結果如何可想而知。
也不是說米國人全都好，台灣人比較好指揮、有彈性(被指揮的彈性)，不會有一堆意見或光說不練。說難聽一點，是當奴隸的好材料。
linus
積分 4
重構跟測試是重點, 文章裡面只有"任性"的建議別重寫程式碼, 而忽略更重要的重構跟補強測試, 擔心會有"誤導"之慮. 除非真的爛到連測試程式都沒法寫啦...不然至少當黑箱去測, 沒有正確的執行結果, 測試目的就變成讓你更了解這個黑箱在幹嘛以及有什麼"洞"
我不重寫舊程式碼可能是因為
- 沒有文件也沒有測試程式，何謂「正確」的執行結果？
- 有些實作看起來很怪其實是有歷史因素的，除非問當初寫的人不然看再久也看不出為什麼，貿然改下去就爆炸。
- 沒有大問題的話針對無法滿足新需求的模組一點一點改寫就好。
- 得讓測試人員重新測試，冒著系統爆炸的風險，只是為了自己覺得程式碼好看一點，未必值得。