程式碼要清的多乾淨?
by thinker
關鍵字:
最後更新時間: 2011-09-18 18:14:41 CST | 引用
查詢:
COMMENTS:
on 2011-09-20 14:04:55 CST
betaparticle said ..
依照程式的蝴蝶效應、加上六度分隔的理論,改一個東西總是會發生順藤摸瓜、牽一髮動全身的效果,也許只有一行的程式,卻千絲萬縷跟別的部份環環相扣。以為順手把一個字串的尾巴空白給拿掉沒關係,卻造成另外一個系統的崩潰。按我膽小的個性,沒時間查完全部,我通常是不改的…。這算抱怨嗎?呵~~
on 2011-09-20 14:06:36 CST
betaparticle said ..
依照程式的蝴蝶效應、加上六度分隔的理論,改一個東西總是會發生順藤摸瓜、牽一髮動全身的效果,也許只有一行的程式,卻千絲萬縷跟別的部份環環相扣。以為順手把一個字串的尾巴空白給拿掉沒關係,卻造成另外一個系統的崩潰。按我膽小的個性,沒時間查完全部,我通常是不改的…。這算抱怨嗎?呵~~
on 2011-09-20 15:36:48 CST
Thinker said ..
蝴蝶效應我還能理解,但六度分隔有何相干? 基本上,這個議題不管怎麼寫,都會有反對的理由。完全取決於價值觀。是求一時安全重要,還是長的進步重要。就如本文裡說的,這是可以 trade-off 的,而不是死規則一條。「改一個空白都可能出錯,所以全都不要動」這樣的死規則,我並不覺的合理,只會故步自封。當然,如果你覺你的專案和發射太空梭一樣重要,或許連一個空白都不能改。
on 2011-09-26 01:09:44 CST
TonyQ said ..
我完全同意Thinker 所說的沒有犯錯就沒有進步。 不過我寫這篇文章的時候是設定對象,是給某些一昧覺得老code就是爛code,自己寫的就是比較好的人看得。 我只是要重新提醒一件事情,架構上的不認同不等於架構上的錯誤,沒有必要為了理念上的正義去「更正」架構。 對於soft_job的讀者來講,像thinker你們這種已經很嫻熟架構設計的人自然很清楚什麼是對的或該做的, 所以一看就會覺得我的立論是偏一邊的。XD 不過我設訂的倒是給那些對專案架構還不是很有把握的人,所以希望他們盡量保守一點, 畢竟新(加入的)人過度積極地把專案大部分砍掉重練的事情也是偶爾會發生的, 這樣對於新人固然是他自己的磨練沒錯,但對整個專案不見得是好事。 重點在於,他不能以自己的正義感要公司買單這些修正跟測試的資源,而必須實際的以專案的角度去確認這是必要的。 而如果是顯著的邏輯錯誤,其實即使是有將錯就錯的部份,那其實我覺得只要測試資源允許,或者客戶承受bug的風險是允許的,那都是應該修正的。 畢竟每個將錯就錯的部份都是一個未來的不可知的炸彈。 除非,那個將錯就錯的部份已經蔓延到別人的系統, 而那些人卻是你的客戶以外......
on 2011-09-26 01:12:43 CST
TonyQ said ..
錯誤不是不可接受的,而是有沒有意識會製造出錯誤而該承擔這些錯誤。 如果能意識到並且能承擔,那我覺得很好,我覺得重點在「自覺」。 保守不代表不要,保守是表示謹慎評估。