Re: [討論] 重構跟kpi的考量

Gaitz02/27 01:10這麼說來你們會在所謂的需求穩定後，停下來大規模的重寫重

Gaitz02/27 01:10構改好架構？還是最後根本沒有時間而且又要開發新需求，然

Gaitz02/27 01:10後說需求沒有穩定？永遠沒有做好？

Gaitz02/27 01:14有新需求會被共用的地方卡住這件事聽起來很奇怪，覺得單一

Gaitz02/27 01:14責任原則沒有做好。

accessdenied02/27 01:16不贊成。初期就這樣做，只會遺留一大堆90%相似只有1

accessdenied02/27 01:160%客製的程式碼，然後未來修改，只敢全文搜索 find

accessdenied02/27 01:16 replace

accessdenied02/27 01:17而且，一旦分開管理，我保證沒人有勇氣統整回來

xenorock02/27 01:27我看法同樓上，沒有先Design好，分割完全，全部搞在一起

xenorock02/27 01:27後面有的痛苦

t6414102/27 01:33初期到處貼你要有把握後期能整理，不然後面維護的人就會

t6414102/27 01:33變下一個原原po，很容易惡性循環的

t6414102/27 01:37至於被共用卡住的問題，遇到特例難以擴充再另外實作就好

t6414102/27 01:37，維護時因為特例而重複比初期就到處貼的副作用小多了

MyNion02/27 02:23我覺得你會被卡住，就代表一開始方法＆功能就沒拆好了

MyNion02/27 02:25將程式模組化，增添彈性的接口供外部呼叫

MyNion02/27 02:29如果這樣還不行，那就代表從一開始這兩者就毫無相同之處

MyNion02/27 02:29本來就要分開寫了

TakiDog02/27 02:39程式碼要增加很容易，要減少太難，那為何一開始不規劃好

labbat02/27 03:06本來只要做加法函數，結果做成通用算數函數

labbat02/27 03:09不如一開始就設計通用算數函數 改壞了也只是大家一起壞掉

geroge082002/27 03:14推文完全文不對題... 重點是需求還不穩定這件事吧

wulouise02/27 09:40可以共用的code怎麼可能會大到需求改變就一堆特例

wulouise02/27 09:41通常都是srp沒處理好才在怕改A錯B

handsomeLin02/27 11:28如果會有發現重複code然後還複製貼上的話就是design

handsomeLin02/27 11:28不行

kkes000102/27 11:48絕對不要這樣做

foreverk02/27 13:42會被共用程式碼卡住，就代表沒抽乾淨，應該要去釐清邏

foreverk02/27 13:42輯，而不是跑去貼一堆重複code然後事後才要處理吧，本

foreverk02/27 13:42末倒置

foreverk02/27 13:44會覺得要花大量時間測試，就代表一開始你就沒有寫好uni

foreverk02/27 13:44t test

srwhite02/27 13:50反了吧應該先寫一起等真的有不同要複製再複製啊

t6414102/27 14:46需求不穩定不是重點，一開始到處複製，需求變化過程要改

t6414102/27 14:46就已經需要到處翻找了，即使等需求確定後也是要面臨重構

t6414102/27 14:46的問題，萬一屆時已經上線更悲劇

neo527702/27 15:17這篇是用接案公司的想法出發寫MVP的時候吧?

viper970902/28 00:08對系統還不夠了解時,這才是比較實用的+1

Nonsense802/28 10:19樓主沒說錯，這適用於未上線的專案，如果老闆在開發中

Nonsense802/28 10:19要求大改，主管有責任爭取上線後重構時間。甚至需求大

Nonsense802/28 10:19改也不是老闆的責任，尤其市場上沒有其他競品可以參考

Nonsense802/28 10:19時，才會不時在開發中更改需求

Nonsense802/28 10:21但原文的情境應該是上線後營運很久的專案，就不適合這

Nonsense802/28 10:21種作法了