→ Gaitz: 這麼說來你們會在所謂的需求穩定後，停下來大規模的重寫重 02/27 01:10
→ Gaitz: 構改好架構？還是最後根本沒有時間而且又要開發新需求，然 02/27 01:10
→ Gaitz: 後說需求沒有穩定？永遠沒有做好？ 02/27 01:10
→ Gaitz: 有新需求會被共用的地方卡住這件事聽起來很奇怪，覺得單一 02/27 01:14
→ Gaitz: 責任原則沒有做好。 02/27 01:14
噓 accessdenied: 不贊成。初期就這樣做，只會遺留一大堆90%相似只有1 02/27 01:16
→ accessdenied: 0%客製的程式碼，然後未來修改，只敢全文搜索 find 02/27 01:16
→ accessdenied: replace 02/27 01:16
→ accessdenied: 而且，一旦分開管理，我保證沒人有勇氣統整回來 02/27 01:17
推 xenorock: 我看法同樓上，沒有先Design好，分割完全，全部搞在一起 02/27 01:27
→ xenorock: 後面有的痛苦 02/27 01:27
→ t64141: 初期到處貼你要有把握後期能整理，不然後面維護的人就會 02/27 01:33
→ t64141: 變下一個原原po，很容易惡性循環的 02/27 01:33
→ t64141: 至於被共用卡住的問題，遇到特例難以擴充再另外實作就好 02/27 01:37
→ t64141: ，維護時因為特例而重複比初期就到處貼的副作用小多了 02/27 01:37
推 MyNion: 我覺得你會被卡住，就代表一開始方法＆功能就沒拆好了 02/27 02:23
推 MyNion: 將程式模組化，增添彈性的接口供外部呼叫 02/27 02:25
→ MyNion: 如果這樣還不行，那就代表從一開始這兩者就毫無相同之處 02/27 02:29
→ MyNion: 本來就要分開寫了 02/27 02:29
→ TakiDog: 程式碼要增加很容易，要減少太難，那為何一開始不規劃好 02/27 02:39
→ labbat: 本來只要做加法函數，結果做成通用算數函數 02/27 03:06
→ labbat: 不如一開始就設計通用算數函數 改壞了也只是大家一起壞掉 02/27 03:09
推 geroge0820: 推文完全文不對題... 重點是需求還不穩定這件事吧 02/27 03:14
推 wulouise: 可以共用的code怎麼可能會大到需求改變就一堆特例 02/27 09:40
→ wulouise: 通常都是srp沒處理好才在怕改A錯B 02/27 09:41
噓 handsomeLin: 如果會有發現重複code然後還複製貼上的話就是design 02/27 11:28
→ handsomeLin: 不行 02/27 11:28
噓 kkes0001: 絕對不要這樣做 02/27 11:48
→ foreverk: 會被共用程式碼卡住，就代表沒抽乾淨，應該要去釐清邏 02/27 13:42
→ foreverk: 輯，而不是跑去貼一堆重複code然後事後才要處理吧，本 02/27 13:42
→ foreverk: 末倒置 02/27 13:42
→ foreverk: 會覺得要花大量時間測試，就代表一開始你就沒有寫好uni 02/27 13:44
→ foreverk: t test 02/27 13:44
→ srwhite: 反了吧應該先寫一起等真的有不同要複製再複製啊 02/27 13:50
→ t64141: 需求不穩定不是重點，一開始到處複製，需求變化過程要改 02/27 14:46
→ t64141: 就已經需要到處翻找了，即使等需求確定後也是要面臨重構 02/27 14:46
→ t64141: 的問題，萬一屆時已經上線更悲劇 02/27 14:46
→ neo5277: 這篇是用接案公司的想法出發寫MVP的時候吧? 02/27 15:17
推 viper9709: 對系統還不夠了解時,這才是比較實用的+1 02/28 00:08
推 Nonsense8: 樓主沒說錯，這適用於未上線的專案，如果老闆在開發中 02/28 10:19
→ Nonsense8: 要求大改，主管有責任爭取上線後重構時間。甚至需求大 02/28 10:19
→ Nonsense8: 改也不是老闆的責任，尤其市場上沒有其他競品可以參考 02/28 10:19
→ Nonsense8: 時，才會不時在開發中更改需求 02/28 10:19
→ Nonsense8: 但原文的情境應該是上線後營運很久的專案，就不適合這 02/28 10:21
→ Nonsense8: 種作法了 02/28 10:21