【合作】和【测试】

玩技站长 测试分享评论570字数 2456阅读8分11秒阅读模式

 有大量的书籍讨论编程语言和框架,但很少有资源讨论像“测试和合作”这样的话题。然而在大型工程中,这些话题能够轻易地使团队取得成功或失败。

从无数的实践经验中,我们认识到这些软技能非常地重要:很多时候项目出错的原因都是因为缺乏测试和合作。文章源自玩技e族-https://www.playezu.com/13371.html

【合作】和【测试】插图

所有的荣耀都属于团队文章源自玩技e族-https://www.playezu.com/13371.html

【合作】和【测试】插图1

【合作】和【测试】插图2文章源自玩技e族-https://www.playezu.com/13371.html

荣耀是团队所有,代码也是团队的。文章源自玩技e族-https://www.playezu.com/13371.html

【合作】和【测试】插图3文章源自玩技e族-https://www.playezu.com/13371.html

代码并不是任何一个开发人员的私有物。这也意味着你所写的任何代码都不属于你,而属于你所在的团队。用这样的方式来看待你所写的代码是非常有益的,有以下几点原因:文章源自玩技e族-https://www.playezu.com/13371.html

 1、不一定非要按照你的方式进行编码。文章源自玩技e族-https://www.playezu.com/13371.html

在了解代码始终属于团队后,理所当然地我们需要遵守一定的编码标准和规则。既然它不属于你,你不能肆意地按照你喜欢地方式去进行编写。你所写的代码是通用的代码库,所以必须遵守一些通用的规则。文章源自玩技e族-https://www.playezu.com/13371.html

这也能够让你在看同事的代码时更加宽容,你可能本能地想到你会以不同的方式完成他们的工作。 但是,请记住所有代码的编写需要遵守的是团队的方式而不是你自己的方式,这可以帮助你更加开放地理解其他解决方案和方法。文章源自玩技e族-https://www.playezu.com/13371.html

 2、一切都是你的问题。文章源自玩技e族-https://www.playezu.com/13371.html

当你在代码中发现问题时,是不是你的错误一点都不重要。因为项目的所有代码都属于团队,并且你是团队的一员,任何来源的有缺陷的代码都成为你的问题。如果团队中的每个人都秉持着“这不是我的问题”的态度,那么这个团队永远也不会开发出优秀的产品。

【合作】和【测试】插图4

分享关于代码审查的知识

【合作】和【测试】插图5

代码审查有助于提升团队的代码质量。

首先,多个人在相同的代码上进行检查,能够提供更多更好的解决方案,将有机会产出更高质量的代码。

其次,代码审查有助于团队的人对所有代码进行了解。例如,当只有一名开发人员指导某段代码时,就会存在一定的风险。每当这位开发人员休假、生病甚至离开公司时,团队都将遇到麻烦。

此外,代码审查有助于促进团队内部的知识交流,提升团队的整体开发水平,因为初级开发人员可以从交流中向高级开发人员学习。高级开发人员也应该意识到在指导初级开发人员时他们也能够学习到新的事物。

【合作】和【测试】插图6

并不是所有的都需要改善

【合作】和【测试】插图7

    【合作】和【测试】插图8

你可以认为程序中的所有一切都可以改进,但重点不是什么可以改进而是什么值得改进。我们知道自己的产品存在弱点,如果时间是无限的,我们可能会改进每一点。但随着时间成为任何团队的稀缺资源,我们不得不设定优先级。

【合作】和【测试】插图9

能够负责任地思考是否真的去改善某件事情是一门艺术,这需要多年的经验,而且最好的情况是,经过有意识的培训。

【合作】和【测试】插图10

进行提问

【合作】和【测试】插图11

 

当你在阅读其他人的代码时,很容易在头脑中假设自己会做得更好。在第一次阅读时,你可能认为这行或那行代码似乎不需要如此复杂,甚至是多余的。你也许是对的,但很难说,因为你实际上并没有编写代码。

根据经验,我们知道即使是最简单的问题也可能包含令人惊讶且无限的复杂性。 只有在实际解决问题的时候(考虑可能的解决方案,副作用等)才能充分地理解它。

【合作】和【测试】插图12

因此,当遇到一段让你怀疑的代码时,假设大量隐藏的复杂性是一个很好的基本规则。从这个角度来看,你可以深入了解代码并尝试理解它以及潜在的问题。

【合作】和【测试】插图13

【合作】和【测试】插图14

只有经过测试的软件才完整

【合作】和【测试】插图15

         【合作】和【测试】插图16单元测试有时被认为是锦上添花。然而,我们的确需要在开发过程中进行单元测试。在较小的项目中,可能不用编写单元测试。然而,在任何甚至只有少量复杂性的项目中,你都应该进行单元测试。很多工程,起初看似非常简单,但后面将发展的越来越复杂。

单元测试对我们至关重要的确有许多原因:

1、测试使我们能够安全并快速地完成大的代码改变。

在每一个大型的项目中,你不得不在一些时候完成一些重构。但是在重构的过程中,如果没有一定数量的单元测试将会带来非常糟糕的体验:在修复一些问题的时候常常不可避免地会破坏另一些地方的代码,如果拥有足够多的单元测试那么你就能够容易地知道哪里出现了问题。

 

2、我们可以很自信地向外部发布项目

如果你的应用需要提供给付费用户使用,如果你没有足够多的单元测试,那么在每次将代码提供给用户使用时你总是会充满担心。

 

 3、测试使我们可以获得更优秀的代码。

进行良好的测试是最终获得优秀项目代码的最好的前置条件,因为测试能够帮助你更好地理解你所解决的问题,并帮助你创造简单的、模块化的代码。

 

4、测试能帮助我们及时更新文献。

在一个理想的世界中,应用中的每一个部分都应该记录在文档中。我们希望拥有一份简洁、格式漂亮、易于阅读的文档,并且最为重要的是当我们每次更改代码的时候我们都希望文档能够及时的更新,当然这是非常理想化的。

对于大型项目来说,对重要部分代码进行充分的测试是非常重要的。它使我们在发布应用程序的时候能够非常自信,并且我们总是能够安全、快速地对代码进行更改。

【合作】和【测试】插图17

测试能够加快开发的速度

【合作】和【测试】插图18

 

起初,你可能会认为测试驱动的开发似乎非常消耗时间,会降低开发进程,并且编写单元测试需要花费一定的时间。但是随着时间的推进,你会发现编写单元测试能够加快你的开发!

【合作】和【测试】插图19

你可能会花费更少的时间来编写实现代码,因为在你写单元测试的时候你应经完成了大量的工作。

另一个好处是:当代码需要发生改变时能够降低破坏现有代码的可能性。你将能够节省无数原本会花在查找和修复bug的时间,然后你就能够用这些时间做更多有用的事情。

【合作】和【测试】插图20

通过测试修复问题

【合作】和【测试】插图21
 

修复bug和编写测试应该是密不可分,当然可以仅跟踪bug并简单地修复代码。然而,如果对“回归”这个词很熟悉的话:已经修复的bug会再次出现在你面前。如果你想要确保bug的确被修复了,那最好的办法就是编写测试代码来确保。

【合作】和【测试】插图22

测试低层次的组件

【合作】和【测试】插图23

 

当开发一个每天都有超过100,000人使用的软件产品时,我们总能够从中学到很多经验教训。一方面,我们明白错误是无法避免的,尤其是像Tower这样的产品,需要处理复杂的系统初始化过程,你不能够控制所有的事情。但另一方面,我们知道哪里发生的错误最多。

【合作】和【测试】插图24

有效测试

【合作】和【测试】插图25

           【合作】和【测试】插图26

通常,尽可能使单元测试覆盖你的代码是非常可取的做法。然而,当你听到一个软件开发人员吹嘘他的“100%测试覆盖率”,你应该小心。听起来我们似乎应该测试程序的每一行代码,但是实际上并不是这样。

关键的标准是——测试能给你带来价值吗?

通常,如果只是测试很简单的逻辑,那么测试所能够提供的价值就非常小。在这些情况下,测试所带来的价值就远小于维护它所花费的精力。

 

【合作】和【测试】插图27

仅测试,不要运行!

【合作】和【测试】插图28

 

在你的应用程序中手动地进行测试需要花费大量的时间:你必须启动应用,跳转到特定的页面,然后执行相应的操作来进行测试。然而编写单元测试只在最初的时候需要花费一些时间,之后的多次测试将会非常容易。

 

仅运行单元测试将比启动整个应用进行手工测试要快的多。除了速度快之外,测试也能够提供高质量和稳定的测试结果,在大多数情况下,前期所投入的时间是完全值得的。

 图文来源网络,如有侵权联系删除

 

 

 最后更新:2022-7-25
匿名

发表评论

匿名网友
确定

拖动滑块以完成验证