看板
[ Soft_Job ]
討論串抄捷徑的技術債，遲早要還的
共 7 篇文章
內容預覽:
我就是那傳說中RD人見人厭的PM. 打掉重練，姑且不說有可能練完之後會不會比較好，這還要看設計的人，如果更強，. 或是原設計人來重構，通常可以更好。. 假設可以保障重構完可以更好，就開始做了嗎??. 先想想你是在甚麼單位?? 學術? 法人? 私企??. 如果前二者，甚至是OSF，就打掉重練吧。不趁現
(還有484個字)
內容預覽:
我是不懂你說的整隻打掉重練. 是要打掉多大的東西. 現有的程式可以用. 如果你要打掉重練.... 那要多久可以讓程式正常運作?. 一年...不接受是正常的. 如果你的變動影響範圍很廣. 我想一般管理者都一定不會同意你大改的. 重構通常也是一點一點慢慢改. 真的改不了的話.... 重新開發新的算了XD
(還有29個字)
內容預覽:
說真的,我覺得有時候這問題是互相的~當然對工程師而言怎麼看都是只有問題有沒有解. 我們公司就曾經軟體發生一重大問題,這問題是可以用不符原架構的方式去解決,. 類似多個旗標去擋(總之就是快速偷懶但不是解根本).. 好了~問題來了,開會時別team都說他們好早就採用這解了,而那位小主管堅持整隻要打. 掉
(還有77個字)
內容預覽:
就是為了以後要跳槽要升遷，所以當年我選擇乖乖做重構。. 搞清楚什麼情況可以作到什麼程度、哪時候該做哪時不該做，就會累積一些經驗。. 我個人不相信class結構的設計是可以入行就有的，能夠一開始就開出良好規格的能力. ，是在多次對相似情境的架構重構之後才有的。. 而且重構最大的目的是將程式碼的複雜度壓
(還有385個字)