今天費了整整一天的時間，從早上8點多，忙多晚上8點多，忙活10多個小時，修改上傳了400多個檔案，卻沒有解決任何故障。不過我覺得今天的工作是非常值得的。
**大全裡面曾講到，**的22中壞味道，其中重複是萬惡之首。我的確是真體驗到了。一套**40多個專案，有四十多個分支。如果僅有幾個檔案有定製，那或許還算是比較愉快的事情。但是如果幾十個檔案有幾十個定製，這就是一件讓人生不如死的經歷了。然而非常不幸，這讓我體驗到了。
前些日子，乙個同事新增乙個新功能，修改了幾十個檔案，又非常不幸的傳到了定製分支。如果事情僅僅如此，也罷了，不幸的是，後面又有十幾個專案都要求合入這個功能，於是這幾十個檔案就被拷貝了幾十份。這一下子讓很有意義的編碼徹底變成了一場體力勞動，往往每修改乙個檔案，都要同事同步幾十次。雖然之前也有想法想徹底處理一下，但是一直沒有動手。
如果這是乙個結束也就罷了，可是就是這幾天七八個專案接踵而至，使岌岌可危的專案維護雪上加霜。為了避免事態進一步惡化，將一切掌於控制之中，使得自己和後來的同事能有乙個更好的開發維護環境。我下定決心把**整理一下。
第乙個階段，找出所有與這個功能有關的修改檔案，查詢整個專案下這個檔案的所有定製；把功能合到各個定製分支下面。編譯各個專案，並對重點專案進行波及分析和測試。
第二個階段，查詢各個分支定製，刪除與主分支相同的檔案定製；對於定製分支通用性介面和功能盡量合到主分支，減少維護**的工作量。
如此一來，很多情況下幾十份的工作量就減少到一兩份，而且避免了由於分支忽略導致的編譯錯誤和功能遺漏，可謂一勞永逸。
我們在是否重構之間猶豫，到底是應該勇於改變還是保持現狀，這是每乙個開發者到了開發中期必需面臨的問題。重構為了專案的可持續發展，不過也是存在風險的；保持現狀是為了專案穩定，不過越到後期專案也不可維護。既然是該做的事情，我們就要去做；也不一定要一蹴而就，可以循序漸進，每次只重構乙個功能或者乙個函式。當然，人非完人，重構建立在充分自測測試的基礎之上，完全有可能魚和熊掌兼得。長痛不如短痛，更重要的是要有乙個意識，每新加入乙個功能都考慮後續可維護性，加入後上傳之前多**走查。所謂早預防、早診斷、早發現、早**。
磨刀不誤砍柴工
這是一句廣為流傳的俗語，表面意思就是磨刀並不會耽誤砍柴的時間，在軟體開發過程中，似乎也有同樣的情況出現。有的時候，專案為了趕進度，需要快速實現，於是我們就馬不停蹄的加班加點的去寫 了，其他周邊的功夫能少耽誤就少耽誤，但是是不是除了寫 其他什麼事情都可以省呢，舉自己切身遇到的2個例子。案例一 在實現過...
磨刀不誤砍柴工
再次驗證了磨刀不誤砍柴工，這次高體大作業，花了我乙個多星期，結果呢，卻是還是有問題，回過頭來再看書上分析，又懂了一點。歸根結底，是沒有做好準備工作，總覺得應該盡快編 這樣才能早點結束。學了物件導向分析與設計，發現這個確實很有用，而且了解到，在軟體開發中，寫 只是其中很小的一部分，前面還有很多準備工作...
磨刀不誤砍柴工
我的部門裡面有erp顧問，也有你們經常說的網管。顧問負責erp管理軟體的維護與管理，網管負責硬體與網路的管理。我發現管理軟體的顧問經常是辦公室裡上網找資源學習，而網管們則 不斷，不是這個部門來 說，電腦無法啟動，就是列印不了，或者是中毒了什麼。為什麼有這個差異呢？我發現了這麼乙個問題，管理軟體的顧問...