Re: [討論] 一段想重構的程式碼

[tyc5116 (累人啊....)]

※ 引述《oaz ()》之銘言：
: 如果對 debug 只有小影響，那應該是要另外去想其它較好的 debug 方式
: : 我對這個理由其實不太認同的,我是覺得加個屬性作為區分即可
: : 然後程式都會跑到相同的地方,debug應該會變的更容易才對阿!!
: : 不知道大家的看法如何?
原本還以為可能PO錯板,沒想到得到這麼多人的回應..(笑)

單純就是我的看法和主管不同,只是反應出來看看大家的看法而已

我也覺得稍微作個處理就可以分辨是哪個模組進到func了

但是主管就覺得這個方式不妥@@

因為他資深,我資淺,對於他說會對於debug造成麻煩

我只是"感覺"會比原來的方式好才對,但我並沒辦法量化

也無法百分百的保證,新的方式一定就好比較好,大致上就是這樣

推文也有說到,先重構就對了,但是要作過測試

的確,這是應該做的,但這不是我的問題點

測試我也會做(雖然我對測試不是那麼在行)

而是說,我重構了,測試了,真的沒問題了,但是程式看起來重構前和重構後差滿多的

(至少覺得我站在主管的立場來看,會這樣想),對於公司來說,就是個風險

基於這樣,我才會先詢問主管的意見,既然他不同意就算了

我的出發點在於,日後在修改維護會很有彈性,便利

程式碼越少越不會出錯,別人看不看的懂是別人的事(註)

實際上那些模組的其中一個func是去讀取xml的資料,功能是對的

但是演算法效率不好,才讓我有想改的念頭,先讓程式碼在每個模組變成共用(重構)

日後有時間再改良func(改寫),當重構的部份OK了,以後改寫就不用四處都要跟著改

大致上就是這樣

註:這就是我個人的黑暗面了...哈,我會想要盡量將進階的寫作技巧應用在裡面

   一方面程式碼少,就容易懂

   (當然也不是刻意的在賣弄技巧,何況我也還不到那個程度)

   前面的人把程式碼寫那麼爛,也沒考慮到後面的人阿

   我反而是想說,在確保程式碼正確的情況下,能盡量用進階技巧就盡量用

   程度不好的看不懂就不敢亂改,程度好的....也不擔心你改了XD

   (有遇過一段傳了好幾個人用都OK的程式碼,到你手上就出了一堆bug,
    查了半天才發現.原來是上一個人把大家共用的底層亂改的情況嗎XD)

   也許有人會想說,就把共用的程式碼包成lib就好啦,嘖嘖....

   因為我有遇到阿,大家有用了很久的程式碼,只有偶爾會出錯而已,所以大家就將就用

   好不容易(其實是湊巧)我找到了他的bug的可能原因,那相關的定義式咧??

   抱歉被包起來了

   那source code咧?

   抱歉,傳了太多人,沒有source code了......@@

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.117.180.172
※ 編輯: tyc5116         來自: 122.117.180.172      (07/24 21:57)
→ realmeat:太多散到不同地方的同一功能, 反而難維護
→ andymai:我倒是有看過同一個類別~每個用到的人都繼承再把想要的覆
→ andymai:寫掉~結果下一個人又不是從原類別繼承~而是繼承覆寫過的!
→ andymai:一層層下來~覆寫的方法都不盡相同~都不知道他們怎麼搞得清
→ andymai:楚現在方法裡面寫的到底是不是他們想要的...
→ hSATAC:先補測試，以後再找機會重構
→ hSATAC:有測試的才叫重構，沒測試的叫別的什麼東西
推 hichcock:先給你個讚, 效率問題就是一個很大的問題了
→ hichcock:有時間就去試試看吧, 技術就是這樣才能磨出來
→ TonyQ:不是程式碼越少越不會出錯，是重複的地方越少越不會出錯
→ TonyQ:不過有時候為了不重複程式碼反而會讓程式碼變複雜，一切都是
→ TonyQ:因地制宜的，沒有什麼標準解。XD
→ TonyQ:不過以這個case，既然你改完測完也對自己的結果有信心了，
→ TonyQ:那就沒甚麼好不改得啦～是我也會改。
→ TonyQ:政治上的因素就是另一件事了，怕以後被找維護麻煩就不改，
→ TonyQ:那系統就不會進步啦～