何时应该维护、重构或重写代码

让我们谈谈重构与重写代码。一般来说，我们的倾向是保持遗留项目的可维护性，但当这根本不可能时，我们就会开始分析重构或重写的需求。

重构在计算机科学术语中，通常只是意味着我们需要在另一个事物中改变一些东西。

它是整个项目，还是您可以只重写应用程序的某些部分？我们如何开始区分和确定我们需要重构代码还是重写代码？

整个审计过程中的第一件事显然只是查看代码，理解它，查看文档。希望有一些。

让我们回到重构与重写。重构通常基本上是部分重写，而重写通常意味着我们从头开始完全重做。

这是可能的，但这在那时是有效的重构。重写通常是每当它说：“嘿，我们需要重写整个事情。” 通常情况下，如果使用重写这个词，我们需要做整个事情，而根据计算机科学术语的重构，通常只是意味着我们需要在另一件事中改变某些东西。我们正在改变应用程序的一个因素。

因此，如果应用程序的某个区域出现问题或无法维护，那么回退是重构的拨号将被确定为正确的选择，而重写是当存在无法修复的系统性问题时，或者我应该说在经济上无法解决通过重构如此多的应用程序来修复，无论如何你最终都会重写。所以这基本上就是区别所在。

当我们获得代码库时，我们的立场是什么？我的意思是，您是否觉得我们的开发团队倾向于让重构和重写繁重，还是我们更倾向于“让我们看看我们是否可以让遗留项目继续下去”的想法？

一方面，它每次都取决于客户的需求，这通常是很多这些问题的答案。但是从偏见的角度来看，我们总是首先尝试可维护性。我们尝试实际获取我们得到的东西，尽我们所能理解它，然后继续努力，随着时间的推移尝试改进它，以及新功能或任何其他目标。所以在一般意义上，我们确实尽量避免在必要时进行重构和重写，除非它真的是不可维护的。这取决于项目的历史。因此，归根结底，我们会推荐它，但如果可以，我们会尽量不推荐。

是的。因为我的意思是，当我们影响我们的决策时，我们总是必须考虑这些更大的业务考虑因素。那么，我们会考虑哪些业务考虑因素，好吧，“这就是我们可能想要尝试使用它的原因”或“这就是我们可能想要实际重写或重构的原因”。

现在说的是实际项目范围的考虑。如果您不在乎，如果应用程序有时会崩溃，那为什么要重构呢？如果它已经被设计为不稳定的，并且你已经接受它只是一个供部门中的几个人使用的内部业务工具，你可能不需要太担心它并且你可以接受它不会非常稳定。这取决于你在那里的目标。然后抽象出，好吧，可靠性的实际目标是什么？下一个显然是预算，因为。

是的。而且你必须考虑时间以及在重构和重写的同时你打算做什么？因为重写基本上意味着我们要重新做整个事情，使用我们迄今为止学到的所有东西。因此，有时这可能意味着比原始应用程序花费的开发周期更长。这可能意味着更短，这取决于您是否只想对其进行迭代并尝试改进麻烦的区域并更新过程中的其他所有内容。然后关于重构的事情，就像我提到的，与重写有点不同，

这通常意味着进入您将要使用应用程序编写任何内容的任何情况，无论它是遗留的东西还是不是首先要设计的东西。这首先意味着软件设计的想法。在你做之前计划你要做什么，甚至 UI 和 UX 设计。因为比方说，如果您先编写代码，然后为该代码设计 UI，最后只是将它们结合在一起，那么它们很可能不会完全吻合。这就像同时挖两条隧道，然后试图在山中相遇。