python图片裂缝_错误和裂缝

python图片裂缝

编译时和运行时恶棍。

考虑您当前使用的软件系统。 您会发布带有31,197个错误的系统吗？ 注意，没有潜在的错误； 实际发现的错误。

如果您回答“是”，则可以立即停止阅读。 这篇文章不适合你。

从软件的荒谬角度来看，我们可以将软件开发分为三个大框，其中两个是用户体验的实现和结构。

用户体验的实现是使软件执行用户所需的过程。 这关系到软件的运行时行为。

另一方面，结构包含了组成组件的系统并在组件之间建立关系的科学：方法，类，包，包等。此框完全与编译时有关：它专注于源代码，文本，关于文字关系。

程序员关心运行时行为和结构。

用户只关心运行时行为。 他们不在乎结构。 两种行为相同的版本中世界上可用的软件系统数量-一个结构不良，另一个结构良好-因此仅基于结构即可为用户提供选择：0。

这种兴趣上的差异产生了现代的软件开发领域，在该领域中，程序员对运行时错误“ Bug”有一个通用术语，因为用户在乎这些东西。 但是，对于结构性故障，不存在这样的术语。 这种遗漏已经浪费掉了，并且每年继续浪费着不计其数的数十亿美元和（非常清楚的）程序员小时的时间。

代码气味。

“ Bug”可能不是一个行为失误的好词，但是这个词很老，已经获得了引人注目的意思。 一个普遍的误解是，伟大的格蕾丝·霍珀（Grace Hopper）首先使用“臭虫”（Bug）一词来描述一种昆虫，该昆虫在1940年代通过原始计算机硬件的抢断继电器跳出来。 但是，早在使用计算机来表示各种工程问题的工程师中，使用该词已经很流行了。 在所有人中， 爱迪生创造了这个短语。

尽管如此，Hopper还是在软件工程师中推广了该术语，无论它的出处如何，当今世界上每个程序员都知道，当收到带有主题的电子邮件时，他们会感到非常恐惧，“我在您的程序中发现了一个错误。 再次！ FFS！”

当然，程序员也讨论结构性错误（通常在其他程序中），但是模糊地进行这样的讨论：“此代码看起来很乱，”“该代码具有过多的依赖关系”，“该其他代码很难更改。”

更糟糕的是，许多程序员将Fowler的短语“代码气味”与结构性错误联系在一起。 令人遗憾的是，这不是因为代码气味概念缺乏优点，而是因为代码气味与结构性缺陷不同。 尽管两种野兽都在编译时存在，但是将两者等同是错误的。

Fowler提供了一个定义：“代码气味是一种表面指示，通常对应于系统中的更深层问题。”

但是，结构性故障并不是表面问题的更深层指示：结构性故障是更深层次的问题。

程序员通常决定忍受代码的气味，因为代码的气味并不总是代表要解决的问题，只是“对应”问题，然后才“通常”。 程序员收到一封主题为“我在您的程序中发现代码气味”的电子邮件，这可能只是一个很好的论据工具。

结构性故障会自动发出错误以进行纠正，就像错误会自动发出错误以进行纠正一样。

进一步强调编译时和运行时竞技场之间的差异，请注意，在运行时竞技场中有错误，但没有“运行时气味”，也就是说，程序员没有确定运行时错误。住在一起。 （的确，管理层可能会拒绝提供更正，从而迫使他们忍受错误，但是程序员不会像编译时的代码气味那样做出此决定。）

裂纹。

因此，我们用一个词来形容应该阻止软件发行的结构性故障，就像错误会阻止软件发行那样。 幸运的是，现实世界中的砖石结构工程领域已经有了这样一个词：“裂缝”。

您不要购买锅盖破裂的锅。 您不会购买屏幕破裂的手机。 您不会购买车轴破裂的汽车。

在所有这些情况下，您仍然可以使用该物品–您可以使用该电话并驾驶该汽车–但是该漏洞立即告诉您，从结构上讲，出了点问题。

当然，即使在现实世界中，裂缝也会以不同的比例存在。 隧道电子显微镜将显示即使是最光滑的表面，也要用微裂纹进行擦洗，而留下的表面是否在某种程度上具有开裂的统计数据，但至少在客观上如此。 软件中也是如此。

对Apache的Lucene的最新评论使用四种类型的裂纹来表征其结构。

首先，Java系统同时使用了程序包和接口，因此大多数程序员都采用外观模式，以通过导出客户端使用其服务的接口来确保具有内聚功能的程序包与彼此的实现保持分离。 这样可以隔离测试软件包，并以最小的系统影响对其进行更新。 因此，任何超出两个包的方法依赖链都必须直接访问实现，而不是通过外观访问。 这是一个裂缝。

其次，Java系统利用访问修饰符，因此在未使用的范围内声明的任何元素都是破解。 仅使用包访问的公共类是破解的。 仅在类内访问的公共方法是一个裂缝。

第三，从统计上讲，是依赖长度。 通过系统运行的依赖关系越长，系统维护的成本就越高。 因此，长期的依赖关系就是裂缝。

最后，从统计角度来看，每种方法在系统中运行的依赖关系越多，系统维护成本就越高。 因此，高的方法依赖密度是裂缝。

一旦软件开发项目定义了这些漏洞的特征和阈值，就可以像对待错误一样残酷地禁止进一步的协商。 程序员很少会提出将错误引入产品的理由。 因此，程序员很少应该能够辩驳在产品中引入裂缝的情况（因为他们目前可以解决代码异味）。

但是，比使用这四种特定类型的裂纹更重要的是，一个软件开发项目严格定义了所有裂纹，并设置了源代码分析器以连续测量这些裂纹，并且由于裂纹过多而无法发布，该软件项目与竞争对手相比，它将在减少开发交付周期方面获得巨大优势。 由于与其他工程领域相比，当今的软件结构质量水平令人尴尬。

图1显示了四个不同系统的包装结构。 所有这些系统都是使用现代开发实践设计的，并且都经过了充分的测试。 但是，只有一个在构造过程中使用了自动裂缝检测。 您认为是哪个？ 您想维护哪个系统？

图1 – A： JUnit 。 B： Spoiklin Soice 。 C： FitNesse 。 D： Struts 。

显然，Lucene不会执行这种自动检测：仅第一类裂纹就有31,197条。 Lucene会考虑发布带有31,197个错误的产品吗？

摘要

这篇文章不是要寻找可能被认为是不可接受的新结构性断层，而是要重新评估所有结构性断层为不可接受的。

它只是不相信软件工程领域选择将结构性故障视为不如运行时故障重要。

那些意识到这一点的软件公司将获得丰厚的回报。

翻译自: https://www.javacodegeeks.com/2015/07/bugs-and-cracks.html

python图片裂缝