Chapter 4 to Chapter 8 of Agile Software Development (principles, models and practices)

Chapter 1 Test

The fire tests the real gold, and the adversity grind the will.
-- Lucius sennega (4-AD 65, BC)

1. Test-Driven Development Method
The test-driven approach has a positive impact on the design of the software we are writing:
(1) Each function in the program has been tested to verify its operation correctness.
(2) writing tests first forces us to use different observation points and design software that is easy to call.
(3) by writing a test, we can force ourselves to design the program as testable, forcing us to lift the coupling in the software (force us to decouple the software)
(4) testing can be an invaluable form of documentation
We believe that, as long as the program is written according to the implied structure of the test, it can pass the test, which becomes an intentional programming (intentional programming ).
Test promotes isolation and decoupling between modules

2 Acceptance Test
For verification tools, unit testing is necessary, but not adequate. Unit tests are used to verify that small components of the system should work in the desired way, but they do not validate the correctness of the system as a whole. Unit Tests are white-box tests used to verify individual mechanisms in the system ). The acceptance test is a black-box tests (black-box tests) used to verify that the system meets the customer's needs ).
The acceptance test is written by a person who does not understand the internal mechanism of the system. Customers can write acceptance tests directly or with some technical personnel (such as QA. The acceptance test is a program and therefore can be run. However, the acceptance test is usually written in a script language created for customers of the application. System code writers cannot write acceptance tests here!
Acceptance testing is the final document about a feature. Unit Tests are compiled and run documents about the internal structure of the system, and acceptance tests are compiled and executed documents about the system features.
In addition, writing acceptance testing behaviors has a profound impact on the system architecture. In order for the system to be tested and tested, the system must be decoupled at a very high system architecture layer.
The acceptance test can encourage you to make good system architecture decisions in a big aspect.
Creating an acceptance test framework seems a difficult task. However, if you only create the part required for the acceptance test of the features contained in a single iteration in the framework, you will find that it is not difficult. You will also find that the effort is worthwhile. We can see that acceptance testing is required for each iteration, and the workload is not too large.
We have not written any code or made any design. This is the best time to start considering acceptance testing. Exposure programming once again becomes a useful tool. We should write them as we think the acceptance test should, and then we can build a script language and construct the system to be developed according to the structure of the script language. (This is worth learning from in the project development process, when the system is not designed and the code is written, the acceptance test of the system is given priority and the acceptance test is constructed using the scripting language, in this way, we can force us to compile the code of the system we are about to design and develop according to the verification test we have designed. This is very helpful for the design and architecture !)
To make system verification easy to write and change. Place them in a configuration management tool and save them so that they can be run at any time. Therefore, it is reasonable to write acceptance tests using simple text files.

3 conclusion
Both unit testing and acceptance testing are in the form of documents that can be compiled and executed; therefore, they are accurate and reliable. In addition, the language used for writing tests is clear and their viewer makes these languages very readable. Programmers can read unit tests. Therefore, unit tests are written in programming languages. The customer can read the acceptance test because the acceptance test is written in a language designed by the customer.
Perhaps the most important benefit of testing is its impact on architecture and design (and indeed ). To make a module or application testable, it must be decoupled. The more testability, the weaker the coupling relationship. Comprehensive Consideration of acceptance testing and Unit Testing behavior has a far-reaching positive impact on the software structure.

Chapter 2 reconstruction

The only thing lacking in the world is human attention.
-- Kevin Kelly (one of the chief prophets of the New Economy), Wired Magazine

In Martin Fowler's masterpiece "refactoring", he thought refactoring as: "... The process of modifying the code without changing the Code's external behavior to improve the internal structure of the Code ."
Each software module has three responsibilities. The first responsibility is the functions completed by it. This is also the reason for the completion of this module. The second responsibility is to respond to changes. Almost all modules need to change in their lifecycles. Developers have the responsibility to ensure that such changes should be as simple as possible. The third responsibility is to communicate with those who read it. Developers who are not familiar with this module should be able to easily read and understand it.

Program for generating a prime number: A simple refactoring example
Example

2 Conclusion
The restructured program reads much better than the first one, and the program works better. The program can become easier to understand and the parts of the program structure are isolated from each other, which makes it easier to change.
The purpose of refactoring is to clean your code every day. We want to extend and modify our system with minimal effort. The most important thing to do is to keep the code clean.

Chapter 2 one Programming Practice

Design and programming are human activities. If you forget this, you will lose everything.
-- Bjarne stroustrup, 1991

In this chapter, the author gives a programming practice, a bowling program, and uses an instance to show detailed scenes of team-end programming!

Part 2 agile design

In an agile team, The Global View evolves along with the software. In each iteration, the team improves the system design so that the design is best suited to the current system. The team will not spend much time predicting future needs and needs, nor try to build some infrastructure today to make the features they think will be needed tomorrow. They prefer to focus on the current system structure and make it as good as possible.

Poor design symptom definition:
Rigidity: Hard to Change Design
Fragility: design is vulnerable
Immobility: Hard to reuse design
Viscosity: difficult to do the right thing
Unnecessary complexity (needless complexity): over-design
Unnecessary repetition: Misuse of the mouse
Opacity: chaotic expression

Some object-oriented design principles:
The single responsibility principle (SRP)
The open-close principle (OCP) Principle)
The liskov substitution principle (LSP)
The dependency inversion principle (DIP)
The interface segregation interface (ISP)

The agile team applies these principles to remove odor. These principles are not applied when there is no smell. It is wrong to follow the principle unconditionally. These principles are not perfume that can be sprayed everywhere in the system at will. Excessive adherence to these principles will lead to the design odor of unnecessary complexity (needless complexity.

Chapter 2 What is agile design

"After reviewing the software development lifecycle in my understanding, I came to the conclusion that the only software document that actually meets engineering design standards is the source code list ."
-- Jack Reeves

1. Design odor-smell of corrupt software
(1) Rigidity refers to the difficulty in making changes to the software, even if it is simple. If a single change will result in dependency-related modules and Sino-Russian chain changes, the design will be rigid. The more modules that must be modified, the more rigid the design.
(2) Vulnerability refers to the possibility of problems in many aspects of the program during a change. It is often said that there is no conceptual correlation between the location where new problems occur and the location where changes occur. Fixing these problems will lead to more problems, so that the development team is like a dog that keeps chasing its own tail. Oh, this description is really appropriate.
(3) Robustness refers to the design that includes useful parts for other systems, but the efforts and risks required to separate these parts from the system are enormous. This is a pity, but it is very common.
(4) There are two types of viscosity: Software viscosity and environment viscosity.
When the methods that can maintain system design are more difficult to apply than the blunt techniques, it indicates that the design is highly viscous.
When the development environment is slow and ineffective, the environment will become slow.
Regardless of the project's stickiness, it is difficult to maintain the software design in the project. We want to create a system and project environment that is easy to maintain and design.
(5) unnecessary complexity if the design contains components that are currently useless, it contains unnecessary complexity.
(6) unnecessary repeated cut and paste operations may be useful for text editing, but they are catastrophic code editing operations.
When the same code appears in a slightly different form, it means that the developer ignores the abstraction. For them, discovering all duplicates and eliminating them through appropriate abstraction may not have a high priority level, but doing so will greatly help make the system easier to understand and maintain.
(7) obscure refers to the hard-to-understand module.
To prevent this situation, developers must stand in the position of the code reader and work together to refactor their code so that the reader of the code can understand the code. Can be reviewed by others.

The most unstable thing in the big data software project is the demand. Demand is in a state of continuous change. This is a fact we must accept as developers! We live in a world with ever-changing needs. Our job is to ensure that our software can withstand those changes. If our software design degrades as demand changes, we are not agile.
The agile team did not try to predict how the program would change at the very beginning when designing the module. On the contrary, they are written in the simplest way. They did not modify the design of the module until the demand finally changed, so that it was flexible.
In short, agile developers know what to do because:
(1) They follow agile practices to develop problems;
(2) they apply design principles to diagnose problems;
(3) they apply appropriate design patterns to solve the problem.
The interaction between the three aspects of software development is design.

Agile developers are committed to keeping the design as appropriate and clean as possible. The design must be kept clean and simple, and the source code is the most important expression of the design, so it should also be kept clean. Professional features require that we, as software developers, cannot tolerate code corruption.

2 Conclusion
Agile design is a process, not an event. It is a process of continuous application principles, patterns, and practices to improve the structure and readability of the software. It strives to keep the system design as simple, clean, and expressive as possible in any practice.

Chapter 2 single responsibility principle (SRP)

Only Buddha should assume the responsibility of publishing xuanmiao secrets.
-- E. Cobham Brewer, 1810-1897
English story dictionary, 1898

This principle was once described in the books of Tom demaro and meilir page-Jones and called it cohesion ). They define cohesion as functional correlations between components of a module.

1. Single Responsibility Principle
For a class, there should be only one reason for its change.
Each role is an axis of change ). When the demand changes, the change will be reflected in the changes in the class's responsibilities. If a class assumes the extra responsibilities, there will be multiple reasons for the change. If a class has too many responsibilities, these responsibilities are coupled. A worthwhile change may weaken or keep this class from fulfilling other responsibilities. This coupling will lead to a fragile (fragile) design. When changes occur, the design will suffer unexpected damages.
In SRP, we define responsibility as a reason for change ). If you can think of another motive to change a class, you have more than one responsibility.

2 Conclusion
SRP is one of the simplest and most difficult to use in all principles. We will naturally combine our responsibilities. What software design really needs to do is to discover responsibilities and separate them from each other. In fact, the rest of the principles we will discuss will return to this issue in one way or another.