Spiritual connotation of agile development

Basically, all agile development practices, such as TDD, Pair programming, continuous integration, and refactoring ), there is a unified concept --Never blocked. It is like a good ball hit player always makes sure that every time he hits the ball, he creates a good opportunity for the next blow. Every great agile developer makes every little progress and needs to make sure the next step. A good agile developer will never take a step, and then there will be no progress, or there will be no progress for others.

So how do you know that your progress has stopped? If you cannot run the system, the progress will stop. If you cannot pass the test, the progress stops. In the agile world, progress can only be measured by tested and runable systems. If the system cannot run or the test fails, all the progress will be stopped, because the feedback loop can tell us that the code is faulty or everything is fine. When the written code cannot be executed, it is like driving a car, but you cannot see the outside of the windshield. The wheel may be still spinning, but you don't know which direction you are heading for. Maybe you are heading for the cliff. Keeping the system running at any time is like keeping the windshield clean. We cannot make progress unless we can see something.

Think about it. For example, two programmers are developing a project. Jack said he wants to write module J, while Bob said he wants to write module B. When Bob writes code to a certain degree, he must find J. But Bob has to wait before J is finished. If Bob was a good agile developer at that time, he would never let things go that far. He will create an interface for J and implement it with the false code, so that he can continue to develop his own tests.

Imagine a four-person team working on a three-tier architecture management information system. They have already completed their work through the abstract layers of the architecture. Gerry and George work on the GUI, Marvin is on the middle layer, and debeay is on the database. When new features are added, The first thing debeay does is to change the table structure of the development database. The GUI can run only when the middle layer is running. Debeay has painted the dark paint on the windshield, and the entire team is like a blind car. If debeay was a good agile developer at that time, she would find a way to incrementally modify the data structure by adding new columns or tables without changing the old ones. After the iteration is completed, the data structure will be finished, and the system will never stop running.

Keeping the system running continuously is the first goal. You will never do anything that will destroy the system for more than a few seconds. If you want to make a huge design change, you will find a way to make every step of the change tiny enough to ensure that the system can run. If you can find a way to keep all tests running, the system will not be suspended for more than a few seconds.

This is not an easy-to-grasp concept. Developers are always used to making some changes to mess up the entire system, and then try to piece together the blocks. Many people are keen on this experience. In fact, when I talked to a developer, he said that tearing the system apart and piecing it together is a skill required by a programmer. He is proud of his ability to do such a thing. Because this is important to his self-esteem, I have to politely persuade him that his sense of self-fulfillment is based on the risks that he has taken and the profit that his employer has created. In fact, he was excited about the ability to survive. He is a dangerous person, and he is taking the property of his employer. This is not a professional behavior. Agile development is like a cautious chess game, not a code-Chicken game (5) that does not count as a consequence ). Excellent agile developers carefully plan a route for their goals, that is, every small step can keep the system running and testing successful.

Some developers believe that this process is inefficient and slow. They thought it would be faster to first mess up the system and then restructure it into a new one. It may be faster sometimes. However, it is like you want to drive to the store, so you can adjust the direction to direct to the store and paint the windshield black, then, regardless of the red light and road conditions, they will go straight toward the store. If it happens, you can drive faster. But in more cases, it is difficult to get on the road.

This goal can be extended to all layers of the team and organization. Never blocking means that you have set up your development environment so that blocking will not happen. Excellent agile teams use unblocked source code control methods. If Bill has a module checked out, Bob can also check it out, but the first check in is successful. Assuming that the core team is building a reusable framework for us, and some of the features we need are not ready yet, we will write it first, use the core team's functions when they are ready. If the enterprise architecture supports us in this roundabout way, we only need to spend a few days learning it, and then we can ignore the enterprise architecture, and let the development of functions in a simple way. We will not be blocked.

:

1. TDD: Test-driven development. For details, see "three military rules of TDD ".

2. Pair programming, Pair programming, also translated as "Pair programming ". The code is completed by a pair of programmers using a computer. One of the pairs controls the code, and the other observes the code being entered and looks for errors and improvements in the code. The roles are frequently exchanged between the two, and the pair relationship changes at least once a day, so that each programmer can work in two different pairs in a day. According to a study by Laurie Williams and Nosek, pairing not only reduces the efficiency of the development team, but also greatly reduces defects.

3. Continuous integration and continuous integration. Programmers perform multiple checkin operations every day and integrate their code. The rule is simple. The first one can be split as long as it is completed, all others are responsible for code merging (merge. To avoid too long merging time, team members frequently split their modules. Therefore, the XP team builds the system multiple times a day and recreates the entire system.

4. refactoring. As we add features or handle errors, the structure of the Code will gradually degrade, leading to tangle and difficulty in maintenance. The XP team uses regular code refactoring to reverse this degradation. Refactoring is a series of small transformations without changing the code behavior. It aims to improve the system structure.

5. Code-chicken, password chicken, an elasticsearch game popular in North America.