Understanding of four cores of Extreme Programming

The core of extreme programming is four: communication, simplicity, feedback, and courage.

These four principles are also noticed during the project process, but the two masters Kent Beck and Martin Fowler can combine these four points, so that they can make up the extreme programming of the carriage, but it is not small to create. Next, I will only talk about some of my understanding of these four core issues in my learning and simple practices.

I. Communication

1) Communication between developers and customers

This is similar to the traditional software engineering. In the process of developing software, we also pay great attention to communicating with customers, especially in demand analysis, outline design, and acceptance testing, effective communication between developers and customers is essential, which will directly affect whether a project can meet the requirements of customers.

However, in extreme programming, the development stages of the customers are somewhat different. In the traditional project development process, the customers only need to be with the developers at the beginning and end, their responsibility lies in the help of business functions, but this inevitably leads to the following situation: at the beginning of the project, the customer raised wrong or inaccurate requirements, and then the project team began development. The customer did not intervene in the project for a long time, during project acceptance, the project team had to spend a lot of time and energy to adapt to the customer's needs. This is a great waste of time and money. In extreme programming, a field customer who is very proficient in business needs to not only provide business information at any time, but also compile the test code for business acceptance testing, in this way, the project direction will not be wrong to a great extent.

The process of extreme programming is the process of "aiming-" shooting-"adjustment-" adjustment ". It is not mandatory to accurately grasp the direction of the project at the beginning of the project, due to the presence of on-site customers, the project direction is constantly being adjusted, which can greatly avoid project detours.

2) Communication between developers

Currently, when recruiting developers and all other staff members, we emphasize team spirit. However, in actual work, apart from problems, in addition, I will ask for advice only when I solve the problems I encountered. (I used to do this. Maybe everyone will be different ), then we can get together to chat, eat, sing, and other activities outside the development process. The above can indeed bring about a certain degree of cohesion in the team, so that everyone can get along in harmony, but there is still a certain gap from the true team.

The education we receive has always been to cultivate an independent ability to solve problems. Therefore, when we encounter problems, we often think of solving them by ourselves rather than working with others.

A very important principle in the practice of extreme programming is Pair programming, which seems a bit strange. Because the first question we thought was to let two people do one thing at the same time. Isn't it a waste of productivity? But this is not actually the case. The so-called Pair programming is not a person programming, the other is watching, and another person also plays a very important role, and his brain is constantly running, he needs to help the coding personnel find low-level mistakes to prevent their code from getting wrong in direction, especially when there is a problem that the encoding person is not good at solving, he will directly take the keyboard and exchange roles with him for encoding.

The benefits of doing so may be realized only after practice. It not only avoids some errors, but also solves some problems that are prone to ambiguity through direct discussion. In addition, the ideas of the two people come together to solve the problem more quickly. In addition, in the process of communication, the level of everyone will be improved quickly. The process of Pair Programming is also a process of learning together. (Unfortunately, I only have one person here, but I will try my best if I have the opportunity)

3) Communication between developers and management personnel

In a project team, the relationship between managers and developers is a very important factor affecting the project. If the problem is not handled properly, it may directly lead to a project failure. The quality of management personnel is extremely demanding. If a manager is transformed from a technician, his management capability needs to be greatly improved. Otherwise, project confusion will occur due to lack of management capability. However, it is very important for a person with management skills to be admired by technical personnel. Otherwise, developers cannot follow the management, then his position is in danger.

In addition, if developers can communicate well with management personnel, their work environment will be greatly improved, not necessarily very luxurious rooms and advanced furniture, only an environment that can work comfortably can greatly improve the combat capability of a team. In addition, if developers can put forward their own ideas on the plan and budget of a project, they will avoid the occurrence of the final win of the project but the final profit will not be obtained.

Management personnel should also take the initiative to listen to the opinions of developers. Many developers are relatively introverted. If they do not ask them, they will only bury their dissatisfaction in their hearts, the final result is a sudden explosion, and then resign and leave, causing significant losses.

Ii. Simplicity

1) Simple Design

In the process of extreme programming, we advocate a simple design practice. The reason for this is that too many design documents will waste us a lot of time, and the design documents are not modified, maybe at the end of the project, we will find that the original design documents have already been completely invisible.

Therefore, what we need to do in our initial design work is to clarify the most important functions we need to implement, and then design the overall framework and core technologies, these documents will not exceed 10 pages from start to end, so even if there are some changes, we do not need to spend too much time to modify them. Especially after modification, we do not need to make great effort to make the code and documentation completely consistent.

However, a simple design does not mean that these designs are dispensable. On the contrary, simple pages are even more important, because the core content of a project is on top, therefore, you must be careful when writing.

2) Simple coding

The simplicity of coding is manifested in the iterative process. In the extreme programming process, it is not necessary to implement all the required functions at once, nor do it need to be completed at once without changing it. On the contrary, changes are promoted in extreme programming. We can simply implement some functions first, then add detailed content, and then refactor the program. The final code will be very simple, because after modification according to the refactoring principle, all classes, functions, and procedures are very short rather than lengthy. The functions completed by each module are very clear.

However, do not equate simplicity with randomness. Even if we want to implement simple coding, we still need coding standards so that everyone can easily understand the programs we have compiled. Other elephant attributes should be defined using nouns. It is also very useful to use verbs to start the process. We should follow them.

3) Simple Annotation

In some projects, the annotation requirements are very strict, and even the comments in a program must reach a percentage. This first day seems very reasonable, because annotations allow us to better understand the functions of the program, but it is not the same thing to think about it.

Someone once said, "A general programmer can compile programs that computers can understand, and a real expert can compile programs that ordinary people can understand ". It is true that, rather than making comments to explain the program, it is better to give everyone an understanding when naming variables, procedures, and functions, even if there are not many comments, another programmer is not very difficult to understand the program you write.

Therefore, we should try to use the Code itself to describe the problem during code writing, instead of using the help of comments. We need to write the code, if there are too many irrelevant code in it, on the one hand, it will waste our time and may lead to ambiguity; on the other hand, it will not be necessary to comment to the Windows source code filled with complaints. Comments only bring distracting effects to those who read the code.

4) Easy to test

Normally, if our projects are developed in waterfall mode, all tests will be placed after coding, including standalone testing, integration testing, function testing, and acceptance testing, in addition, most tests are performed manually. Therefore, based on experience, if the encoding takes 20% of the time, the test should take at least 40% of the time. In addition, many problems need to be modified during the test, which is also the reason that the test takes a lot of time.

In extreme programming, testing is automated by writing test code. Especially in some object-oriented programming environments, we can use xunit tools to quickly and effectively perform standalone testing. In addition, you can write the standalone test code before the code is officially coded. After each program is modified, run the test code to check whether the program is faulty. In addition, for program integration, eXtreme Programming advocates continuous integration, that is, continuous integration of compiled code modules that have passed the standalone test into the compiled system, the test suit integration test can be conducted directly to ensure that the Code does not affect the entire system.

We can see that encoding and testing in extreme programming are carried out in a small step, so that we can promptly discover and modify the errors. The automated testing tool ensures the efficiency of our work and avoids repeated work.

III, Feedback

1) Customer feedback on Software

In extreme programming, a very important practice is to have on-site customers. From then on, we can also see the importance of customer feedback. With on-site customers, we can provide feedback to the software at any time to ensure constant adjustment during the "targeting" process and to ensure the direction of the software forward. In addition, on-site customers can also provide feedback on problems encountered by developers during the development process, so that developers can avoid errors caused by their own subjective guesses. This is the easiest mistake for programmers to make in the coding stage of traditional software engineering, because at that stage, there was no customer participation, and the coding staff only compiled the code according to the detailed design, A lack of understanding of the business often results in difficulties in coding and standalone testing, and even serious errors, which will not be detected until the final acceptance test, the modification cost is very high. As a result, we can see that due to the presence of on-site customers, these possible errors have been eliminated in the bud, saving a lot of time, energy, and money.

However, it does not mean that we can find someone from the customer's company to be a field customer. The choice of field customer should also be a factor that can directly affect the success or failure of the project. A good on-site customer can not only accurately grasp the software direction, answer business questions, but also write acceptance tests to ensure that the business data in the software is correct. This requires him to be not only a manager, but also a certain degree of computer level. This may not be difficult to find in foreign countries, but it may be very difficult in China.

If there are no on-site customers, we must have corresponding solutions. I think one way is to make sure that there is a person at the system analyst level who can participate in coding in a small amount, in the process of pairing programming, he will give you a lot of help. In addition, he also has a more important task, that is, responsible for communication with customers, timely delivery of short-term iterations of the small version of the program to the customer, and listen to their feedback, that is, to play a bridge between developers and customers.

2) Test code feedback on functional code

In extreme programming, we advocate "coding is not dynamic, testing is the first". That is to say, you must write the test code before writing the functional code, the test code can be used to ensure that our function code runs correctly. In general, we use xunit as a tool for developing and testing code.

With the test code, functional code compilation is more like a process to solve the problem. What kind of problems? That is, the problem of changing the status of xunit to green. We need to constantly adjust our functional code to change the status bar from red to green. Looking at the green color, our mood will become better.

This method is especially useful when the program needs to change constantly, because in general, if we modify the function code, we need to repeat the previous test work, this is a waste of time and error-prone. With the automated test code, we only need to run test case to see what feedback it gives us. If the information provided by the xunit code is correct, we can rest assured to continue our work.

However, it does not mean that everything is fine with the xunit tool. We must make good use of this tool. First of all, we must have some theoretical knowledge of testing and understand what data needs to be used as test cases. In this way, we can perform real-time testing to ensure the quality of the program. In addition, the compilation of the test code is not completed at once. With the addition of the function, the test code also needs to change, while ensuring that the original code is correct, continue to write new code.

3) Feedback from management personnel to developers

This does not seem to be very important, but if you think about it carefully, who will ultimately rely on the completion of the software? Everyone should be very clear about this answer, but it is actually all developers. A project without a manager may be postponed, or the quality is not high. However, if a developer is absent, the project cannot be completed. Therefore, in order to ensure the satisfaction of developers, it is very important for managers to give feedback to developers.

Developers may encounter various problems during their work, such as rest, treatment, work environment, and tools and software used for work, these problems may directly affect the enthusiasm and efficiency of the work. Therefore, managers must keep ears to listen to these opinions and give feedback in a timely manner, so that developers can avoid emotional work, this will not only affect you, but also, due to the characteristics of Pair programming, such emotions will soon spread throughout the entire team and when everyone is in conflict with the current project, the following results can be imagined.

I think the task of management personnel is to unite developers so that all people can truly become a team, rather than a group of scattered sand. To achieve this, you need to always understand the requirements of developers. It seems that they are doing logistics-like work, but such work is often the most important.

4. Courage

1) Courage to accept tasks

At the beginning of the project, the management personnel usually assign tasks to developers. However, such allocation is only based on the estimates made by the managers themselves, so it is difficult to satisfy everyone. Sometimes some people want to engage in tasks they have not done, so as to learn new knowledge. At the same time, some people want to engage in tasks that they are familiar, in this way, you can make more achievements in a shorter time. Not only for everyone, but for a person, they may have different ideas at different times. So, some people are not satisfied with their tasks when assigning tasks based on subjective judgments of managers.

At this time, we may try to publish all the tasks to you, and then let the developers select the tasks they want to do. In this way, because the task is selected by yourself, the satisfaction will be greatly improved.

In this case, it is important for developers to have the courage to accept the task. If all of them choose the task that they think is easy, they can avoid the difficult task, then our method fails, because there must be some tasks that are not selected. At this time, managers should encourage developers in an appropriate way, so that they can select tasks that are challenging for themselves, which is also good for personal improvement.

As a developer, there should be no problems. Dare to meet the challenge is a quality that most programmers currently possess.

 

Reprinted statement:This article is transferred from

Http://blog.csdn.net/lingyun2005/archive/2005/04/18/352865.aspx

Http://blog.csdn.net/lingyun2005/archive/2005/04/27/365384.aspx