妥協的設計和代碼質量與現有模塊集成

問候！妥協的設計和代碼質量與現有模塊集成

我繼承了一個C＃.NET應用程序，我一直在擴展和改進一段時間。總的來說，這顯然是一項急功近利的工作（或者寫這篇文章的人似乎不如我自己）。該應用程序從嵌入式設備中提取一些數據並對其進行處理。核心是主應用程序表單中的通信線程，該線程執行600多行代碼方法，該方法在整個地方調用函數，實現一個狀態機 - 大量的if-state-then-do類型代碼。與設備的交互是通過全局設置狀態/模式並讓線程完成它的事情來完成的。（這只是代碼糟糕的一個例子 - 總體上它不像OO，它提醒了設備固件寫入的嵌入式C代碼的風格）。

我的問題是這段代碼是應用程序的核心。軟件，通信協議或設備固件根本沒有記錄。顯然，繼續我的工作，我必須與此代碼進行交互。

我想得到的一些指導是，是否值得報廢這個代碼&試圖從我可以逆向工程的信息中拼湊出更合理的東西？我無法決定！我不想重構的原因是因爲代碼已經工作，而改變它肯定會是一個漫長而艱辛的任務。另一方面，不重構意味着我不得不妥協其他模塊的設計，以便我可以從這個狀態機調用我的代碼！

我聽說過「如果沒有損壞就不修復它！」，所以我想知道它是否應該適用於「它」影響未來代碼的設計！任何意見，將不勝感激！

謝謝！

來源

2010-06-11 filip-fku

此處的關鍵是確保您正在重構即改進結構*而不會修改行爲*爲此，在進行任何更改之前，您需要將測試更新到該核心，沒有人喜歡破壞的代碼。 – Gishu 2010-06-11 08:00:41

這取決於您面臨的約束條件，這是基於實際基礎而不是理論基礎的決定。你需要考慮三件事情。

時間：你需要有足夠的時間去學習它，實現它，並對其進行測試，沒有過多的其他任務打斷你
老闆＃1：如果你正在爲一個人，他需要知道並批准你花費的時間和精力，重建你的解決方案所需的時間和精力
老闆＃2：你的老闆也需要知道，擁有新的和乾淨的軟件的優勢將以可能的迴歸爲代價，因此在部署開始時可能會出現意外的錯誤

如果你有這三個，那麼繼續並重構它。這將是值得的！

來源

2010-06-11 07:11:25 Palantir

我肯定會推薦你重構代碼，如果你覺得它的垃圾。是的，在重構過程中，您可能會在開始時遇到一些不一致/問題。但這就是我們進行迭代和測試的原因。既然你將來要建立在這個核心引擎上，爲什麼不讓地下室儘可能地穩定。

但是，要非常確定你要做什麼。因爲有時很長的代碼行並不一定意味着邪惡。另一方面，它們在運行時間上可能非常有效。如果你問我，如果/ else塊不壞，因爲從微處理器的角度來看，它們非常聰明。所以，在你觸摸這個之前，你必須做出判斷並且非常清楚。

但是，一旦你重構代碼，你一定會很好地控制它。並且不要忘記記錄它！明天，有人可能會很好地來和你談論關於這個寫這個核心代碼的人的任何事情。

來源

2010-06-11 07:01:57 bragboy

此外，您等待的時間越長，代碼庫的氣味就會越糟糕。我的建議將首先創建一個測試套件，您可以評估您的重構。這使得更容易看到你是否重構或者只是簡單地破壞東西:)。

來源

2010-06-11 07:06:22 Goblin

首先，從表單中獲取所有業務邏輯。其次，找到代碼與全局狀態交互的所有部分（例如訪問嵌入式系統）。委派所有這些訪問方法。然後，將這些方法移到一個新類中，並在該類的構造函數中創建一個實例。最後，inject爲該類使用的實例。

按照這些步驟，您可以將您的嵌入式系統邏輯（「現有模塊」）移動到您編寫的包裝類中，因此界面可以非常乾淨且更易於管理。那麼你可以更好地解決重構怪物方法的問題，因爲不需要擔心全局狀態（只有本地狀態）。

來源

2010-06-11 07:06:55 strager

如果代碼有效並且您可以將您的零件進行最小化更改，然後讓代碼保持原樣並進行整合。

如果代碼只是大屏障以添加新功能的方式，那麼最好是重構它。

與負責該項目的其他人交談，解釋情況，對重構代碼後獲得的好處進行估計，我確信（我希望）會做出最好的選擇。最好是談論你的想法，不要讓任何東西里面，尤其是如果這會影響你的工作效率，動機等

注：通常重寫代碼是不可能的，但根據情況和數量代碼需要重寫，決定可能會有所不同。

來源

2010-06-11 07:10:14 INS

你說這對系統的未來設計有影響。在這種情況下，我會說它已經壞了，需要修復。

但是您必須考慮業務需求。經常會遇到阻礙！

是否有可能將此代碼包裝到另一個類中，該類的接口更適合您希望如何使系統前進？（See adapter pattern）

這樣可以讓您在不影響設計的前提下滿足您的要求。
它給你一個界面，你明白你可以寫一些單元測試。這些測試可以基於您的設計從此代碼中需要的內容。它確保你對它所做的假設是正確的。如果你說這個代碼有效，那麼任何失敗的測試都可能是你的假設是錯誤的。

一旦您進行了這些測試，您就可以按照業務需求一次一個安全地重構，當您有一些空閒時間或需要時。

很多時候我發現真正理解一段代碼的最好方法是重構它。

編輯

在反思，因爲這是一個大的方法，多次調用到外面的世界，你將需要某種形式的反適配器類來包裝這個方法。如果您可以在方法中注入依賴關係（請參閱Dependency Inversion，以便該方法可以調用您的類中的方法，然後您可以將這些方法路由到原始調用）

來源

2010-06-11 08:50:41

妥協的設計和代碼質量與現有模塊集成

回答

相關問題