Agile Software development 2

1,
Through repeated iterations and releases, the project enters a predictable and comfortable development pace. Everyone knows what to do and when to do it. Stakeholders often and practically see the progress of the project. What they see is not a notebook that is full of pictures and plans, but a software that they can touch and feel that they can work, and they can also provide their own feedback to the software. P20

 

2,
When you can measure what you say and express it with numbers, it means you understand it. If you cannot measure it, you cannot express it with numbers, it means that your knowledge is lacking and unsatisfactory. -- Lord Kevin (British physicist), 1883. P17

 

3,
In addition, by writing a test, we force ourselves to design the program as testable. It is very important to design programs that are easy to call and can be tested. In order to be easy to call and testable, the program must be decoupled from its surrounding environment. In this way, writing a test forces us to lift the coupling in the software (forces us to decouple the software ). P21.

 

4,
In the initial stage of project iteration, it will be tempted to manually perform acceptance tests. However, this makes it unwise to decouple the system at the initial stage of iteration because of the need for automated acceptance testing. However, at the earliest stage of iteration, if we were very clear about the necessity of automated acceptance testing, we would make a very different balance between the system framework. In addition, just as unit testing can enable you to make good design decisions in a small way, acceptance testing can enable you to make good system framework decisions on a large scale. P25

 

5,
Perhaps the most important benefit of testing is its impact on the framework and design. 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 profound positive impact on the software structure. P2

 

6,
Each software module has three responsibilities. The first responsibility is the functions completed by it. This is why this module exists. The second responsibility is to respond to changes. Almost all modules need to change in their lifecycles, and developers have the responsibility to ensure that such changes should be as simple as possible. A module that is hard to change is poor and needs to be corrected even if it can work. 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. A module that cannot communicate with each other is also poor and needs to be corrected. P28