[討論] 前人的code 後人翻寫的機率高嗎?

看板Soft_Job作者 (丁守中)時間7年前 (2018/09/24 20:43), 7年前編輯推噓21(23推 2噓 56→)
留言81則, 34人參與, 7年前最新討論串1/8 (看更多)
大家中秋節快樂，快收心了。 想問一個假設性問題，大家在工作上，如果有一份專案的 code 是某位前人一手寫的 後來新人加入，變成前人帶新人，此時繼續維護那份code。 但再過一陣子，前人離職了，唯一的創始者走了。 新人把舊 code 重構，或是砍掉重鍊的機率高嗎？ 我的想像是，如果一份code是出自於1個人之手 那麼code就是他的世界觀、他的切入點 後面的人看著他的世界觀，有時候不一定能全部接受 而有人的地方就有政治 當他還在的時候，當然就不會亂動。 而當他走了的時候，後面的人，一看不爽，就可能改寫成自己看得爽的、 好改的code。 如果是一個團隊，那當然要好好討論為什麼要改 哪些因素造成現在不好的情況，以及主管同不同意改等等的。 只是我很好奇，1,2人的專案，改的機率高嗎？ 是不是，code只能是「現在還存在公司的人」能控制的才行。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 124.6.15.211 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1537793002.A.FC8.html
推
09/24 20:46, 7年前 , 1F
重構的好處在那裡，有比重構完整個系統壞掉的風險高嗎
09/24 20:46, 1F
→
09/24 20:46, 7年前 , 2F
就算系統重構好可以正常行為，重構花掉的成本算誰的
09/24 20:46, 2F
所以大大的經驗是 東西沒壞 就不要亂重構嗎？ ※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:48:15
推
09/24 20:48, 7年前 , 3F
想改就改啊..不過我碰到的都是新人裝死..懶得改..責任推給
09/24 20:48, 3F
→
09/24 20:48, 7年前 , 4F
前人XDD
09/24 20:48, 4F
推
09/24 20:49, 7年前 , 5F
不是說不要亂重構，你重構的好處要大於重構的成本跟風險
09/24 20:49, 5F
→
09/24 20:50, 7年前 , 6F
不然你只是看不順眼就重構，對之後維護沒有特別幫助
09/24 20:50, 6F
我知道要看目的，以及成本~ 是想問最後結果會重構的機率高不高XD 八卦一下
→
09/24 20:54, 7年前 , 7F
一般來說，要重構通常是要加需求但是改不動了只好重構
09/24 20:54, 7F
→
09/24 20:54, 7年前 , 8F
前人有時候規劃時寫太死，或是架構只有規劃的人懂，後人
09/24 20:54, 8F
→
09/24 20:55, 7年前 , 9F
要看成本阿
09/24 20:55, 9F
是的~ 但想問最後結果是會還是不會XD
→
09/24 20:55, 7年前 , 10F
維護起來太困難就會打掉重寫（小公司可能兩三年就一個輪
09/24 20:55, 10F
→
09/24 20:55, 7年前 , 11F
迴
09/24 20:55, 11F
感謝回應 ※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:56:43
→
09/24 20:56, 7年前 , 12F
我的切入點是重構減少未來的維護成本
09/24 20:56, 12F
→
09/24 20:56, 7年前 , 13F
漏字，減少未來多少的維護成本
09/24 20:56, 13F
※ 編輯: peanut97 (124.6.15.211), 09/24/2018 20:57:54
→
09/24 20:57, 7年前 , 14F
但這得要你老闆有技術背景聽得懂，或是非常信任你
09/24 20:57, 14F
推
09/24 20:57, 7年前 , 15F
如果沒問題的 code ，重寫代表要重測 ，能保証重寫的更好嗎
09/24 20:57, 15F
→
09/24 20:57, 7年前 , 16F
？
09/24 20:57, 16F
推
09/24 20:57, 7年前 , 17F
講得出來怎麼改善就改阿 比較怕改完只有風格變了而已
09/24 20:57, 17F
→
09/24 20:59, 7年前 , 18F
高不高看時間有沒有給你 同時新需求跟重構你趕得上嗎
09/24 20:59, 18F
推
09/24 21:00, 7年前 , 19F
自己偷偷開一個分支改阿XD
09/24 21:00, 19F
推
09/24 21:03, 7年前 , 20F
要看，重構花時間成本，老闆不一定願意讓你做，除非有
09/24 21:03, 20F
→
09/24 21:03, 7年前 , 21F
要加幾個大功能或效能改進
09/24 21:03, 21F
→
09/24 21:05, 7年前 , 22F
尤其前人寫的很少會有test case
09/24 21:05, 22F
→
09/24 21:08, 7年前 , 23F
我比較機車 第一款出來之後接著改版UI 然後我覺得我寫的
09/24 21:08, 23F
→
09/24 21:08, 7年前 , 24F
很爛所以我多要了一個月砍掉重寫 但我沒說我全部砍掉重
09/24 21:08, 24F
→
09/24 21:08, 7年前 , 25F
來
09/24 21:08, 25F
→
09/24 21:22, 7年前 , 26F
通常翻寫是換語言，十年以上歷史
09/24 21:22, 26F
推
09/24 21:23, 7年前 , 27F
FLAG之流的公司 平均年資也是三到五年 難不成這些公司每
09/24 21:23, 27F
→
09/24 21:23, 7年前 , 28F
三到五年就重構嗎
09/24 21:23, 28F
→
09/24 21:23, 7年前 , 29F
另外一個人只揹一個案子真是太幸福了
09/24 21:23, 29F
→
09/24 21:24, 7年前 , 30F
重構是有工時跟時間成本的 不是你愛幹嘛就幹嘛XD
09/24 21:24, 30F
推
09/24 21:26, 7年前 , 31F
開這條戰線出來你要hold住 不然你沒弄好大概變戰犯
09/24 21:26, 31F
推
09/24 21:28, 7年前 , 32F
而且很多時候除了設計上要做改善或改良，為了求未來穩定或要
09/24 21:28, 32F
→
09/24 21:28, 7年前 , 33F
完整輸入出結果不會因為重構影響 還會有很多test要測
09/24 21:28, 33F
推
09/24 21:29, 7年前 , 34F
看重要性, 越重要越不可能隨便重購
09/24 21:29, 34F
推
09/24 21:30, 7年前 , 35F
如果你的問題只是coding style的問題 就看怎麼拿捏 因為在
09/24 21:30, 35F
→
09/24 21:30, 7年前 , 36F
少人團隊還是會專注於解決當下問題
09/24 21:30, 36F
→
09/24 21:30, 7年前 , 37F
主管寧願多花幾倍成本作測試也不會承擔重構壞掉風險
09/24 21:30, 37F
→
09/24 21:30, 7年前 , 38F
重構要長期維護跟遇到真實的瓶頸或遇到設計、擴充上的問題才
09/24 21:30, 38F
→
09/24 21:30, 7年前 , 39F
會動刀
09/24 21:30, 39F
→
09/24 21:31, 7年前 , 40F
一個系統的核心程式非常多 你重構幾個小部分是沒有意義的
09/24 21:31, 40F
→
09/24 21:36, 7年前 , 41F
有一本書 叫做clean code，可以看看
09/24 21:36, 41F
噓
09/24 22:06, 7年前 , 42F
正常智商的老闆不會讓你這樣幹
09/24 22:06, 42F
推
09/24 22:38, 7年前 , 43F
幹嘛翻 花自己時間耶 又不是自己公司
09/24 22:38, 43F
推
09/24 22:42, 7年前 , 44F
除非有重大瑕疵 否則公司又不是做藝術品 當時沒做好的就沒做
09/24 22:42, 44F
→
09/24 22:42, 7年前 , 45F
好 像那種程式後面常常會被講是黑盒子XDD
09/24 22:42, 45F
→
09/24 22:58, 7年前 , 46F
韌體 重構和porting 前人吃過的硬體屎 還要吃一遍...
09/24 22:58, 46F
推
09/24 22:58, 7年前 , 47F
對一個已經上production的系統而言，重構跟重新投胎有87
09/24 22:58, 47F
→
09/24 22:58, 7年前 , 48F
%像...
09/24 22:58, 48F
→
09/24 23:02, 7年前 , 49F
專案數千聲音 分類+隱藏規格數十 跨三家IC i/o硬體會錯
09/24 23:02, 49F
→
09/24 23:03, 7年前 , 50F
都開賣囉。就問誰敢重構QQ
09/24 23:03, 50F
→
09/24 23:15, 7年前 , 51F
我一介小小打工仔 還是pass
09/24 23:15, 51F
推
09/24 23:38, 7年前 , 52F
有問題誰背 時間太多嗎 我會叫你去弄新專案
09/24 23:38, 52F
→
09/24 23:39, 7年前 , 53F
每次離職 code就要重搞 公司又不是瘋了
09/24 23:39, 53F
→
09/24 23:43, 7年前 , 54F
很多時候就算你有實力重改，也因為上面的決定無法重做
09/24 23:43, 54F
推
09/25 00:09, 7年前 , 55F
會先寫好測試再來談重構
09/25 00:09, 55F
推
09/25 00:41, 7年前 , 56F
我們team機率是很高啦，前人留下太多債，現在碰到很多
09/25 00:41, 56F
→
09/25 00:41, 7年前 , 57F
評估再加功能會邊難以測試的架構，所以常常重構。
09/25 00:41, 57F
→
09/25 01:18, 7年前 , 58F
這是政治問題 老闆87%不會同意花錢 花時間 做同樣的東西
09/25 01:18, 58F
→
09/25 01:19, 7年前 , 59F
你的直屬長官更不會同意重寫 因為這證明以前他走錯方向了
09/25 01:19, 59F
推
09/25 01:26, 7年前 , 60F
一般是從小做起 摸到的部分開始一點一點重構 而不是 「我他
09/25 01:26, 60F
→
09/25 01:26, 7年前 , 61F
媽要重構全部程式啦！」這樣吧
09/25 01:26, 61F
推
09/25 06:28, 7年前 , 62F
我負責的code + 我看不爽 = 翻
09/25 06:28, 62F
推
09/25 08:16, 7年前 , 63F
翻寫ok 但是我經驗是，不要有一種自己的優越心態去面對
09/25 08:16, 63F
→
09/25 08:16, 7年前 , 64F
這種code，很多看起來很詭異的workaround都是因為前人
09/25 08:16, 64F
→
09/25 08:16, 7年前 , 65F
碰過某些難以越過的困難才這樣做
09/25 08:16, 65F
→
09/25 08:17, 7年前 , 66F
這些困難也許是其他系統造成的 也許真的是一開始就長歪
09/25 08:17, 66F
→
09/25 08:18, 7年前 , 67F
也許現在也不存在，總之，別太狂戰士
09/25 08:18, 67F
→
09/25 09:36, 7年前 , 68F
除非你能在維持正常工作的情況下還能重寫，不然老闆幹嘛讓
09/25 09:36, 68F
→
09/25 09:36, 7年前 , 69F
你花很長的時間停擺現有工作，只為了讓你改你覺得不好的東
09/25 09:36, 69F
→
09/25 09:37, 7年前 , 70F
西?這種要嘛是流程已經大改，可是前面的人偷懶用很迂迴的
09/25 09:37, 70F
→
09/25 09:37, 7年前 , 71F
方式一直加垃圾，要嘛就是現有方法已經沒辦法更新新需求或
09/25 09:37, 71F
→
09/25 09:37, 7年前 , 72F
是你的專案重要性不高，不然通常就加減用。除非你能力真的
09/25 09:37, 72F
→
09/25 09:37, 7年前 , 73F
很好，超越了你前面的所有人…
09/25 09:37, 73F
→
09/25 10:44, 7年前 , 74F
手上多少資源做多少事 吃飽太閒才會想要改改改
09/25 10:44, 74F
→
09/25 10:46, 7年前 , 75F
改不是當下爽就好 要有引發後續種種連動議題的心理準備
09/25 10:46, 75F
→
09/25 13:03, 7年前 , 76F
時間成本問題 除非有特定原因 EX:想逃避面對舊CODE出的問題
09/25 13:03, 76F
→
09/25 13:04, 7年前 , 77F
或是"期望公司能更上一層樓"等 不然我想像不到"推翻"舊CODE
09/25 13:04, 77F
→
09/25 13:04, 7年前 , 78F
的動機..= =a
09/25 13:04, 78F
推
09/25 19:28, 7年前 , 79F
看成本啊
09/25 19:28, 79F
噓
09/26 07:52, 7年前 , 80F
Test Case全pass想怎麼改誰管你
09/26 07:52, 80F
推
09/26 11:39, 7年前 , 81F
回樓上，會有這種code，通常也不會做 testing ...
09/26 11:39, 81F
‣ 更多 peanut97 的文章
文章代碼(AID): #1RgDlg_8 (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 8 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 peanut97 的文章
文章代碼(AID): #1RgDlg_8 (Soft_Job)