可複用性，可測試性，代碼複雜度降低和可展示性編程重要性

Question

有很多編程和體系結構模式。模式允許代碼更清潔，可重用，可維護，更可測試&終於（但不是至少）感受到跟隨者是一個真正的酷開發者。

你如何評價這些考慮？當你決定應用模式時，最吸引你的是什麼？

我不知道多少次代碼的可重用性（特別是對於MVP，MVC模式）很重要？例如DAL庫經常在項目之間共享（它是可重用的），但控制器/視圖（通過接口抽象）多久會被重用？

Answer 1

如果我把事情簡單化，代碼複雜度降低很高，我可以更好地維護項目並更快地處理它以添加/更改功能。

可重用性是一種工具，它有其用途，但不適用於任何地方。我通常會重構那些在三個以上地方顯示相同使用歷史的組件的可重用性。否則，我冒着在一個或兩個地方遇到專門行爲的需要，最終將一個組件分解成幾個具有相似結構的專業組件，但如果將它們放在一起很難理解。

可測試性並不是我個人投入的大量精力。然而，它在很多情況下都是從降低的代碼複雜度中派生出來的：如果沒有太多的依賴關係和複雜的代碼路徑，那麼將會減少測試的危險或者使它們更難執行。

至於炫耀能力......好吧......客戶對應用程序的表現感興趣，而不是根據他的要求來表達他的想法，而不是關於我的代碼的「酷炫」。 'nuff says

Answer 2

我想你錯過了列表中最重要的一個 - 更易於維護。代碼結構良好，結構一致（使用簡單的可重用代碼時）更容易維護。

至於reusablilty，那麼是的，在許多場合，通常是這樣的：創建一個網頁來保存/更新某些記錄。幾個月後 - 我們需要將此作爲第三方使用的服務公開 - 如果您的代碼結構良好，應該既簡單又低風險，因爲您只需添加新的前端。

Answer 3

我希望大多數人使用模式來學習如何在特定環境下解決設計問題。您提到的所有非功能性需求可能非常重要，具體取決於項目利益相關者的需求。 對於MVC等，它並不意味着只能在項目之間重複使用，這通常是不可能的或者是一個好主意。您從MVC中獲得的好處在您使用該架構的項目中應該很重要。您可以獨立更改視圖和模型中的細節，您可以針對不同模型重新使用控制器的視圖，您應該能夠更改持久性細節而不會影響控制器和視圖。在單個項目的開發過程中，這一切都非常重要。

Answer 4

許多書中定義的「代碼可重用性」或多或少都是一種神話。嘗試着重於易於閱讀 - 易於維護。不要着眼於「可重用性」，如果你開始首先考慮可測試性，然後重用某些東西，會更好。重要的是提供，測試，清理代碼，重構，不重複自己，重要的是從開始構建可以在項目之間重用的組件。無論重複使用什麼，都必須是一個自然的過程，更像是一個發現：你會看到一個重複，所以你建立了一些可以在特定情況下重用的東西。