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

看板Soft_Job作者StupidGaGa (笨嘎嘎)時間12年前 (2013/07/26 02:18)推噓7(7推 0噓 26→)

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

※ 引述《tyc5116 (累人啊....)》之銘言： : ※ 引述《oaz ()》之銘言： : : 如果對 debug 只有小影響，那應該是要另外去想其它較好的 debug 方式 : 原本還以為可能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: 你絕對不應該做的事當你肚爛別人程式看不懂時，也請想想自己寫了多少；當你覺得別人程式易懂易改時，請讚嘆他是如何寫的；當你覺得別人程式不好時，請先思考他為什麼這樣寫。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.33.20.138

→

elvispoetic

07/26 02:32, , 1^F

07/26 02:32, 1^F

→

StupidGaGa

07/26 02:37, , 2^F

07/26 02:37, 2^F

推