最近公司領導層腦袋發熱要轉java，干掉.net，所以碰到一個系統新的需求過來都要評估一下是重構還是原有的基礎上修改
基于以上背景也就誕生了這篇文章：到底重構還是優化
我的建議是：工時決定一切
老系統重構會遇到2個問題：
1.業務的重新梳理
2.代碼邏輯的梳理
業務的重新梳理：不用分析，大家做個系統的都明白，5年甚至10年的老系統業務梳理簡直就是sheet，如果一個開發不想接這個系統，他一定會建議你去梳理業務（不用說，我就是那樣的:-)）
為什么，因為要把業務梳理清楚至少要個10天半個月的，這段時間開發只要睡睡覺就能拿工資了，產品經理忙活了大半天沒有沉淀檔案，5年后又得重新來過，而且業務梳理是跨部門溝通，浪費的是兩個部門的人的時間，算人天的話這成本可想而知，
代碼邏輯的梳理：不管是重構一套還是優化，都要梳理代碼邏輯，因為系統雖然重新開發的，但是老資料不能丟啊，不能升級下系統以前的資料就沒了吧
重構的成本很高，那優化的成本就會很低嗎？
這個要看情況，大部分情況一個優秀的程式員寫的系統，優化的成本是很低的，注意，這里有個前提：優秀的程式員，我曾經碰到過企業的OA系統，里面的代碼真的是sheet，方法名中英文混雜，不判斷null，一個方法n個版本，fun1(),fun2(),funNew(),一個方法20多個引數，類A的方法調類B的方法，類B的執行又調類A的方法，問題是這樣的代碼難看點沒有bug也就算了，問題是天天客戶要找你為何頁面按鈕點不了了，為何導不了資料了，為何資料重復了，，，，維護這類系統讓人懷疑人生，有個開發就是因為接了這個專案離職了，，，無奈作為tl只能自己上，沒有人啊，公司不招.net，我能咋辦，難道我也離職，沒人要哇，，，對于這個系統，我就建議重構，因為維護的成本已經占用了一個
開發40%以上的工時，扯遠了，優化的成本一般不高，只要一個系統平時的維護占用開發的工時不超過10%，也就是一周五天作業日不超過4個小時，我都建議優化，
當然，今天的案例有點例外，系統的代碼也很亂，也沒法看，上面的幾個壞代碼的要素也占了80%，頁面按鈕不能用，資料無法匯出，反映慢，資料結構不合理，還有資料沒有維護的頁面，直接在mssql里硬編碼進去的，原諒我又要罵人了@#￥@#￥#@￥%，這個系統用戶都不使用了，所有本應用戶自己能完成的事情都推給了開發，拉資料，維護資料等，沒辦法作為tl，在沒有新人的情況，只能自己攬活了，系統不能用我給你重新整下吧，只要系統能用，開發也不用做非開發的活了，
攬活了，好評估下到底新開發還是優化呢，看了一下代碼，雖然臟代碼很多，但是主要問題只有3個：
1.組織架構是手動，不與ps系統同步，這個好解決，都不需要改程式，直接寫個外掛（Python讀取部門資料，對比系統的組織架構資料，同步缺的部門，更新重復部門的相關屬性）
2.資料庫鏈接超時是因為資料庫處理該陳述句花費太長的時間導致超過了過期時間，默認是30秒
看了下代碼造成該問題的是一個存盤程序，在存盤程序中拼接sql查詢字符竄，搜索的條件欄位沒有加索引，表中的資料有5萬條，然后又有很多表連接，這個問題也好解決
3.最后一個問題是手動維護的一個字典資料，理了下完全可以通程序式自動生成，只要不重復就行
4.用戶新增的批量審批的需求，簡單，只需要加個介面和sql
基于以上3點，果斷選擇優化，評估下最壞的情況大概10個作業日，其中包括5個開發日，3個測驗日，1個寫博客的日子，1個緩沖的日子，哈哈，如果選擇開發新系統產品保守估計10個作業日100%投入，開發重頭嚕代碼最少要30個作業日，而且還要兼容老系統，從這個角度講一個給力的開發可以節省的作業量是不可估量的，各位老板，給好的開發漲漲薪帶回來的回報也是不可估量的，不要因為跑了一個開發，新的開發來了重構一個系統，那就呵呵了
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/225259.html
標籤：其他
上一篇：自動化管理之禪-新人培養