你如何說服你的經理你的項目需要大量的重構？

我作爲承包商加入了一個鐵路項目。該項目已經進行了一年多。代碼由大約10個不同的開發人員編寫，其中大多數也是承包商。他們有不同的代碼風格。其中一些來自Java。該代碼與metric_fu有可怕的分數。許多功能非常長（100 - 300行）。一些函數具有瘋狂的邏輯分支，循環和遞歸量。每個請求都會生成大量的SQL查詢。性能非常糟糕。很多從未使用但從未得到清理機會的過時代碼。核心架構顯然是錯誤的或過度設計的。代碼覆蓋率僅爲25％左右。觀點和偏見是混亂和可怕的閱讀和理解。你如何說服你的經理你的項目需要大量的重構？

這位經理正試圖通過不斷添加新功能來滿足CEO的需求，但是新功能越來越難以正確實施而不會破壞其他功能。他知道代碼很糟糕，但不想花太多精力修復它們，因爲重構需要很長時間。

作爲承包商/開發人員，清除這種情況以及方便經理或首席執行官分配一些重構時間的好方法是什麼？

How to refactor on a budget

Dealing with illogical managers

來源

2009-08-26 Aaron Qian

在我有限的experiance：

這是不可能說服經理認爲有必要留出時間來重構。您可以讓他意識到這一點，並在每次因代碼錯誤而遇到問題時強化這一點。然後繼續前進。希望你的老闆能弄明白。
進入正在運行的項目並認爲「這是完全垃圾」是相當普遍的。給它一些時間。你可能會開始看到瘋狂的模式。

來源

2009-08-26 08:25:42 Alterlife

廣告。 2 - 當我參加一個項目時，每次都發生在我身上。 +1 – samuil 2009-08-26 08:32:12

也廣告2：它幾乎每次都發生在我恢復工作時，我自己的代碼的部分我沒有碰過一會兒;-) – jens 2009-08-26 09:44:10

除非你做了像激烈的身體傷害這樣的激烈和未經推薦的東西，這就是你會得到。你必須操縱這種情況來重構模塊並讓他們一點一點地說服他們，以使你有足夠的能力做出巨大的改變。 – 2010-01-16 15:49:52

我已經在類似的情況。基本上有隻有兩個選擇：

你得到一些放鬆的時間，你可能會被授予時間來重構東西
由於某些組件的惡意代碼的進一步發展涉及到一個攤位。你不能繼續添加任何東西，因爲每一個小小的變化都會導致其他一切停止運作。在這種緊急情況下，你將會得到一個「去」重構。

我剛纔已經回答了一些其他的問題，我的恐怖故事：

https://stackoverflow.com/questions/1333077/dirty-coding-tricks-to-deliver-project-on-time/1333095#1333095

我有一個項目，骯髒的把戲是發展的主要驅動原理工作。 Needlees說，一段時間後這些技巧已經開始相互衝突。在一個分析組件中，我們必須實現另一個非常髒的技巧 - 隱藏由於相互衝突的技巧由於計算不正確而計算出的值。之後，二級技巧開始發生衝突，我們不得不製造技巧來處理這些技巧。從那以後，即使提到這個組件，也讓我感到恐懼，我可能不得不重新開始工作。

這正是重構是唯一出路的第二種情況。一般來說，許多沒有技術背景的管理人員（實際上，來自壞程序員的人員）既不關心也不理解質量代碼和良好體系結構的價值。只有當某些事情打斷他們的計劃時，他們才能讓他們傾聽，比如「不可實施」功能的打擊，錯誤的增加和再次發生，客戶的請求不能滿足等等。只有這樣，對代碼問題的理解纔會第一次出現。通常，到那時爲時已晚。

來源

2009-08-26 08:23:46

我會帶應用的一個小塊和重構和優化它，直到它的光芒（和我做在我的私人時間，爲了不騷擾我的經理）。然後，您將能夠向您的經理/首席執行官展示重構和SQL優化的良好結果。

來源

2009-08-26 08:24:28

不，你不應該免費工作。 – erikkallen 2010-01-16 15:48:06

如果有需要重構，那麼代碼將爲自己說話。在開發過程中可以繼續進行較小的重構。如果你不能說服經理，那麼你可能應該重新思考它是否有必要。

但是，如果這是絕對必要的，那麼構建開發活動的指標和好處應該說服經理。

來源

2009-08-26 08:25:02

我認爲其中一個選擇是向經理強調如何對代碼庫進行重新分解以節省長期的時間（即金錢）。如果項目期望長期運行，那麼現在進行更改將明顯地爲您和其他開發人員節省時間。

最好用你的估計多長時間，如果你有更清晰的代碼從擺在首位的工作，將採取的工作特徵的一個例子。祝你好運！

來源

2009-08-26 08:28:57 tsdbrown

一個棘手的，我最近在這樣的公司工作......他們總是推動新的東西，他們又知道這是不好的，但我無論怎樣努力推動它 - 我甚至到了外部顧問驗證我的發現 - 他們認爲這是浪費時間。

最終，他們看到了曙光......只用了多個服務器崩潰，並在一個點上，幾乎整整8天無網站的說服他們。

即使在他們堅持認爲它一定是託管服務。

關鍵是要儘量量化他們的網站會持續多久，但仰臥起坐之前，並獲得一些外部驗證支持你 - 誰知道也不關心你的應用「他們」始終信任外人！此外，如果可以的話，嘗試制定一個計劃，以便在最壞的情況下逐步進行更換，並制定計劃要花費多長時間才能完成。另外還有一個計劃，如果有一兩個人正在進行完整的重寫，可能需要多長時間 - 但也要現實一些，否則會讓你陷入困境！如果你走這條路線（這就是我們所做的），只要你把它融入到新的網站中，你仍然可以在現有網站上做一些工作。

來源

2009-08-26 08:30:02 Brian

我會建議你把重點放在事情，他們可以看到自己，那就是，他們肯定會注意到該應用程序是在一些功能緩慢，所以拿起其中一個，這樣說：「我可以減少在這裏等待的時間，我可以花一些時間來改善這個具體的事情嗎？「（更好地說，但你得到了點：P）。

另外考慮到10個開發者在你沒有重構代碼庫之前，這可能意味着它是一個monstruos任務，可能會使情況變得更糟，在這種情況下，如果重構後出現問題，它將會是你的如果程序無法正常工作，則爲錯誤。只是一個雖然，但值得考慮。

來源

2009-08-26 08:30:19

我在同一位置的權利，但與該經理認爲，當新的功能，應該在現有的一些模塊來實現重新因子模塊太（如果它需要重新分解）的協議，我們現在正在用4-5年前創建的代碼掙扎，而且我發現重新分解別人的代碼不是微不足道的，也沒有趣，但對未來的重用非常有幫助。

來源

2009-08-26 08:40:39 IgorS

每個人都在這裏失去了一個觀點：

重構是軟件開發生命週期的一部分。

這不僅是一個回報率或任何具體項目，而是任何其他軟件開發項目。

如果不知爲何，你能說服你的PM why it is important to refactor增加任何新功能之前，現有的代碼庫，你就大功告成了。你應該清楚地告訴你的PM，沒有任何重構的任何進一步添加新功能將花費比所需更多的時間。即使添加了該功能，錯誤解決會話也會花費更多的時間，因爲代碼非常龐大且不可維護。

我真的不明白爲什麼人們忘記了以後優化的原則。以後優化還包括稍後重構恕我直言。

一兩件事，以設計決策的時候，你應該告訴後果，或好或壞，你的PM非常非常清楚。

您可以創建一個不同的分支（我假設你正在使用GIT）進行重構，並開始在其他一些分支添加新的功能。如果PM堅持與重構以及添加新的功能。

來源

2009-08-26 09:31:58 Waseem

糟糕的重構代碼是編碼的一部分，所以你不需要得到任何人的批准除非你的經理正在密切關注你的代碼和/或小時。今天我節省重構的時間是我不必爲了明天正常代碼工作而瘋狂操作的技巧（所以最終得以實現）。

猛擊了方法成更小的方法和刪除不使用的是你工作的一部分方法。在你調用的代碼中減少數據庫調用也是必要的，這樣你的代碼就不會被吸引。再次，不是真正的重構，只是正常的編碼。

說服你的經理取決於其他因素，包括（但不限於）他們願意被說服的能力和說服力。

無論如何，RoR中的大規模重構是什麼？即使「核心架構顯然是錯誤的」，它通常可以一次性理清一點。確保你把它分成塊/使用分支，這樣在你忙於修復時就不會破壞任何東西。

如果這是不可能的，那麼你回來的如何說服你的經理社會問題。這是一個簡單的問題，可以確定他/她的按鈕是什麼，並且推動他們而不會被解僱或被捕。羞辱，拒絕食物，給予獎品，成爲朋友，匿名綁架威脅，在你步入並挽救一天的過程中......這很簡單，真的：創造力是關鍵！

來源

2010-01-16 15:36:13

你如何說服你的經理你的項目需要大量的重構？

回答

相關問題