软件需求分析的任务_软件任务

软件需求分析的任务

Internal deficiencies of quality and technical debt

质量和技术债务的内部缺陷

When we use the term Cruft in Software development, we are referring to redundant, defective, useless, and poorly written code. Another way to define the term Cruft is “things” that were left temporarily in the system during the previous iteration. Also, Cruft refers to any code that is not necessary to perform the task it was designed for or forgotten code without any utility.

在软件开发中使用术语Cruft时，是指冗余，有缺陷，无用且编写不良的代码。 定义术语Cruft的另一种方法是在上一次迭代过程中暂时留在系统中的“事物”。 同样，Cruft指的是执行其设计任务所必需的任何代码，或者是没有任何实用程序而被遗忘的代码。

Although Cruft does not mean a code bug, it makes the code harder to maintain or to read and creates technical debt.

尽管Cruft并不意味着代码错误，但它使代码更难以维护或阅读，并造成技术负担。

Cruft in computer jargon is also used to describe different situations like obsolete computers, old monitors, or obsolete hard disks. Still, in our case, we are going to refer to the implications of the poorly written code.

计算机术语中的残篇也用于描述不同的情况，例如计算机陈旧，旧显示器或硬盘陈旧。 不过，在我们的案例中，我们将参考编写不良的代码的含义。

Technical debt is a concept in software development that reveals the cost of redoing things caused by choosing a quick solution instead of solving problems using the best solution we can implement at the moment.

技术债务是软件开发中的一个概念，它揭示了重做选择快速解决方案而不是使用我们目前可以实现的最佳解决方案解决问题所引起的事情的成本。

技术债务和软件残留 (Technical Debt and Software Cruft)

When we talk about technical Debt and Cruft, we refer to a way of thinking about the treatment of Cruft as if it were a financial Debt.

当我们谈论技术债务和Cruft时，我们指的是一种考虑如何处理Cruft的方式，就好像它是金融债务一样。

Sometimes when we develop functionality, we don’t have all the knowledge to implement it in the best possible way at that time, but this doesn’t mean that we don’t have to think about it and do it following good practices. This is what makes the technical debt we are generating easy to pay in the future or not.

有时，当我们开发功能时，我们当时并没有全部知识以最佳方式实现它，但这并不意味着我们不必考虑它，也不必遵循良好实践。 这就是使我们将来产生的技术债务是否容易偿还的原因。

If the code we have written in the past has generated a technical debt in the present, and this code is straightforward and easy to understand, the interest to be paid will be small because refactoring will be simple and will not require a lot of time (money). But, if the code is difficult to understand, we will have to pay a lot of interest because it will take us a long time to understand it and then refactor it.

如果我们过去编写的代码在当前造成了技术上的负担，并且该代码简单易懂，那么由于重构将很简单且不需要很多时间，因此要支付的利息将很小。钱)。 但是，如果代码难以理解，我们将不得不付出很大的兴趣，因为这将花费我们很长时间来理解它，然后对其进行重构。

The following video explains the Technical Debt Metaphor:

以下视频解释了技术债务隐喻：

Debt Metaphor by Ward Cunningham

沃德·坎宁安 ( Ward Cunningham)的债务隐喻

For example, let’s imagine that we have developed an algorithm to recognize patterns in images and identify cats. The algorithm is not perfect, but we are aware of it, and we have designed it in such a way that when we want to improve it again in the future, it will be easy to understand and modify it.

例如，假设我们已经开发出一种算法，可以识别图像中的图案并识别猫。 该算法不是完美的，但是我们已经知道它了，并且我们已经设计了这样一种方法，使得当我们将来希望再次对其进行改进时，将很容易理解和修改它。

In this case, the cost of doing will be small. But on the contrary, if we use an algorithm that we copy from somewhere and then modify without understanding it very well, and also without following any good practice, the cost of refactoring it will be very high. This cost is the interest, and it will depend on us if they are big or small in the future.

在这种情况下，这样做的成本将很小。 但是相反，如果我们使用从某个地方复制然后在不十分了解它的情况下进行修改的算法，并且也没有遵循任何良好实践，则重构它的成本将非常高。 这是利息，这取决于我们将来它们的大小。

The problem, therefore, is not mainly the Cruft that we are leaving but not being aware of it and not understanding it well. Why do we implement it that way? What does it do exactly? Is the above algorithm used in many places, is it implemented following good practices?

因此，问题主要不在于我们要离开但仍未意识到和不了解它的残留物。 我们为什么要这样实施？ 它到底是做什么的？ 上面的算法是否已在许多地方使用，是否遵循良好做法实施？

In the following example, suppose that we know from the beginning the scope of the Cruft, and we designed it with the idea of refactoring it in the future. Also, it is not very integrated with the rest of our software, so the interests that we will have to pay in the future will be small:

在下面的示例中，假设我们从一开始就了解Cruft的范围，并且在设计时考虑了将来对其进行重构的想法。 而且，它与我们的其他软件没有很好地集成在一起，因此我们将来必须付出的利益很小：

In this other case, we know from the beginning the scope of Cruft. We designed it with the idea of refactoring it in the future, but it is very integrated with the rest of our software, so the interests we have to pay are high but the sooner you pay off and eliminate the Cruft, less technical debt will be created, and the interest will not continue growing:

在其他情况下，我们从一开始就知道Cruft的范围。 我们设计它的目的是在将来对其进行重构，但是它与我们的其余软件高度集成，因此我们必须付出的利益很高，但是您越早付清并消除Cruft，技术债务就越少产生的兴趣将不会继续增长：

This is the worst-case scenario. We are not aware of the technical debt generated in the past, so we will first have to know its scope and understand it in order to then try to refactor it without spoiling anything. If the code was not written according to good practices, refactor this would be very complicated and expensive:

这是最坏的情况。 我们不了解过去产生的技术债务，因此我们首先必须知道它的范围并了解它，然后才能尝试对其进行重构而不会破坏任何东西。 如果代码不是根据良好实践编写的，则重构它会非常复杂且昂贵：

我们如何才能去除碎屑？ (How can we remove the Cruft?)

Removing the Cruft helps us to make it cheaper for future changes to it is a good practice to eliminate it gradually. We can start removing Cruft in those areas that we frequently use, thus significantly reducing our debt and interest.If the Cruft we want to remove is almost not used and its relevance within our code is small, it is better not to invest a lot of time in it because the interest we will pay in the future will be minimal.

删除Cruft可帮助我们使其更便宜，以便将来对其进行更改，这是逐步消除它的好习惯。 我们可以在经常使用的区域开始删除Cruft，从而显着减少我们的债务和利息。如果要删除的Cruft几乎没有使用，并且在我们的代码中相关性很小，那么最好不要花很多钱时间，因为我们将来要支付的利息将很小。

As in life itself, invest in what gives you more value in the future.

与生活本身一样，对未来能带来更多价值的东西进行投资。

结论 (Conclusion)

What I find most useful is to know how to differentiate the type of debt we are generating. It is not the same to be conscious of it and leave it as best as possible to solve it in the future than not even to realize the debt we are generating, and the latter will make us pay a very high price in the future when we try to modify or add new features.

我发现最有用的是知道如何区分我们正在产生的债务类型。 意识到这一点并让它尽可能地在以后解决它，而不是甚至不意识到我们正在产生的债务，这是不同的，后者将使我们将来在我们付出高昂代价时尝试修改或添加新功能。

Thanks for reading me!

感谢您阅读我！

翻译自: https://medium.com/swlh/software-cruft-28ae5e766e98

软件需求分析的任务