KISS＆設計圖案

Question

我需要重寫舊的舊版桌面應用程序。這是一個小型的非Java桌面程序，仍然支持幾個內部用戶社區的日常任務。

應用程序既陳舊又不再受支持的語言。我是一名初級開發人員，我需要重寫它。爲了避免app rewrite sinkhole，我打算開始使用現有的數據庫&數據結構（雖然有一些明顯的侷限性，但是像重構一樣痛苦，這種方法可以更快速地完成最初的工作，並避免遷移，這兩者都是成功的關鍵）。

我的挑戰是我對Keep It Simple的概念非常矛盾。我知道它是在討論功能，而不是設計。但是，當我正在編寫這個應用程序時，似乎有很多時間花在追求設計模式上（特別是依賴注入方面，我非常努力），堅持使用好的（但不是「四人小組」）設計可以使工作更快，更簡單地完成。

這個應用程序將會長時間生長，但它永遠不會成爲一個400萬行的企業巨獸，它的對象不會被其他應用程序使用（是的，我知道，但如果是這樣的話。 ... YAGNI！）。

KISS是否曾經適用於建築設計&的問題？可以延長「稍後重構」規則，比如說，「我們稍後會回到依賴注入」，或者如果項目沒有在所有所謂的關鍵框架支持馬上？

我想這樣做「正確」......但它也必須完成。如果我完成它太複雜，無論設計如何，都會失敗。

Answer 1

我會說KISS肯定適用於建築和設計。

過建築是我的經驗，一個共同的問題，而且也涉及這一個代碼味道：

Contrived complexity

被迫的過於複雜的設計模式，其中簡單 設計就足夠使用。

如果使用更高級的設計模式，範例或體系結構不適合您的項目規模，請不要強制使用它。

您必須權衡體系結構的潛在成本與潛在節省量之間的差距......但也要考慮更快實施它的額外時間節省的時間。

Answer 2

是的，KISS，但看到http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/dp/0321213351並考慮重構朝小步驟的設計模式。代碼應該告訴你該怎麼做。