复杂而艰辛的重构之路--起步

简介: 你有没有试过,当你踏入一个新的公司,看到了几千几万几十万代码的时候,那种崩溃的感觉?代码多不可怕,怕的是代码的可读性、维护性、扩展性是如此之差,这时候该怎么办呢?当我进入了新的公司,利用了一个星期去熟悉代码,也知道了各个开发的编程习惯,在一个大公司里,没有一个规范的编程宝典,出来的就是这种大杂烩,但作为另一个开发的我,该怎么做呢?顺着他们的开发思路继续写这种代码?No,It’s Not My Style!该如何进行慢慢重构,等到一定阶段去跟领导说呢?1、把现在的hard code统统整理一下,这种小改动,相信任何一个LEADER都不会反对的吧。

你有没有试过,当你踏入一个新的公司,看到了几千几万几十万代码的时候,那种崩溃的感觉?

代码多不可怕,怕的是代码的可读性、维护性、扩展性是如此之差,这时候该怎么办呢?

当我进入了新的公司,利用了一个星期去熟悉代码,也知道了各个开发的编程习惯,在一个大公司里,没有一个规范的编程宝典,出来的就是这种大杂烩,但作为另一个开发的我,该怎么做呢?顺着他们的开发思路继续写这种代码?

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,方便你进行管理。

重构之路任重道远,暂时只能进行小改动,大的改动真心不太敢弄,牵涉的东西太多了,但我们如果尽力能做到以上几点,相信对以后的维护、扩展还是有帮助的。

相关文章
|
2月前
从零到一:技术创新的个人感悟###
【10月更文挑战第20天】 在技术探索的征途中,每一步跨越都如同在浩瀚宇宙中点亮一颗新星,既照亮了未知的边界,也映照出自我成长的轨迹。本文旨在分享一段从技术小白到创新实践者的心路历程,探讨技术背后的本质、内涵与意义,以及这一过程中对人生哲理的深刻理解。通过亲身经历,展现技术创新如何成为推动个人成长与实现自我价值的桥梁。 ###
42 5
|
7月前
|
存储 监控 Go
万字心路历程:从十年老架构决定重构开始
不论是从产品演进,还是从开发体验,原有iLogtail架构已经严重制约了其快速发展。因此,对iLogtail的架构进行升级已经迫在眉睫。
1163 10
|
7月前
|
设计模式 微服务
从代码到架构,我的技术成长之路
【2月更文挑战第5天】技术是一门不断进步的艺术,我在不断的实践中,通过学习和思考,逐渐领悟到了代码、架构等方面的知识和技能。在这个过程中,我发现技术并不仅仅是一种工具,更是一种思维方式和生活态度。本文将分享我的技术成长历程和所获得的思考。
57 2
|
机器人 网络安全 数据安全/隐私保护
谈谈数字化转型之路中的五大挑战及其解决办法
数字化转型不再是企业的选择,而是必不可少的。先进技术已经开始影响并改变了人们与企业沟通、协作和互动的方式。对于大多数首席执行官而言,这是在不断发展的业务环境中生存的问题。
谈谈数字化转型之路中的五大挑战及其解决办法
|
安全 测试技术
从零开始搞基建(3)——设计方案
  最近看了一篇文章,文章中提到在开发流程中包含一个设计方案的阶段,位于需求评审之后,用于描述自己对于该需求的实现思路、模块划分等相关考虑的点,可供今后自己或他人查阅。   目的就是在编码前理清思路,整体架构,查缺补漏,作为他人或自己的技术参考文档。   自己在项目开发的过程中,也曽有过这样类似的想法,但没有作者那样写的系统,也没有在团队中落地。   基于文章中的设计方案,自己做了点修改。设计方案包括4个部分:需求、调研、实现和复盘。
从零开始搞基建(3)——设计方案
|
存储 自然语言处理 Java
记一次优化经历杂谈
记一次优化经历杂谈
302 0
|
机器学习/深度学习 人工智能 算法
带你读《创新之巅: 未来十年重构商业的六大战略性技术》第一章未来十年重构商业的 六大技术1.3AI 如何工作
带你读《创新之巅: 未来十年重构商业的六大战略性技术》第一章未来十年重构商业的 六大技术1.3
带你读《创新之巅: 未来十年重构商业的六大战略性技术》第一章未来十年重构商业的 六大技术1.3AI 如何工作
|
传感器 人工智能 供应链
带你读《创新之巅: 未来十年重构商业的六大战略性技术》前言
带你读《创新之巅: 未来十年重构商业的六大战略性技术》
|
传感器 存储 人工智能
带你读《创新之巅: 未来十年重构商业的六大战略性技术》第一章未来十年重构商业的 六大技术1.AI 启用战略
《创新之巅: 未来十年重构商业的六大战略性技术》第一章未来十年重构商业的 六大技术1.AI 启用战略
带你读《创新之巅: 未来十年重构商业的六大战略性技术》致谢
《创新之巅: 未来十年重构商业的六大战略性技术》致谢
下一篇
DataWorks