[阅读] 管理、修改、重构遗留程式码的技术

章节连结

进入软件相关行业,接手他人的程式码一起协作是工程师日常。若团队的程式码不易修改、或是不容易了解其运作逻辑,那么就算你现在拼了命的想要逃跑,日后也会花费更多时间和心力来处理。这本书算是集合作者的长期开发经验和心血,来带领诸多新鲜人少走点冤枉路。
working-effectively-with-legacy-code


书籍资料

书籍名称:管理、修改、重构遗留程式码的技术
原文名称:Working Effectively with Legacy Code
作者:Robert C.Martin Series
ISBN:9789864344000
博客来推荐连结:https://tinyurl.com/yce47h82

1. 第一印象的主观想法

转职后开始进入正式的开发环境中打滚,面对成千上百行、复杂程度也加倍的程式码,往往就迷失于其中。若想要快快完成功能,程式码的品质却又经不起考验。到头来,借由这本书导正了自己在开发上的心态缺陷。若是求快和逃避改动,最后到头来要花费的时间可能更多。在评估自己的工作负担上,测试和反复调教的时间是要估算进去的。

2. 认同之处和分段笔记

这本书个人认为随着自身的经验累积, 会有一些新的观点产出以及理解原先不明白的地方。因此,下面只记载部分段落。

Chapter 1 – 修改软件

起因:添加新特性、修正 Bug、改善设计架构、最佳化资源运用(效能提升)
  • 使用者在意的是行为,在添加新行为的时候,尽量不改动他们早已习惯的模式,或是多了 Bug
  • 若你对程式码进行重构 (Refactoring),要对每一步环节进行测试并验证其正确性
  • 保留既有行为不变,是最具有挑战的工作
  • 问题总是无法避免,所以别等它长大后,才能动手解决
添加特性
修正 Bug
重构
最佳化
结构
改变
改变
改变
新功能
改变
原有功能
改变
资源使用
改变

Chapter 2 – 带着回馈工作

单元测试可以独力的针对某一段程式码进行测试,帮助了解问题
依赖性(Dependency)是软件开发中最为关键的问题,遗留程式码就是要解决过多的依赖性
确定变动、找出测试点、解依赖、编写测试和重构

Chapter 4 – 接缝模型

为既有程式码编写测试,都会发现非常的困难,这是很正常的。
透过 seam 来解除依赖性,这边的细节直接看书会比较快,毕竟有太多的程式码范例。

Chapter 13 – 修改时应该怎样写测试

特征测试,描述系统的实际行为 – 先写一个你知道会出错的断言,然后修改到可以通过。用这样的方式来了解函式的运作。

Chapter 15 – 到处都是 API 呼叫

如果你发现那些 API 多半不是我们能够控制的话,那就很难去做改善了。当然,你也可以将其依照职责拆分出各个不同的逻辑区块,并替这些区块编写测试、重新命名、外覆类别 (Wrapper Class)等。

Chapter 16 – 对程式码的理解不足

写下草图,力求理解方法结构和职责分离,并删除不会用到的程式码

Chapter 22 – 要修改一个巨型方法,却没办法编写测试

  • 进行少部分的提取,并加以语意化,力求达成一个函式仅做一件事
  • 将同类的方法放到一块,并逐条进行测试
  • 只提取你所了解的部份,可以从传入和输出的变量总和越小的着手

Chapter 23 – 降低修改的风险

程式设计是同一时间只做一件事的艺术,可以用同侪来协助
多一双眼睛来看总是好的

3. 总结

本篇主要是以 Java 程式码做示范,对于初学为 JavaScript 的我来说,在理解上会有点困难度。不过借由书中所提到的不少精采范例,可以让自己在编写程式的时候,尽量减少依赖程度和语意化程式码。
按赞加入粉丝团

延伸阅读