为什么要进行单元测试?怎么进行测试?

本文阅读 10 分钟
首页 技术分享,GO 正文

软件
软件是可以改变的。这就是为什么它被称为「软」件,它的可塑性是比硬件强的。一个优秀的工程师团队应该是一个公司一笔惊人的财富,他们编写可以随着业务发展而不断增值的系统。

那么,为什么我们在这方面做的如此糟糕呢?你听说过多少完全失败的项目?或者成为「遗产」,必须完全重写 (重写通常也会失败! )

软件系统是如何“失败”的呢?难道不能在它正确之前进行修改吗?这就是我们的承诺!

很多人选择用 Go 来构建系统,因为它已经做出了许多选择,人们希望这些选择能让它更经得起遗产的考验。【相关推荐:Go视频教程
和我之前 Scala 生涯相比 我形容它简直会让你有上吊的冲动,Go 只有25个关键词和 很多 可以从标准库和一些其他小型库中构建的系统。 愿景是通过 Go 你可以编写代码并在6个月内回顾它,它仍然有意义。

1.与大多数替代品相比,测试,基准测试,语义解析和装载方面的工具是一流的。

2.很棒的标准库。

3.严谨的反馈回路让编译非常迅速

4.Go 有向后兼容性承诺。看起来 Go 将来会获得泛型和其他功能,但设计师们已经承诺,即使你 5 年前写的 Go 代码仍然会构建。我花了几周的时间将项目从Scala 2.8 升级到 2.10。

即使拥有所有这些优秀的属性,我们仍然可能会制造出糟糕的系统,因此我们应不论你使用的语言优秀与否,你都应该回顾过去的软件工程并理解其中获得的经验教训。

1974年,一位名叫 曼尼·雷曼 的聪明的软件工程师写下了 雷曼软件进化定律。

这些定律描述了推动新发展的力量和阻碍进步的力量之间的平衡。

如果我们不希望开发的系统变成遗产,被一遍又一遍的重写,那么这些力量是我们需要着重理解的。

连续变化规律

实际生活中被使用的软件系统都必须不断的改变,要不然就会被大环境淘汰

很明显,一个系统 必须 不断的改变,要不然就会变的越来越没用,但是这种情况为什么经常被忽略呢?

因为很多开发团队在指定的日期交付一个项目会得到奖金,然后他们会继续开发下一个项目。如果这个软件是「幸运的」,至少它会以某种形式移交给另一组人来维护它,但是他们一定不会继续迭代它。

人们通常关心的是选择一个框架来帮助他们「快速交付」,而不是关注系统持久性发展。

即使你是一名出色的软件工程师,你仍然会因为不了解自己系统的未来需求而成为受害者。随着业务的变化,你写的出色的代码也会变得不再适用。

雷曼在70年代很成功,因为他给了我们另一条值得深思的规律。

复杂性增加的规律

随着系统的发展,除非采取措施减少系统复杂性的增加,否则系统的复杂程度会持续增加

他现在要所说的就是:我们不能让软件团队成为纯粹的功能工厂,只是通过将越来越多的功能集中到软件上, 来让系统能够继续长期运行。

随着我们知识领域的变化,我们 必须 持续管理系统的复杂性。

重构
软件的开发可以在 许多 方面保持软件的可塑性,例如:

开发人员授权

通常「好」的代码。关注代码合理的分离,等等

沟通能力

体系结构

可观性

可部署性

自动化测试

闭环

我将重点放在重构上。在开发人员编程的第一天经常听到的话就是「我们需要重构它」。

这句话从和而来?重构与编写代码有什么不同?

我知道我和其他很多人都 认为 我们在进行重构,但我们错了。
马丁·福勒描述了人们是如何犯错的

然而「重构」经常被用在不合适的地方。如果有人讨论一个系统在重构时出现了几天故障,你可以肯定他们不是在重构。

那是什么呢?
因式分解
在学校学习数学时,你可能学了因式分解。这里有一个非常简单的例子

计算 1/2 + 1/4

为此,将分母 分解,将表达式转换为

2/4 + 1/4 你可以把它变成 3/4.

我们可以从中吸取一些重要的教训。当我们 分解表达式 时,我们没有改变表达式的含义。两者都等于 3/4,但我们通过将 1/2 变为 2/4 后,我们的工作变得更容易了;它更适合我们的「领域」。

当你重构代码时,你应该在「符合」你当前系统需求的情况下,尝试找到一个方法来使你的代码更容易理解。关键是你不应该改变代码原有的行为.

Go 的一个例子
下面这个方法是用特定的 language 问候 name

 func Hello(name, language string) string {
    if language == "es" {
        return "Hola, " + name
    }
    if language == "fr" {
        return "Bonjour, " + name 
    }
    // 想象一下更多的语言
    return "Hello, " + name
}

如果有几十个 if 语句会让人感觉不舒服,而且我们还要重复的使用特定的 language 去伴随着 , 问候 name。因此,我们来重构代码。

func Hello(name, language string) string {
      return fmt.Sprintf(
          "%s, %s",
          greeting(language),
          name,
      )
}

var greetings = map[string]string {
  es: "Hola",
  fr: "Bonjour",
  //等等...
}

func greeting(language string) string {
  greeting, exists := greetings[language] 
  if exists {
     return greeting
  }
  return "Hello"
}

实际上,这个重构的本质并不重要,重要的是我们没有改变代码的行为。

当重构时,你可以做任何你喜欢的事情,添加接口,新类型,函数,方法等等。唯一的规则是你不能改变代码的行为。

重构代码时不要改变功能
这非常重要。如果你重构时改变功能,你相当于同时在做 两 件事。作为软件工程师,我们应该学习把系统分成不同的文件/包/功能/等等,因为我们知道试图理解一大块东西是困难的。

我们不要一次想很多事情,因为那会使我们犯错误。我目睹了许多重构工作的失败,因为开发人员贪多嚼不烂。

当我在数学课上用笔和纸做因式分解时,我必须手动检查我是否改变了头脑中表达式的意思。当我们重构代码时,尤其是在一个重要的系统上,我们如何知道我们是否改变了功能?

那些选择不编写测试的人通常依赖于手动测试。除非是一个小项目,要不然这将是一个巨大的时间消耗,并且从长远来看不利于系统将来的扩展。

.为了安全地重构,您需要单元测试因为它提供了

.可以在不担心功能改变的情况下重构代码

.有助于开发人员编写关于系统应该如何运行的文档

.比手工测试更快更可靠的反馈

1 本网站名称:规海-上至
2 本文章出自:https://www.php.cn/be/go/496429.html
3 本网站的文章部分内容可能来源于网络,仅供大家学习与参考,如有侵权,请联系站长85762836进行删除处理。
4 本站一切资源不代表本站立场,并不代表本站赞同其观点和对其真实性负责。
5 本站一律禁止以任何方式发布或转载任何违法的相关信息,访客发现请向站长举报
6 本站资源大多存储在云盘,如发现链接失效,请联系我们我们会第一时间更新。
-- 展开阅读全文 --
php经典趣味算法
« 上一篇 10-10
日落云任务助手V1.5
下一篇 » 10-18

发表评论

发表评论