Название: Software Reviews - Identifying Risks and Problems in Software
Автор: Christine Koppelt, Markus Harrer, Gernot Starke
Издательство: innoQ Deutschland GmbH
Год: 2022-12-07
Язык: английский
Формат: pdf (true), epub
Размер: 10.2 MB

Practically all software suffers from problems: Maybe it runs too slowly, sometimes crashes, doesn't look as nice as the competitors' product or changes take too long. Apart from hello-world applications, there is always room for improvement. Here we show you how to detect such problems.

Have you ever experienced a cursor that moves unspeakably slowly across the screen, and the whole application (apparently) ignores clicks or keystrokes? This behavior represents a symptom—intuitively, we speak of a “slow system” or “poor performance.” Instead of rushing to optimize the event handling or window management of the used GUI framework, we should explore the cause(s) of the poor performance. And this is where reviews come in.

Let us list a few possible causes for the above example of poor GUI behavior:

• The application uses too much working memory, and the operating system has to swap it in the background.
• The application is performing tedious background calculations on a sizable amount of data.
• The runtime environment performs a so-called garbage collection to free up memory, leaving little CPU capacity for your application.
• The application is blocked by input/output operations.
• The database has no index for the search criteria you entered into the application and has to search billions of records sequentially, etc.

Check use of appropriate technology: The choice of underlying technologies and frameworks can significantly influence the changeability of a system. Example: In early architecture and programming paradigms of Enterprise Java, development teams had to configure their systems manually in XML-based deployment descriptors besides fulfilling complicated programming requirements. This was both time-consuming and error-prone. Simplified models such as Spring Boot reduce the cognitive load for development teams and, therefore, most times lead to systems that are easier to change. Therefore, you should check the technologies and frameworks used to determine whether necessary or frequently recurring changes are made easier or more difficult as a result.

Source code is one (or even the) central artifact of your system. So, code analysis will almost certainly reveal some problems or risks to your system. In this chapter, we introduce you to methodological tools that allow you to perform such analyses. Even if you already perform code reviews or static analysis. Read on anyway. We have a few surprises in store for you. A side note: If your development team uses unit testing, you are already actively engaged in code analysis. These unit tests analyze the behavior of your system on a detailed level.

The most straightforward tool for testing, and one that every development team is familiar with, is called debugger. A debugger allows us to track the operations of a piece of software at runtime, almost at the atomic level. With a debugger, you can check your assumptions about specific processes in a finely detailed way. Yes, theoretically, you could do that by reading the source code, but some dependencies are only built at runtime. Often it is more convenient to use the debugger: And unlike assumptions made when reading code, the debugger tells the truth. :-)




ОТСУТСТВУЕТ ССЫЛКА/ НЕ РАБОЧАЯ ССЫЛКА ЕСТЬ РЕШЕНИЕ, ПИШИМ СЮДА!