Agile Software Development Reading notes (iii)

Agile Design

If Agility (Agility) is about building software in small increments, how do you actually design the software? And how do you ensure that the software has a good structure for flexibility, maintainability, and reusability?

In an agile team, the global view evolves with the software. In each iteration, the team improved the system design to make the design as suitable as possible for the current system. The team doesn't spend a lot of time predicting future needs and needs, or trying to build some infrastructure today to support features that they think will be needed tomorrow. They prefer to focus on the current system structure and make it as good as possible.

So how can you ensure that the global view evolves with the software? When any of the following smells are present in the software, it indicates that the software is corrupting. Members of the Agile team take some action to prevent the software from corrupting. The odor of a common design-the smell of corrupted software-is listed below [1].

1. Rigidity (rigidity): It is difficult to make changes to the system, because each change will force many other changes to the rest of the system.

2. Vulnerability (fragility): Changes to the system can cause problems in many places where the system and the changes are conceptually unrelated.

3. Robustness (immobility): It is difficult to unravel the tangled system and make it a component that can be reused in other systems.

4. Viscosity (Viscosity): It is more difficult to do the right thing than to do the wrong thing.

5. Unnecessary complexity (needless complexity): The design contains an infrastructure that does not have any immediate benefits.

6. Unnecessary duplication (needless repetition): The design contains a repeating structure that can be unified using a single abstraction.

7. Obscurity (Opacity): Difficult to read and understand. Not very good at showing intentions.

What motivates the corruption of software? In non-agile environments, the degradation of design is caused by the fact that requirements are not changed in the manner foreseen by the initial design. Often, the changes are urgent, and the developers who make the changes are not familiar with the original design ideas. Thus, while changes to the design can work, it violates the original design in some way. As the changes continue, these violations gradually accumulate, the design began to stink.

However, we cannot blame the change in demand for the degradation of the design. As a software developer, we have a very good understanding of the change in requirements. In fact, most of us recognize that demand is the most volatile element of the project. If our design fails due to a continuous, massive demand change, it shows that our design and practice are inherently flawed. We must try to find a way to make the design resilient to this change and apply some practices to prevent design corruption.

In contrast to traditional software development approaches that fear a change in demand, agile teams rely on change to gain vitality. The team is virtually non-pre-engineered, so there is no need for a mature initial design. They prefer to keep the system design as clean and simple as possible, and use many unit tests and acceptance tests as support. This preserves the flexibility and ease of understanding of the design. The team leverages this flexibility to continually improve the design so that the systems that are generated at the end of each iteration have the design that best fits the needs of that iteration.

The description above is very good, and the reader will not only ask: How does the agile developer know what to do?

The answer is:

(1), they follow the agile practice to identify problems;

(2), they apply design principles to diagnose problems;

(3), they apply appropriate design patterns to solve the problem.

The interplay of these three aspects of software development is design.

In summary: Agile design is a process, not an event. It is a continuous process of applying principles, patterns, and practices to improve the structure and readability of software. [1] It is dedicated to keeping system design as simple, clean and expressive as possible at any time.

Design principles

Design principles help developers eliminate odors in the design and build the best design for the current set of features. It is worth emphasizing that these design principles are a hard-won result of decades of software engineering experience. They are not the result of one person, but the crystallization of the ideas and writings of many software developers and researchers. Although they are described here as the principle of object-oriented design, they are in fact only a special case of the principles that have always existed in software engineering.

These principles are as follows:

1. Single Duty principle (the one Responsibility Principle, SRP): For a class, there should be only one cause for it to change [1]. In the SRP, we define our responsibilities as "Reasons for change". If you can think of more than one motive to change a class, then this class has more than one responsibility. The real thing about software design is to discover responsibilities and separate those responsibilities from each other. In fact, the rest of the principles we will be discussing will return to this issue in one way or another.

2. Open Closure principle (The Open-close Principle, OCP): Software entities (classes, modules, functions, and so on) should be extensible, but cannot be modified. The modules designed to follow the open closure principle have two main characteristics. They are: (1), open for expansion. This means that the behavior of the module can be extended. When the requirements of the application change, we can extend the module to the new behavior that satisfies those changes. In other words, we can change the function of the module. (2), to expand the module behavior, you do not have to change the module's source code or binary codes. The binary executable version of the module, whether it is a linked library, DLL, or java. jar file, does not need to be changed.

3.Liskov Replacement principle (the Liskov Substitution Principle, hereinafter referred to as LSP): subtypes must be able to replace their base types. The OCP principle is at the heart of many of Ood's claims. LSP is one of the main principles that make OCP possible. The substitution of formal subtypes makes it possible to extend a module that uses a base class type without modification. This kind of substitution must be something that developers can implicitly rely on.

4. dependency Inversion principle (the Dependency inversion Principle, referred to as DIP): (1), high-level modules should not be dependent on the underlying module. Both should be dependent on abstraction. (2), abstraction should not depend on details. The details should depend on abstraction. Using the dependency structure created by the traditional process design, the strategy is dependent on the details. Object-oriented programming inverts the dependency structure, making the details and strategy dependent on abstraction, and often the customer has a service interface. In fact, this kind of dependency is formally good for object-oriented design flags.

5. Interface Isolation principle (the Interface segregation Interface, referred to as ISP): Customers should not be forced to rely on methods they do not use [3]. If the client program is forced to rely on methods that they do not apply, then these client programs face changes due to changes in these unused methods. This inadvertently results in a coupling between all client programs. We want to avoid this coupling as much as possible, so we want to detach the interface.

Summarize

The Agile Software Development method is the innovative development method which realizes this essential characteristic of software development. The use of agile development methods can bring great benefits to us. Of course, it is also very difficult to do it completely. This requires not only a deep understanding of agility, but also the concerted efforts of agile team members.

Agile Software Development Reading notes (iii)