Re: [討論] 一個Programmer該維護幾行程式碼?

看板Soft_Job作者時間12年前 (2014/01/16 14:01), 編輯推噓3(3012)
留言15則, 7人參與, 最新討論串4/5 (看更多)
※ 引述《oaz ()》之銘言: : 標題: Re: [討論] 一個Programmer該維護幾行程式碼? : 時間: Thu Jan 16 11:24:40 2014 : : 重構是你的好幫手 : 你可以一邊重構,一邊理解程式碼 : ※ 引述《C6H5CH3 (........)》之銘言: : : 最近調單位, 接了一個專案, 上頭說將來要由我維護 : : 看code看了快3個月, 還是摸不清整個軟體的架構, 挫折感非常重 : 會不會是你看的方式有問題 : 我遇過有人看程式碼是從 main() 開始看的。 : : 我的話,我會挑一個明顯的功能,然後再找出這個功能所對應的程式碼 : 然後,加了一些 print ,再把這個功能跑過,就可以大概理解這個功能了 : : 至於,如何找出這個功能所對應的程式碼 : 我通常是挑一個 UI 上看得到的特別的字串,然後對程式碼搜尋 : : 每段code都艱深難懂, 隨便一個if case都3層以上 : 如果太多層,試著把 if 提出函式 : : 每個function長度以百行為單位 : : 主管說, 按照前人的慣例, 應該一個半月就該上手 : : 理所當然我被噹了, 我看了三個月還懵懵懂懂 : : 而且每段code看起來都似曾相似, 好像在哪看過, 又好像不太一樣 : 看起來應該是有很多重複的程式碼 : 儘量提出函式 : : 索性寫了個小程式, 計算一下這個project有幾行程式碼 : : 算完後發現總共有200多萬行 : : 但是當初別人在demo這個程式時, 我壓根不認為這樣的project需要寫成200多萬行 : 聽起來是有很多重複的程式碼 : : 現在問題來了, 主管前輩們認為我應該要獨當一面, 把這個project接起來 : : 如果換作各位, 你們會怎麼作? 想聽聽大家的想法? : 最後,重構需要一個好用的版本控制系統,個人推 Git : : -- : ※ 發信站: 批踢踢實業坊(ptt.cc) : ◆ From: 140.112.30.46 : → fuha:小心 很多code 是累積的 小心產生新bug 01/16 11:33 : 推 xatier:通靈時請繫好安全帶 (版本控制) 01/16 11:54 : → cha122977:是說如果這個proj有版本控制 也可以先回到前面版本看 01/16 12:37 : 推 chchwy:重構也是要很花時間成本的喔 啾咪 01/16 13:03 看 code 也是要花時間成本啊 : → fuha:有時候沒有真正了解前人寫的code最好小心點改不然就.... 01/16 13:04 : → fuha:尤其是那種一堆 if else 或是一個 function 有幾百行那種 01/16 13:05 關於重構,我認為需要解釋一下 一、重構是要小心,要避免產生新的問題 這點我同意,因此,要有版本控制系統, 甚至,有個自己個人用的版本控制系統,都會有很大的幫助。 只要不要進到產品線就可以了 再者,出問題就可以很容回溯,發現是哪個改變出問題 二、重構有分大小的 有些是幾乎不會錯的,有些則風險很大 風險小的如:改變數名稱、為一個魔術數字定義常數,將一段程式碼提成一個函數 當然,再小的改動也是有風險,就算是改變數名稱,也有可能用到已經在用的變數名稱。 不過,這些的風險相對小 對於一個函式有幾百行那種, 我個人的經驗是,如果把其中一段提成函式並且不要改變邏輯,通常這不太會有錯。 而且,往往很容易發現其它地方有類似的地方可以改呼叫新的函式 三、儘量用多個小的重構取代一個大的重構 重構很重要的一點就是在不影響外在的行為(包含引進錯誤) 而小的重構是很容易看出改動前後是不是行為一樣。 事實上,許多小的重構往往對之後大的重構有很大的幫助。 另一個是,如果出錯了,回溯發現是某個改動有問題, 小的重構比較容易還原或修正 : → f1234518456:不如每天捲程式碼 看看等薪水下來比較實在 01/16 13:09 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.46

01/16 14:04, , 1F
問題是, 充滿小型重構機會的專案, 都是架構本來就比較健康的
01/16 14:04, 1F

01/16 14:06, , 2F
房間如果不趁還不太亂的時候整理, 就會連整理的空間都沒有了
01/16 14:06, 2F
我反倒認為,架構本來就比較健康的,比較不太需小型重構機會 應該是這樣說,如果一開始就重視架構的人,平常就會做一些小型重構了 而那些不重視架構的人,對於一些小的重構則就懶得做 舉個例子,就拿重複的程式碼來說, 重視架構的人很早之前,甚至在設計階段就會提成函式 不重視的人,一開始很容易為了方便,省時,就很快複製、貼上、修改 ※ 編輯: oaz 來自: 140.112.30.46 (01/16 14:24)

01/16 16:19, , 3F
你說的沒錯, 不過我也覺得健康的關鍵之一是最初是否有採用
01/16 16:19, 3F

01/16 16:20, , 4F
發展起來相對靈活的架構, 如你所說, 小型重構往往不是問題
01/16 16:20, 4F

01/16 19:10, , 5F
幾百萬行怎麼構阿 有請大師指點指點
01/16 19:10, 5F

01/16 19:42, , 6F
的確不熟系的兩百萬行重構好像很難有信心不出包..
01/16 19:42, 6F

01/16 21:52, , 7F
10萬行以內進行整體重構經驗的人, 我想也不會太多
01/16 21:52, 7F

01/16 21:52, , 8F
更不用說200萬行這種天文數字了
01/16 21:52, 8F

01/16 22:47, , 9F
再小的重構都有風險~而且測試也花時間~然後如果領域知識不
01/16 22:47, 9F

01/16 22:48, , 10F
足就完了~一個個自以為的命名只會更亂...
01/16 22:48, 10F

01/17 01:26, , 11F
說真的真的很討厭那種if else內容都一樣,只有一點差異的
01/17 01:26, 11F

01/17 01:26, , 12F
真是懶到一個程式,後面的人要改也不好修
01/17 01:26, 12F

01/17 01:27, , 13F
看過那種if else裡面各又包一個if else,然後四段內容都差
01/17 01:27, 13F

01/17 01:28, , 14F
不多的,真的很搞不懂為什麼不花點心思把架構弄好
01/17 01:28, 14F

01/20 21:41, , 15F
沒有註解才可怕...50多萬行註解不到0.1成,崩潰!!!!
01/20 21:41, 15F
文章代碼(AID): #1IrtMZh0 (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1IrtMZh0 (Soft_Job)