看板
[ Soft_Job ]
討論串[討論] 前人的code 後人翻寫的機率高嗎?
共 8 篇文章
內容預覽:
這位前輩你好，小弟有些不同的意見. 就算沒有單元測試，"高內聚，低耦合"的原則，也應該是適用的. 所謂斷開相依性更準確地說應該是"相依於抽象而非具體類別". Design Pattern有80%以上的pattern都是在做這件事. 以您提的DateTime為例，若If那行出問題，沒有單元測試的情況下
(還有632個字)
內容預覽:
單元測試有時候反而破壞程式碼的易讀性和維護性. 因為要做到單元測試，就得斷開所有的相依性. 而對抗相依性，作法就是引入 DI。但是 DI 就會增加代碼閱讀和維護的複雜度。. 舉例來說，如果代碼內有時間上的相依性，例如用了 DateTime 物件取得現在時間做某些判斷，原本可以很簡單的寫出易於閱讀和維
(還有593個字)
內容預覽:
這邊想提出點不同意見. 如果太過於為了未來未知的需求而設計. 一旦實際需求與預期相差太遠. 有時候可能會變成過度設計. 過度設計跟不設計我認為是一樣可怕的事情. 至於如何不過度，就需要經驗去掌握. 所以這個說詞不是讓人寫爛code的理由. 但單就這個描述，我覺得不全然一定是錯的. 有看過一些書跟文章
(還有72個字)
內容預覽:
BEN兄講得很好. 我看到底下有人提出一個很好的問題. 重構、SOLID、設計模式、review、unit test 這些東西做起來既麻煩又沒有比較省時. 為什麼要做？. 沒有錯. 敏捷開發的關鍵是敏捷而不是快. 更嚴格來講. 敏捷開發所謂的快. 跟一般認知所謂的開發時程的快. 是完全不一樣的東西.
(還有1361個字)
內容預覽:
先跟主管、老闆提，確認有人支持你，不然你會被當成怪物. 「為什麼要改？」. 「系統好好的幹麻改？」. 「改了有好處嗎？」. 「會花多久時間？」. 「時間剩不多，要動不動隨便你，不要影響到時程」. 我們公司的經驗，以前因為很多原因 (十幾年前的 code). 導致系統沒有測試、沒有嚴謹的 coding
(還有4479個字)