调试代码遗留
Modernisation usually occurs incrementally, there would be very few success stories about legacy systems modernisation following a big bang approach.
现代化通常是逐步进行的，采用爆炸式方法进行的遗留系统现代化的成功案例很少。
Some important challenges when modernising incrementally are: determining the order, priorities and correctness of the new resulting system; where tests play a fundamental part.
逐步进行现代化改造时，一些重要的挑战是：确定新系统的顺序，优先级和正确性； 测试在其中起着至关重要的作用。
The quantity and quality of tests seems to be inversely proportional to the uncertainty during a modernisation. The lesser the tests, the more we ignore.
测试的数量和质量似乎与现代化过程中的不确定性成反比。 测试越少，我们就越会忽略。
According to Michael Feathers, legacy code is code without tests [1]. Because legacy is, as modern, a concept tight to time, I guess there would be some legacy code with tests.
根据Michael Feathers的观点， 遗留代码是没有测试的代码 [ 1 ]。 因为遗留是一个紧迫的概念，因为它是现代的，所以我猜可能会有一些遗留代码经过测试。
In any case, let’s suppose you want to introduce tests or improve your harness. There’s always the question about where and how to do that. This article addresses specifically the where question, tests condition your modernisation, and vice-versa.
无论如何，让我们假设您要进行测试或改进您的工具。 始终存在关于在何处以及如何执行此操作的问题。 本文专门解决了问题所在， 测试决定了您的现代化，反之亦然。
Many techniques can be used for determining where to add tests, you can count on deterministic, stochastic or just experience. Certainly there is no silver bullet and right technique, only a set of tools you can use depending on your case and the certainty that there is usually no money and time enough for adding all the tests you would like to add.
许多技术可用于确定在何处添加测试，您可以依靠确定性，随机性或只是经验。 当然，没有灵丹妙药和正确的技术，只有一套工具可以使用，具体取决于您的情况，并且可以确定通常没有足够的金钱和时间来添加要添加的所有测试。
One key challenge for modernisation is to understand the system, so you can add tests. Some techniques mentioned by Robert C. Seacord et al [2] about code-structure representation are: Manual Code Reading, Artifact Extraction, Static Analysis, Dynamic Analysis, and Slicing.
现代化的一项主要挑战是了解系统，以便您可以添加测试。 Robert C. Seacord等人[ 2 ]提到的一些有关代码结构表示的技术包括：手动代码读取，工件提取，静态分析，动态分析和切片。
The technique presented below belongs to the Dynamic Analysis approach set of tools, where “dynamic analysis observes a program executing in the operational environment or in a simulation of the operational environment” [2]
下面介绍的技术属于“动态分析”方法的工具集，其中“动态分析观察在操作环境中或在操作环境中执行的程序” [2]
The idea is to understand how your app behaves through real logging information, understanding what is really important!. Profiling could be too expensive and not suitable for production environments.
这个想法是通过真实的日志信息来了解您的应用程序的行为， 了解真正重要的是什么！ 。 分析可能过于昂贵，不适合生产环境。
You can add logging to the different layers of your application, for example: controllers, services and repositories. Specifically how long a function took to finish. Then you select one layer for starting, usually the uppermost layer (e.g. controller) and log elapsed times for a representative time window (e.g. 2 days).
您可以将日志添加到应用程序的不同层，例如：控制器，服务和存储库。 具体来说，功能需要多长时间才能完成。 然后，选择一层作为开始层，通常是最上层(例如，控制器)，并记录代表时间窗口(例如2天)的经过时间。
Once your program finishes, you will have to extract:
程序完成后，您将必须提取：
How many times a function was executed (hits) 一个函数执行了多少次(命中) How long each function took to execute (elapsed time) 每个功能执行所需的时间(经过的时间)Now you can use a Priority Matrix [3] with hits vs elapsed time, to understand what is “important” (relevant at least). Keep in mind that you’ll have to position the centroid depending on the values you get for “x” and “y”. You could use averages for that, since all numbers are positive.
现在，您可以使用点击率与经过时间的优先级矩阵[ 3 ]来了解什么是“重要”(至少是相关的)。 请记住，必须根据“ x”和“ y”的值来定位质心。 您可以使用平均值，因为所有数字均为正数。
Priority Matrix 优先矩阵After creating the Priority Matrix you will end up with the following categories:
创建优先级矩阵后，您将得到以下类别：
Add tests. You should focus here for starting your modernisation. Ensure your harness is good enough in all layers related to these functions. 添加测试。 您应该集中精力开始现代化。 确保您的线束在与这些功能有关的所有层中都足够好。 Investigate more. It would be ideal to trace and understand more about what is happening with these functions. Maybe your application is suffering from low performance and you would need to focus here first. For example: database queries performance tuning affecting the rest of the system. 调查更多。 跟踪并了解有关这些功能正在发生的事情的理想方法是理想的。 也许您的应用程序性能低下，您需要首先关注这里。 例如：数据库查询性能调整会影响系统的其余部分。 Modernise later. If the number of hits is considerably higher than the rest, this might be telling you that the system does this thing very well, it might be important, and you need to keep that flawless. 以后进行现代化。 如果命中次数大大高于其余命中次数，则可能是在告诉您系统可以很好地执行此操作，这可能很重要，并且您需要保持无瑕疵。 Discard. You might come later to these functions and modernise, but not now. 丢弃。 您可能稍后再使用这些功能并进行现代化，但现在不行。As you can see, the approach is semi-deterministic. Human intervention, common sense, and a nose for what is correct needs to be part of the process.
如您所见，该方法是半确定性的。 人工干预，常识和正确判断的鼻子需要成为过程的一部分。
For the areas where you want/need to dig in, you could use the logging information from the different layers (e.g. repositories), so you can better understand areas for improvement. It is worth inspecting functions where you foresee typical bottlenecks (e.g. external API or database access).
对于想要/需要挖掘的区域，可以使用来自不同层(例如存储库)的日志记录信息，这样您就可以更好地了解需要改进的区域。 值得检查的功能可以预见典型的瓶颈(例如，外部API或数据库访问)。
I have thought about this technique after profiling some apps this week. It is something that came to my mind, successfully tried some bits, and thought it would be interesting for some folks out there. Hope it helps!
在本周对一些应用程序进行概要分析之后，我曾考虑过此技术。 这是我想到的事情，成功尝试了一些尝试，并认为这对于那里的一些人来说很有趣。 希望能帮助到你！
翻译自: https://medium.com/@camposer/a-semi-deterministic-approach-for-directing-your-legacy-code-modernisation-and-tests-58fb9d1987d8
调试代码遗留
相关资源：四史答题软件安装包exe