重构 高效重构(三):构建高效工程环境

admin · December 31, 2020 · 53 hits

高效实施重构

当我们熟练掌握了重构技术后,还不能就此说自己在实践中已经可以安全而高效地实施重构了! 因为落到真正的工程实践环境,安全和高效的重构过程还需要好用的 IDE 工具,成熟的自动化测试套件,快速高效的开发构建环境,以及良好的编码习惯来支撑.
本节以 C/C++ 语言为例,总结了一些和高效重构相关的语法及工程实践方面的关注点,这些点同样可以供别的编程语言参考。

语言相关

不同编程语言的设计和发展历程不同,导致语法层面有些方面对重构非常友好,但也都有不利于开展重构的语法特性。例如C++,由于它语法相对复杂,导致业界对C++的自动化重构工具支持一直非常不理想,很多重构到目前为止只能手工进行。重构工具对编程语言的支持,其中一个重要的点在于对代码引用点分析查找的可靠性。 C++中有很多语法会干扰到这一分析,导致难以进行自动化重构.

C++中会让重构难以进行的语法包含以下:

  • 指针
  • 函数重载
  • 操作符重载
  • 默认参数
  • 类型强转
  • 隐式转换
  • 友元
  • 模板

还有一些不合理的编码规范,也会阻碍到重构的进行,例如

  • 匈牙利命名
  • 函数单一出口
  • 大而全的 common 头文件
  • ...

上述语法或者规范不仅会让自动化重构难以进行,也会干扰到手动重构. 对于不好的编码规范要及时摒弃! 对于会妨碍重构的语言元素要慎重使用,最好保持其影响在一定范围内,缩小重构时查找引用不确定性的范围.

当然 C++ 语言中也有一些语法非常有利于重构,例如:

  • const
  • 访问限制修饰符privateprotected
  • 匿名namespace
  • 局部变量延迟定义

这些语言元素有些会让代码语义更明确,有些会限制代码元素的可见度,缩小引用查找范围. 对于这些语言元素在开发中尽可能多的去使用,可以让重构变得更加容易.

最后,保持好的编码习惯,例如一开始就不要将文件\类\函数搞得过大,尽可能多的对外隐藏细节,对复杂语法的使用保持慎重态度,这样每次重构的成本都会小很多.

自动化测试

重构的安全性依赖于快速的自验证测试用例。基本每种编程语言都有对应的 xUnit 测试套件,可以对软件进行自动化测试用例的开发和执行.

针对 C++,可供选择的 xUnit 套件有GtestTestngppCppUnitCXXTest以及Boost Test等。目前最多人使用的应该是Gtest,由于使用广泛所以非常成熟,支持跨平台,方便简单容易上手,提供了丰富的断言机制和成熟的用例管理. 当然Gtest也有其问题,主要是测试注册机制不够优雅导致限制过多,测试用例运行期不能隔离导致互相影响,测试工程的组织不能模块化导致单元测试不能显示化物理依赖,无法低成本完成测试依赖文件的物理替换. 而TestngppGtest一样跨平台,断言丰富,用例管理成熟.。它最大的强大之处是支持沙盒模式,测试用例运行期间互相隔离,不会彼此影响. 另外,Testngpp支持模块化管理测试工程,支持方便的对测试依赖文件进行物理替换,这一特性对于没有虚接口情况下的 mock 非常实用. 但是由于Testngpp的强大,也导致了它某些情况下不如Gtest方便使用,受众相对小,文档也不全面。

在使用 xUnit 的同时再能结合一款合适的 Mock 框架,可以大大降低单元测试的成本。对于C++目前最好用 Mock 框架是Mockcpp。事实上 mock 技术在测试中经常容易被滥用,导致编写过多的面向行为的脆弱测试用例. 其实在测试中直接打桩进行状态验证成本并不高,所以现今我已经很少使用 mock 工具了。但是学会一款 mock 工具留着在适合的时候偶尔使用一下也是不错的.

关于 C/C++ 语言中如何做好自动化测试以及挑选合适的测试框架,可以参考这篇文章:"C/C++ 如何做好单元测试"

最后,我们都知道重构需要自动化测试的支持! 但是并不是没有自动化测试,重构就不能开展! 有些历史遗留代码,一开始很难加进去测试,必须要先着手修改,才能逐渐添加测试. 这时起步需要的就是对安全小步的重构手法的熟练掌握,以及利用原有手工测试进行安全保证. 当对软件进行修改从而可以添加自动化测试后,重构慢慢就上轨道了.

IDE

为了提高重构效率,我们需要一款智能的 IDE。它需要支持基本的自动化重构,能够高效准确的搜索到代码的引用点,支持良好的面向对象风格代码浏览,高效流畅地快捷键...

对于 Java 来说无论eclipse或者IntelliJ IDEA都相当不错,而对于类似 C/C++ 这样相对复杂的静态语言,或者动态脚本语言,都相对难找到一款高效好用的全面支持自动化重构的 IDE。

对于 C++ IDE,这里做以下对比和推荐:

  • Visual studio C++
    自身的重构工具并不完善,但是加上番茄小助手就很不错了.支持自动重命名,自动提取函数,重命名类还会自动把类的头文件和所有的#include点的文件名都做一修改.最大的缺点是不能跨平台,而且耗费机器资源较多。据说从 Visual studio 2015 以后已经内置了很多重构功能,不过本人没有试过.
  • clion
    Jetbrains 公司出品的跨平台 C/C++ IDE,号称要做最强大的 C++ IDE. 目前是收费的,免费的只能试用 30 天。工程构建只支持 CMake,另外只能在 64 位机器上使用。 Clion 内置的自动化重构菜单是最强大 (支持 rename,inline,extract,Pull member up/down ...)。本人试用过 1.0 版本,比较耗性能,当时用户也还不是特别多。
  • eclipse-cdt
    个人使用频率比较高的C++ IDE。 最大的好处是支持跨平台. 用 eclipse 在类的继承引用关系之间跳转非常流畅.。支持简单的重命名,提炼函数,提炼常量等自动化重构.。从 luna 版本开始支持重命名文件或者移动文件的时候会自动替换所有#include中的路径名. 个人目前最满意的 C++ IDE.

关于如何为 C/C++ 语言挑选好用的 IDE,具体可以参考"C++ IDE 口味谈""Effective Eclipse CDT"系列文章。

物理重构

物理设计往往容易被人们忽视,但其实它对软件的易理解性和可维护性也非常重要! 好的物理设计不仅可以减少物理依赖,还会有利于软件的构建和发布。所以程序员除了掌握一般的代码元素级别的重构,还需要熟悉常见的物理级别的重构,包括文件重命名,文件提炼,文件移动,或者目录结构调整等等。对于 C/C++ 语言,物理重构比较繁琐的地方在于经常需要同步修改 makefile 或者头文件的#include引用点。

以下以 C/C++ 举例,看看一些和物理重构相关的经验技巧 (make 相关的见下节):

  • 每个文件只包含一个类,并且文件名和类名相同. 这样方便重命名类的时候 IDE 自动对文件进行重命名.
  • 利用 IDE 提供的自动化重命名或者移动菜单进行文件/目录的重命名或者移动,以便 IDE 可以对涉及文件的所有#include引用点进行路径自动替换.
  • 使用 IDE 提供的自动化头文件添加功能来添加物理依赖,例如在 eclipse 中是ctrl+shift+n
  • 配置 IDE 的头文件模板,让自动生成头文件的 Include Guard 使用 Unique Identifier,避免每次头文件重命名后还得要修改 Include Guard(见下). (最新的 eclipse mars 版本中在 Windows -> Preferences -> C/C++ -> Code Style -> Name Style -> Code -> Include Guard 中选择 Unique Identifier,较老版本需要在 workspace 中修改配置文件,可以自行 google 修改办法).
    // Runtime.h
    #ifndef HDEA41619_5212_4A92_8A09_3989000E6BAE
    #define HDEA41619_5212_4A92_8A09_3989000E6BAE
    
    struct Runtime
    {
        void run();
    };
    
    #endif
    

编译构建

不好的编译构建工程不仅干扰到物理重构,更重要的可能导致编译效率底下从而让重构无法正常开展. 没人愿意在每次构建都要几十分钟到数小时的工程上进行频繁重构. 尤其是对于大型的 C/C++ 工程,需要对其编译构建过程进行持续地分析优化,不断提高版本的编译构建速度。

以下是一些针对 C/C++ 工程的编译构建实践经验:

  • makefile 中尽可能使用模式规则.自动搜索文件.不要显示使用源文件名,否则每次重命名文件后都得要修改 makefile.
  • makefile 中为预编译目标文件设置规则,不仅有利于解决一些宏展开的问题,更重要的可以快速解决一些头文件包含上的编译难题.
    # makefile example
    ...
    SRCS += $(abspath($(shell find $(SOURCE_HOME) -name "*.cpp")))
    OBJS = $(subst $(SOURCE_HOME),$(TARGET_HOME),$(SRCS:.cpp=.o))
    ...
    $(TARGET_HOME)%.i : $(SOURCE_HOME)%.cpp
        $(CXX) -E -o $@ -c $<
    $(TARGET_HOME)%.o : $(SOURCE_HOME)%.cpp
        $(CXX) -o $@ -c $<
    $(TARGET):$(OBJS)
        @$(generate-cmd)
    
  • makefile 采用自底向上组织,保证每个源代码文件单独可编译,每个模块单独可编译. 最终产品版本的构建调用每个模块的 makefile 生成编译中间产物后进行链接. 不要采用自顶向下传递 make 参数的 makefile 工程管理模式,否则每次编译任何一个文件或者模块都要全编译所有代码.
  • 尽可能使用并行编译. 在 Visual Studio 下可以使用 IncrediBuild 分布式编译工具. 对于 make 使用-j选项,并且可以使用 distcc 来进行分布式编译.另外可以使用 ccache 来做缓存加速编译。
  • 将测试工程的编译构建和真实产品版本的构建分离,测试工程的编译构建可以采用更好的工具:例如 cmake,rake 等.
  • 保证增量编译可用,并且是可靠的.

很多项目虽然有增量编译,但是都不够可靠,尤其是当有头文件删除的时候! 另外每次无论是否有依赖变化,makefile 都要重新生成加载.d 文件,效率也很低下. 所以大多数时候增量编译功能是关闭的!
《GNU Make 项目管理》一书中提供了很多大型工程中 make 组织的优秀实践,其中有一段对增量编译可靠高效的 makefile 片段,我将其提炼成了一段 make 函数,见下面,大家可以使用.

# make_depend.mak
# this file implement the makefile function for dependencies rules

# $(call make-depend,source_file,object-file,depend-file)
define make-depend
    mkdir -p $(dir $3);
    $(CC) $(CFLAGS) $(CPPFLAGS) -MM $(INCLUDE) $(TARGET_ARCH) $1 > $3.tmp1;
    $(SED) 's,\($(notdir $*)\)\.o[ :]*,$2 $3 : ,g' < $3.tmp1 > $3.tmp
    $(SED)  -e 's/#.*//'                                           \
    -e 's/^[^:]*: *//'                                             \
    -e 's/ *\\$$//'                                                \
    -e '/^$$/ d'                                                   \
    -e 's/$$/ :/' $3.tmp >> $3.tmp
    $(MV) $3.tmp $3
    $(RM) $3.tmp1
endef

# should use the make-depend as follow
# %.o: %.c
#   $(call make-depend,$<,$@,$(subst .o,.d,$@))
#   $(CC) -o $@ $<

后记

作为一名软件技术咨询师,过去些年指导过许多大型软件系统的重构工作。 这篇文章基本上是自己多年工作实践的一些心得,包括对如何高效实施重构的一些精炼和总结。

对于大型的软件重建,无论你的目标架构多么漂亮,最终还必须是一行一行的代码修改。如何安全可靠并且高效地修改代码,必然是落地的基本技能!

对于日常开发也是如此, 保持代码符合简单设计是一项日常行为,重构是达成它的唯一方式. 对重构的使用应该融入到代码开发的每时每刻,到最后不必强行区分是在开发还是重构,就像《重构》的序言中所说"变得像空气和水一样普通". 希望每个学习重构的同学都能体会到这种感觉!

千里之行,始于足下!


高效重构(一):正确理解重构
高效重构(二):掌握重构手法

「软件匠艺社区」旨在传播匠艺精神,通过分享好的「工作方式」,让帮助程序员更加快乐高效地编程!

No Reply at the moment.
You need to Sign in before reply, if you don't have an account, please Sign up first.