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

看板Soft_Job作者時間12年前 (2014/01/16 11:24), 編輯推噓6(6014)
留言20則, 13人參與, 最新討論串3/5 (看更多)
重構是你的好幫手 你可以一邊重構,一邊理解程式碼 ※ 引述《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

01/16 11:33, , 1F
小心 很多code 是累積的 小心產生新bug
01/16 11:33, 1F

01/16 11:54, , 2F
通靈時請繫好安全帶 (版本控制)
01/16 11:54, 2F

01/16 12:37, , 3F
是說如果這個proj有版本控制 也可以先回到前面版本看
01/16 12:37, 3F

01/16 13:03, , 4F
重構也是要很花時間成本的喔 啾咪
01/16 13:03, 4F

01/16 13:04, , 5F
有時候沒有真正了解前人寫的code最好小心點改不然就....
01/16 13:04, 5F

01/16 13:05, , 6F
尤其是那種一堆 if else 或是一個 function 有幾百行那種
01/16 13:05, 6F

01/16 13:09, , 7F
不如每天捲程式碼 看看等薪水下來比較實在
01/16 13:09, 7F

01/16 13:42, , 8F
還沒瞭解就重構?這樣好嗎?互相摻雜~確定不會弄得更亂?
01/16 13:42, 8F
當然要先看過一部分程式碼才做重構 但是,不用整個架構都了解八九成了,才做重構 先挑一個明顯的功能就可以了 事實上,在《重構》-- 改善既有程式的設計中 (http://jjhou.boolan.com/jjtbooks-refactoring.htm) 有一章關於「何時重構」? 有一段 無論何時只要我想理解程式碼所做的事,我就會問自己:是否能 對這段程式碼進行重構,使我能更快理解它。然後我就會重構。 也提過,重構有助於復審 (code review) 這些是作者的經驗談,也符合我個人的經驗。 至於互相摻雜弄得更亂的話,那也沒關係,就放棄這個重構,去找下一個 所以說,版本控制系統是很重要

01/16 17:05, , 9F
refactor->test->refactor->test->refactor->test->.....
01/16 17:05, 9F

01/16 19:18, , 10F
->rewrite
01/16 19:18, 10F

01/16 19:40, , 11F
有暗黑程式碼暗黑變數,一動程式就在其它地方爛掉怎麼辦?
01/16 19:40, 11F
爛掉就爛掉 :) 應該是說,只要不會進到產品線,就算改爛了也無所謂吧 :) 所以我才會說,有一個「自己用」的版本控制系統很重要 大不了就所有的重構都放棄,而且這不會做白工 原 po 的目的是讀懂既有的程式 要考慮的是,如果改了十個地方才在一個地方出錯 那其它九個是值得的(尤其是重構後的程式碼有助於理解更多程式的時候)。 而且如果之後需要修正錯誤,新加功能時,這九個說不定可以直接拿來用。 此外,如果改爛了,就回頭去找是因為哪一個改動出錯了,為什麼 這樣也可以幫助理解為什麼當初要那樣寫,有沒有更好的寫法 如果只是一味地害怕一動程式就在其它地方爛掉而不敢動程式 往往是因為這種心態導致程式架構愈來愈糟。 我個的人看法是,重要的反而是培養什麼時侯可以做怎樣程度的重構。 如:接近出貨,就只能做小幅度的重構,甚至不可以做。 如果時程很足夠的話,做大一點的也沒關係 如果只是想讀懂程式碼,用一個「自己用」的版本控制系統儘量做吧

01/16 21:17, , 12F
我比較想了解原po從哪邊開始看程式
01/16 21:17, 12F
同感

01/16 22:15, , 13F
砍掉重練增加自己的價值((誤))
01/16 22:15, 13F
※ 編輯: oaz 來自: 140.112.30.46 (01/17 12:12)

01/17 14:19, , 14F
同意這篇的說法,進行重構不管成功失敗都有助於了解專案
01/17 14:19, 14F

01/17 14:20, , 15F
有自己的版本控管的話,大不了就把重構的版本廢掉就好
01/17 14:20, 15F

01/17 14:27, , 16F
有道理耶!!!
01/17 14:27, 16F

01/18 00:04, , 17F
弄亂就放棄下一個...這?弄亂所花的時間真的有幫助~還是只
01/18 00:04, 17F

01/18 00:05, , 18F
是推翻自己之前的假設?假設是錯的~花的時間真的值得?
01/18 00:05, 18F

01/18 00:07, , 19F
另外那一段寫的也是在"自己知道程式在幹嘛"的情況下重構吧
01/18 00:07, 19F

01/18 00:11, , 20F
?看不懂的硬要照自己的意思分...踩地雷修正的機率是???
01/18 00:11, 20F
文章代碼(AID): #1Irr3xfR (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1Irr3xfR (Soft_Job)