→ fuha:小心 很多code 是累積的 小心產生新bug 01/16 11:33
推 xatier:通靈時請繫好安全帶 (版本控制) 01/16 11:54
→ cha122977:是說如果這個proj有版本控制 也可以先回到前面版本看 01/16 12:37
推 chchwy:重構也是要很花時間成本的喔 啾咪 01/16 13:03
→ fuha:有時候沒有真正了解前人寫的code最好小心點改不然就.... 01/16 13:04
→ fuha:尤其是那種一堆 if else 或是一個 function 有幾百行那種 01/16 13:05
→ f1234518456:不如每天捲程式碼 看看等薪水下來比較實在 01/16 13:09
→ andymai:還沒瞭解就重構?這樣好嗎?互相摻雜~確定不會弄得更亂? 01/16 13:42
當然要先看過一部分程式碼才做重構
但是,不用整個架構都了解八九成了,才做重構
先挑一個明顯的功能就可以了
事實上,在《重構》-- 改善既有程式的設計中
(http://jjhou.boolan.com/jjtbooks-refactoring.htm)
有一章關於「何時重構」?
有一段
無論何時只要我想理解程式碼所做的事,我就會問自己:是否能
對這段程式碼進行重構,使我能更快理解它。然後我就會重構。
也提過,重構有助於復審 (code review)
這些是作者的經驗談,也符合我個人的經驗。
至於互相摻雜弄得更亂的話,那也沒關係,就放棄這個重構,去找下一個
所以說,版本控制系統是很重要
推 wuliou:refactor->test->refactor->test->refactor->test->..... 01/16 17:05
→ testPtt:->rewrite 01/16 19:18
→ SuperUp:有暗黑程式碼暗黑變數,一動程式就在其它地方爛掉怎麼辦? 01/16 19:40
爛掉就爛掉 :)
應該是說,只要不會進到產品線,就算改爛了也無所謂吧 :)
所以我才會說,有一個「自己用」的版本控制系統很重要
大不了就所有的重構都放棄,而且這不會做白工
原 po 的目的是讀懂既有的程式
要考慮的是,如果改了十個地方才在一個地方出錯
那其它九個是值得的(尤其是重構後的程式碼有助於理解更多程式的時候)。
而且如果之後需要修正錯誤,新加功能時,這九個說不定可以直接拿來用。
此外,如果改爛了,就回頭去找是因為哪一個改動出錯了,為什麼
這樣也可以幫助理解為什麼當初要那樣寫,有沒有更好的寫法
如果只是一味地害怕一動程式就在其它地方爛掉而不敢動程式
往往是因為這種心態導致程式架構愈來愈糟。
我個的人看法是,重要的反而是培養什麼時侯可以做怎樣程度的重構。
如:接近出貨,就只能做小幅度的重構,甚至不可以做。
如果時程很足夠的話,做大一點的也沒關係
如果只是想讀懂程式碼,用一個「自己用」的版本控制系統儘量做吧
→ sardine:我比較想了解原po從哪邊開始看程式 01/16 21:17
同感
推 plover:砍掉重練增加自己的價值((誤)) 01/16 22:15
※ 編輯: oaz 來自: 140.112.30.46 (01/17 12:12)
推 genesic:同意這篇的說法,進行重構不管成功失敗都有助於了解專案 01/17 14:19
→ genesic:有自己的版本控管的話,大不了就把重構的版本廢掉就好 01/17 14:20
推 freeman921:有道理耶!!! 01/17 14:27
→ andymai:弄亂就放棄下一個...這?弄亂所花的時間真的有幫助~還是只 01/18 00:04
→ andymai:是推翻自己之前的假設?假設是錯的~花的時間真的值得? 01/18 00:05
→ andymai:另外那一段寫的也是在"自己知道程式在幹嘛"的情況下重構吧 01/18 00:07
→ andymai:?看不懂的硬要照自己的意思分...踩地雷修正的機率是??? 01/18 00:11