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

看板Soft_Job作者hichcock (快樂一整年 ^^~~~)時間12年前 (2013/07/26 10:11)推噓6(6推 0噓 7→)

留言13則, 6人參與討論串7/10 (看更多)

※ 引述《StupidGaGa (笨嘎嘎)》之銘言： : ※ 引述《tyc5116 (累人啊....)》之銘言： : : 原本還以為可能PO錯板,沒想到得到這麼多人的回應..(笑) : : 單純就是我的看法和主管不同,只是反應出來看看大家的看法而已 : : 我也覺得稍微作個處理就可以分辨是哪個模組進到func了 : : 但是主管就覺得這個方式不妥@@ : : 因為他資深,我資淺,對於他說會對於debug造成麻煩 : : 我只是"感覺"會比原來的方式好才對,但我並沒辦法量化 : : 也無法百分百的保證,新的方式一定就好比較好,大致上就是這樣 : : 推文也有說到,先重構就對了,但是要作過測試 : : 的確,這是應該做的,但這不是我的問題點 : : 測試我也會做(雖然我對測試不是那麼在行) : : 而是說,我重構了,測試了,真的沒問題了,但是程式看起來重構前和重構後差滿多的 : : (至少覺得我站在主管的立場來看,會這樣想),對於公司來說,就是個風險 : : 基於這樣,我才會先詢問主管的意見,既然他不同意就算了 : : 我的出發點在於,日後在修改維護會很有彈性,便利 : : 程式碼越少越不會出錯,別人看不看的懂是別人的事(註) : : 實際上那些模組的其中一個func是去讀取xml的資料,功能是對的 : : 但是演算法效率不好,才讓我有想改的念頭,先讓程式碼在每個模組變成共用(重構) : : 日後有時間再改良func(改寫),當重構的部份OK了,以後改寫就不用四處都要跟著改 : : 大致上就是這樣 : : 註:這就是我個人的黑暗面了...哈,我會想要盡量將進階的寫作技巧應用在裡面 : : 一方面程式碼少,就容易懂 : : (當然也不是刻意的在賣弄技巧,何況我也還不到那個程度) : : 前面的人把程式碼寫那麼爛,也沒考慮到後面的人阿 : : 我反而是想說,在確保程式碼正確的情況下,能盡量用進階技巧就盡量用 : : 程度不好的看不懂就不敢亂改,程度好的....也不擔心你改了XD : : (有遇過一段傳了好幾個人用都OK的程式碼,到你手上就出了一堆bug, : : 查了半天才發現.原來是上一個人把大家共用的底層亂改的情況嗎XD) : : 也許有人會想說,就把共用的程式碼包成lib就好啦,嘖嘖.... : : 因為我有遇到阿,大家有用了很久的程式碼,只有偶爾會出錯而已,所以大家就將就用 : : 好不容易(其實是湊巧)我找到了他的bug的可能原因,那相關的定義式咧?? : : 抱歉被包起來了 : : 那source code咧? : : 抱歉,傳了太多人,沒有source code了......@@ : 如果不想看落落長的感想文章， : 請直接拉到最下面的網址，一定會有幫助。 : 如果想看，要鞭也請小力點... : 說實在的，這文章回響很大， : 主要是因為，牽扯到程式的「架構」跟「維護」這兩種一定會矛盾的事情， : 每個程式設計師都會因為個人的經驗而有不同。 : 我想所有的程式設計師都會有相同的毛病， : 那就是「眼見為憑」、「前人的錯誤並不會發生在我身上」、「舊的程式碼不如新的」 : 即使身邊的人都建議，但還是要自己碰到釘子再說， : 但「前人」跟「自己」都是人，並不會高竿多少... : 今天跟公司的前輩(上司)討論到這問題，前輩寫了很多年， : 他都可以給我許多的幫助跟經驗。 : 我說：前輩，你認為程式的「穩定」、「維護」、「效率」哪個比較重要？ : 前輩：你覺得哪個重要？ : 我說：我認為穩定 > 維護 > 效率。 : 前輩：跟我說一下理由 : 我說：穩定是程式的基本條件，一個常掛掉、BUG的程式不能賣錢，也是自找麻煩(除錯)。 : 維護跟程式除錯時間與增刪功能有關，維護性高代表不須太多時間在這程式上面。 : 效率是我最後的考量，程式寫得好增加0.001秒，只要使用者無感都沒差， : 當然一定有例外，每分鐘幾十萬資料上下的那種，或者不同需求、大小等， : 但這並不代表我不考慮效率，而是我在穩定與維護之後才會增加效率。 : 前輩：這跟年資有關係。 : 一開始在學校是要求你寫出來，能跑。 : 經驗多一點時，隨便寫都能跑，你就會開始考慮到穩定性， : 因為你隨便寫都寫得出來，但是你的BUG很多。 : 經驗在多一點時，穩定性夠了，你會覺得怎麼自己以前寫的程式都看不懂， : 程式加個功能或刪掉功能都很麻煩，BUG出現時很難找希望找快一點， : 不要每次都全看才能知道BUG可能在哪，你就會覺得維護很重要。 : 經驗在多一點時，像我就會覺得穩定跟維護已經是最最基本的要求， : 而直接針對效率下手了。 : 但是「穩定」與「維護」常常都會「效率」相衝突，甚至三者相衝突， : 這就要看這專案的大小程度來衡量了。 : 我心想：靠，我被間接說菜了~T.T : 前面的推文我都在說「容易維護」，因為根據自我的經歷， : 我大部分都在幫別人或自己的程式做除錯、增刪功能等等，也會開發新程式， : 我常常遇到的問題就是， : 1. 程式是外包寫的，沒說明文件 : 2. 編寫程式的人已經離職、或者在職但他自己因為時間久遠也看不懂或忘了 : 3. 整份程式幾乎沒有幾個地方有註解 : 4. 新增或刪除功能時，幾乎牽一髮動全身 : 5. 看繼承之前先寫族譜 : 還有更機車的不說了。 : 但我很幸運的，我也遇過不少漂亮、容易維護的程式。 : 大致上都有我之前推文說的那兩個共通點。 : 1. 直覺式架構、程式碼 : 有人會說：「直覺這東西跟個人經驗有關，你的直覺別人不一定看得懂，直覺太抽象。」 : 那我會說：「別人無法一眼就看出來就是你的問題。」 : 直覺就是要一眼就看的出來， : 難道你直覺「一個香菸圖像，外面包個圓圈，從左上到右下畫個直線」是禁止開車的符號？ : 難道你直覺變數名稱Length的意義是平方？ : 難道你直覺Class Dog裡面放的是天氣資料？ : 難道你直覺變數相加，c = a + b，要這樣寫 c = (a * 100 + b * 100) / 100？ : 有多少程式設計師還是不重視「直覺式」！ : iPhone連猩猩都會滑了，程式碼內容至少也讓後人看得懂吧！！ : 2. 獨立性高 : BIOS還是組合語言的那時代，更動一行程式碼有時就必須開會一個星期或一個月， : 真的就是牽一髮動全身，舊時代的恐龍BIOS。 : 很不幸的，現在都高階語言時代了還是有不少人這樣做， : 當初規劃架構沒考慮到，導致後面要改倒不如重寫。 : 獨立性高不是單以程式碼的角度來看，是以功能面+程式碼來看。 : 況且獨立性高不代表會有「程式碼重複」問題，但是多執行緒有時必須要這樣。 : 如果今天A、B內的func一模一樣，當然寫成一個就好， : 但是今天A、B內的func少許不同，依照程式決定是否寫成一個， : (但我大多會分開寫，而不是用同一個func再加上判斷) : 舉例來思考： : 小算盤當初只有+-，如果寫出*/是否需要動到一推變數？ : 今天加了*/功能會不會對之前的+-有影響？ : 老闆不爽+，要把它刪除是否困難？會對其他-*/有影響嗎？ : 以上說的是個通則，一定會有例外情況， : 大量處理、記憶體或硬體容量極小、銀行相關金錢交易系統等等。 : 謝謝大家也聽我廢話那麼多， : 也許有人認為我不是頂尖的程式設計師，所以我說的話都沒參考價值。 : 也許有人意見跟我相左，這很好，因為這樣子才會互相學到更多經驗，聽到更多東西。 : 我喜歡的文章之一 : http://local.joelonsoftware.com/wiki/The_Joel_on_Software_Translation_Project: : 你絕對不應該做的事 : 當你肚爛別人程式看不懂時，也請想想自己寫了多少； : 當你覺得別人程式易懂易改時，請讚嘆他是如何寫的； : 當你覺得別人程式不好時，請先思考他為什麼這樣寫。這版上太多高手了, 純粹來個拋磚引玉, 分享一下小弟的心得希望能看到其他同好一起分享您的前輩正確的基本上, 寫程式到一定經驗後, "維護" 與 "穩定" 真的是基本中的基本與其說 "維護與穩定" 和 "效率" 何者重要倒不如考慮 "彈性" 和 "效率" 何者重要因為相比之下, 彈性與效率才是真的超級相衝突離題了....拉回來在以前還是個小菜鳥的時候, 剛接手一個系統的程式碼, 當時也是有遇過您現在遇到的問題 1. 程式裡面很多的重複碼 2. 程式裡面一堆東西沒有註解 3. 客戶(老闆) 一天到晚要加新功能 (但是不加薪) 剛開始, 也就是超級菜的時候, 我的行為準則就是.... 1. 原始的程式碼不動, 除非出現錯誤需要修正 2. 在原始程式碼的某些地方加入一些不影響原始動作 "介面", 方便未來我插入新功能這時候我所顧慮的是....彈性因為原始程式碼的穩定度已驗證過, 所以我可以排除穩定性的問題壓根沒考慮過效率問題再來是真的有新需求需要加入新功能後....我才顧慮到 "穩定" 一如在推文中提到的, 只要有加入或修改任何動作, "測試" 是必需的更別提我部門現在都要求的是 "壓力測試" 再過了一段時間之後, 也就是經過了幾次的 debug + 新功能需求才會對這系統越來越熟析, 就會發現有些地方可以 "重構", "合併" or "省略" 當然, 前提如版友提到的, 您需要對該系統有一定程度的熟析, 並且完成後要嚴厲的測試有這樣的認知的話....為什麼不做呢再過了一段時間之後, 您甚至可能會發現...這系統已經不行了, 乾脆砍掉重練並不是當初設計者設計的不好, 有可能如您遇到的問題....中間經手太多人要知道, 每個人風格習慣各自不同, 光是同一個問題, 10 個人可能就有 20 種解法大公司的系統更是如此, 一堆人維護同一套系統, 裡面可以看到各種不同風貌的寫法另外....不是每個人都是 "有責任感的" 軟體工作者老實說....即使 10 年以上老 RD 的程式碼, 我仍然有看過全域變數滿天飛的哪天怎麼死的都不知道再來就是...舊系統的架構可能已無法負荷新需求, 效率不彰有了這些 "維護" 的經驗, 你才能知道, 設計一套新系統需要考慮的地方這些大概是我當年從維護 "舊系統" 到設計 "新系統" 的歷程吧純分享~ 我也不一定對 by the way. 程式的效率...真的很重要, 對一個資深的工作者來說 -- 生命是一個過程可悲的是他不能重來可喜的是他也不需要重來 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 60.248.105.226

推

jackylu63

07/26 10:37, , 1^F

07/26 10:37, 1^F

→

yyc1217

07/26 10:59, , 2^F

07/26 10:59, 2^F

推

dyco

07/26 12:28, , 3^F

07/26 12:28, 3^F