<input id="ohw05"></input>
  • <table id="ohw05"><menu id="ohw05"></menu></table>
  • <var id="ohw05"></var>
  • <code id="ohw05"><cite id="ohw05"></cite></code>
    <label id="ohw05"></label>
    <var id="ohw05"></var>
  • 復雜而艱辛的重構之路--起步

    你有沒有試過,當你踏入一個新的公司,看到了幾千幾萬幾十萬代碼的時候,那種崩潰的感覺?

    代碼多不可怕,怕的是代碼的可讀性、維護性、擴展性是如此之差,這時候該怎么辦呢?

    當我進入了新的公司,利用了一個星期去熟悉代碼,也知道了各個開發的編程習慣,在一個大公司里,沒有一個規范的編程寶典,出來的就是這種大雜燴,但作為另一個開發的我,該怎么做呢?順著他們的開發思路繼續寫這種代碼?

    No,It’s Not My Style!

    該如何進行慢慢重構,等到一定階段去跟領導說呢?

    1、把現在的hard code統統整理一下,這種小改動,相信任何一個LEADER都不會反對的吧。

    針對不同的hardcode要有不同的解決方案,如果hard code僅對本類的話,請在本類中使用private const,如果跨越多個類的,請不要怕麻煩,添加一個類,把這些都設置進去,當然,盡量把這些硬編碼的使用歸類。

    public class Example
    {
        public void ExampleMethod()
        {
            //var name = "jamesying"; old class
    
            //private string
            var name = MyName;
    
            //public string
            var pname = PublicString.MyName;
        }
    
        //if jamesying only in this class you can
        private const string MyName = "jamesying";
    }
    
    //if jamesying is a public string
    public class PublicString
    {
        public const string MyName = "jamesying";
    }
    

    2、超過50行的方法,進行小重構。超過50行就另外建個方法,相信這個也不會反對吧。

    public class Example
    {
        public void ExampleMethod()
        {
            if (....)
            {
                //old more than 50 lines
                //do....
                DoMethod();
            }
        }
        
        public void DoMethod()
        {
            do.....
        }
    }
    

    3、盡量不改變原來方法的結構,參數、命名盡量不改動,除非很有爭議性。

    原有的一些方法分布的不是很合理,比如View層做了邏輯操作,Controller做了數據操作等,遇到這種就重新建一個項目或者建一個類,按照更合理的方式來進行,保持原有方法不改動,只是通過它再去call一下自己的方法。如果遇到一些重復操作,這樣有便于以后的維護。

    public class ViewExample
    {
        public void ExampleMethod(string id, string name, string age)
        {
            //old Do Anything and than for more lines
            //new
            var business = new BusinessClass();
            business.DoExampleMethod(id, name, age);
        }
        
    }
    
    public class BusinessClass
    {
        public void DoExampleMethod(string id, string name, string age)
        {
            //old Do anything
        }
    }
    

    第三步你是不是覺得多余呢?如果這么覺得,那是你還沒有經歷過恐怖的項目而已,而且你這種提煉,為以后的維護、改版、更新都會有幫助,這里要注意一點,千萬別直接去掉原先的方法參數,因為你不知道有多少地方調用了它,等你的提煉穩定了,試著去改變原先的方法或者去除。

    以上只是代碼的小改動,相信不難,如果要重新構建一個完全新的系統,這事情還是要多多考慮的,肯定不能一蹴而就的,等完成了上面三步,相信你的領導已經對你刮目相看了,接下來的事情就好辦了。

    4、統一wcf、webservices、webapi等接口,盡量使用統一方式,方便調用。

    如果調用的時候用的是自動更新方式,那就統統使用這種方式,如果是手動編寫的,千萬別放在一個類里(博主已經崩潰中)

    剛接觸項目的時候,我一直覺得他們是直接引用,然后手動右鍵獲取更新,誰知道他們是把增量代碼手動復制到Reference.cs中,著實讓我吃驚不少,what a fuck day!

    遇到這個問題,我真心沒法修改,動一動把命送,因為merge的都是外國人,英語也不好,只能先暫時跟著他們的思路走,等英語好了再說吧。

    5、把項目中的緩存用統一的方式。

    編寫一個ICache接口,項目中所有使用到緩存的地方都修改掉,為了避免有多個緩存方式,可以寫一個CacheFactory或者CacheStrategy,這樣方便你在內存方式還是其他方式緩存進行切換。

    這個是一個非常有必要的做法,不管你是重構、新建,都一定要注意這點,否則后期你維護或者更換的話會讓你痛不欲生。

    public interface ICacheExample
    {
        void Add(string cacheKey, object obj, TimeSpan expiredTime);
    
        void Save(string cacheKey, object obj, TimeSpan expiredTime);
    
        T Get<T>(string cacheKey);
    
        T Retrieval<T>(string cacheKey, Func<T> func, TimeSpan expiredTime);
    
        bool Delete(string cacheKey);
    
        Dictionary<string, object> CacheManagerDict { get; }
    }
    

    Add,Save,Delete對應原先的Cache方法,這個大家應該都知道,Retrieval是一個檢索方法,如果緩存中沒有這個cache,那將執行func委托,得到的結果緩存起來并返回。CacheManagerDict是對緩存的一個管理,有些時候我們需要手動清除某一個緩存,如果你用的HttpCache,那可以不使用這個屬性,但如果你是其他方式緩存,或者是分布式的話,建議加一個管理dict,方便你進行管理。

    重構之路任重道遠,暫時只能進行小改動,大的改動真心不太敢弄,牽涉的東西太多了,但我們如果盡力能做到以上幾點,相信對以后的維護、擴展還是有幫助的。

    posted @ 2017-04-10 09:30  James.Ying  閱讀(4891)  評論(42編輯  收藏  舉報
    国产美女a做受大片观看