※ 引述《markzog21 (殘羽星辰)》之銘言:
: 因為板上有在討論
: 而小弟最近也在看這方面的書(如果表達有誤請見諒XD)
: 突然有個疑問
: 我們常常覺得前人留下來的技術債很大
: 所以思考要重構
: 因此我們開始重新規劃整個系統
: 但會不會我們陷入了另一個陷阱
: 就是我們自認為此系統架構的最佳解
: 卻恰恰是下一個接手人覺得的"技術債"?
: 或許下一個接手人與我們自己的想法不同
: 於是我們想到的最方便解決的方式(也可能真的是不太好的方式)
: 就成為了下一個接手人心中罵聲連連的"技術債"?
: 一個好的系統架構uml應該不全然是教科書上面的教案範例
: 而是因時制宜的解決方案(這是小弟的拙見,如有不對請指教,但請手下留情...)
: 但其實我也不太知道
: 一個讓下一個接手的人感謝的系統架構
: 應該長什麼樣子
: 所以上板來詢問大家看看
: 怎樣的架構是
: 你曾經看到前人留下來讓你感謝不已的系統架構或解決方案?
: 還是說寫程式的人
: 寫的好是應該
: 寫不好就該...
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.42.236.144
※ 編輯: thinkniht 來自: 114.42.236.144 (02/07 00:45)
我覺得這問題問得不錯
我曾經遇過有人因為功力不夠
程式是越改越爛
(而且不是產生bad smell,而是產生一堆Bug=.=)
每個人因為其背景的不懂
對於同樣架構可能會有不同的評價
甚至有時候當環境改變時
原本適當的寫法就變成一種阻礙了
有種軟體開發的方式叫pair progamming
採取兩個人一起用一台電腦開發的方式
如果使用這樣的方式進行重構的話
我想就比較"有可能"避免掉這樣的問題
不過我要申明幾點
1.我其實沒用過這種方法(台灣很難能找到有老闆讓人玩這種開發方式吧)
2.這只是個人推斷這樣"可能"有用
3.甚麼樣的人搭配也可能影響結果
最後個人想說...
我覺得程式沒有最佳解
不管你寫得再漂亮 考慮得再多
當環境或需求改變時
改一改程式之後
都可能變成爛code(所以才需要重構咩)