大家好,中常我是大重程序员幽鬼。
Martin Fowler 在他的构技书中[1]将重构定义为*“对软件的内部结构进行的更改,以使其更易于理解,中常并且在不更改其可观察到的大重行为的情况下更低廉地进行修改”*。本书包含大量重构技术,构技这些重构技术旨在在某些情况下应用,中常并旨在消除代码坏味道[2]。大重
重构是构技一个非常广泛的话题,我发现重构在软件开发过程中起着重要的中常作用。它们的大重相关性很高,因此它们是构技TDD[3]生命周期的重要组成部分。
由于它们的中常重要性,在这篇文章中,大重我想分享一下软件开发人员中使用最多的构技 4 种重构技术。但是在开始之前,因为可以自动应用重构技术(即某些 IDE 为你提供了帮助,通过应用重构工具,只需单击几下鼠标和进行选择,源码下载即可使你的生活更轻松),在这里,我将通过使用 Go 语言手动重构进行描述,并尝试将其作为参考指南。我们的开发团队意识到,在应用任何重构技术之前,应将可观察到的功能包含在单元测试中,并通过所有测试。
这是我常应用于代码的技术。它包括提取一段按意图分组的代码,并转移到新方法中。通过提取可以将一个长方法或函数拆分为一些小方法,这些小方法将逻辑组合在一起。通常,小方法或函数的名称可以更好地了解该逻辑是什么。
下面的示例显示了应用此重构技术之前和之后的情况。我的主要目标是通过将复杂度分为不同的功能,这样来抽象其复杂度。
func StringCalculator(exp string) int { if exp == "" { return 0 } var sum int for _, number := range strings.Split(exp, ",") { n, err := strconv.Atoi(number) if err != nil { return 0 } sum += n } return sum }重构为:
func StringCalculator(exp string) int { if exp == "" { return 0 } return sumAllNumberInExpression(exp) } func sumAllNumberInExpression(exp string) int { var sum int for _, number := range strings.Split(exp, ",") { sum += toInt(number) } return sum } func toInt(exp string) int { n, err := strconv.Atoi(exp) if err != nil { return 0 } return n }StringCalculator 函数更简单了,但是亿华云当添加了两个新的函数时,它会增加复杂性。这是一个我愿意做出慎重决定的牺牲,我将此作为参考而不是规则,从某种意义上说,了解应用重构技术的结果可以很好地判断是否应用重构技术。
有时,在使用提取方法后,我发现了另一个问题:此方法应该属于此结构或包吗?Move Method 是一种简单的技术,包括将方法从一个结构移动到另一个结构。我发现一个技巧,来确定某个方法是否应该属于该结构:弄清楚该方法是否访问了另一个结构依赖项的内部。看下面的例子:
type Book struct { ID int Title string } type Books []Book type User struct { ID int Name string Books Books } func (u User) Info() { fmt.Printf("ID:%d - Name:%s", u.ID, u.Name) fmt.Printf("Books:%d", len(u.Books)) fmt.Printf("Books titles: %s", u.BooksTitles()) } func (u User) BooksTitles() string { var titles []string for _, book := range u.Books { titles = append(titles, book.Title) } return strings.Join(titles, ",") }如你所见,User 的方法BooksTitles 使用了 books(具体是 Title)中的内部字段多于User,这表明该方法应归于Books。应用这种重构技术将该方法移动到Books类型上,然后由用户的Info方法调用。源码库
func (b Books) Titles() string { var titles []string for _, book := range b { titles = append(titles, book.Title) } return strings.Join(titles, ",") } func (u User) Info() { fmt.Printf("ID:%d - Name:%s", u.ID, u.Name) fmt.Printf("Books:%d", len(u.Books)) fmt.Printf("Books titles: %s", u.Books.Titles()) }应用此方法后,Books类型会更内聚,因为它是唯一拥有控制权和对它的字段和内部属性访问权的人。同样,这是在深思熟虑之前进行的思考过程,知道应用重构会带来什么结果。
你见过多少像下面方法一样,有很多参数的:
func (om *OrderManager) Filter(startDate, endDate time.Time, country, state, city, status string) (Orders, error) { ...即使我们看不到函数内部的代码,当我们看到大量这样的参数时,我们也可以考虑它执行的大量操作。
有时,我发现这些参数之间高度相关,并在以后定义它们的方法中一起使用。这为重构提供了一种使该场景更加面向对象的方式进行处理的方法,并且建议将这些参数分组为一个结构,替换方法签名以将该对象用作参数,并在方法内部使用该对象。
type OrderFilter struct { StartDate time.Time EndDate time.Time Country string State string City string Status string } func (om *OrderManager) Filter(of OrderFilter) (Orders, error) { // use of.StartDate, of.EndDate, of.Country, of.State, of.City, of.Status.看起来更干净,并且可以确定这些参数的身份,但是这将要求我更改调用此方法的所有引用,并且需要OrderFilter在传递给该方法之前创建一个新类型的对象作为参数。同样,在尝试进行此重构之前,我会尽力思考并考虑后果。当你的代码中的影响程度很低时,我认为此技术非常有效。
该技术包括用常数变量替换硬编码值以赋予其意图和意义。
func Add(input string) int { if input == "" { return 0 } if strings.Contains(input, ";") { n1 := toNumber(input[:strings.Index(input, ";")]) n2 := toNumber(input[strings.Index(input, ";")+1:]) return n1 + n2 } return toNumber(input) } func toNumber(input string) int { n, err := strconv.Atoi(input) if err != nil { return 0 } return n }其中 ; 字符是什么意思?如果答案对我来说不太明确,我可以创建一个临时变量,并使用硬编码字符设置该值,以赋予其意义。
func Add(input string) int { if input == "" { return 0 } numberSeparator := ";" if strings.Contains(input, numberSeparator) { n1 := toNumber(input[:strings.Index(input, numberSeparator)]) n2 := toNumber(input[strings.Index(input, numberSeparator)+1:]) return n1 + n2 } return toNumber(input) } func toNumber(input string) int { n, err := strconv.Atoi(input) if err != nil { return 0 } return n }感谢阅读,希望对你有所帮助。重构是一个非常广泛的话题,本文举例说明了重构中使用最多的四个。不要将此处提到的内容视为理所当然,自己尝试一下。此处描述的重构技术仅用作指导原则,而未作为规则遵循,意味着它们在需要时可以有针对性地进行调整。最后,我想说我们对所编写的所有代码和所使用的所有工具负责,我们的经验和知识可以指导我们掌握在每种情况下最适合的技能,我认为重构技术确实值得。
原文链接:https://wawand.co/blog/posts/four-most-refactoring-techniques-i-use/
参考资料
[1]书中: https://martinfowler.com/books/refactoring.html
[2]坏味道代码: https://en.wikipedia.org/wiki/Code_smell
[3]TDD: https://en.wikipedia.org/wiki/Test-driven_development#/media/File:TDD_Global_Lifecycle.png
本文转载自微信公众号「幽鬼」,可以通过以下二维码关注。转载本文请联系幽鬼公众号。