Extreme Programming-understanding and practice

As a mainstream development method in the field of agile software development, extreme programming is more like an organic combination of a series of best practices than a systematic methodology. Some of these best practices are widely accepted (such as coding standards), while others are very disruptive. At first glance, they seem unacceptable.
In this article, I will explain my views on these seemingly weird best practices and briefly explain my thoughts on implementing these best practices.
I. planning games
It takes some courage to call a plan a "game. In traditional software development methods, planning is an important part. Prior to planning, careful estimation is required. During the implementation of the plan, it is necessary to keep track of and correct the plan, until the entire project is completed.
In XP, planning seems much easier. This is not because the plan itself has become sloppy and irrelevant, but because of the release of Small versions of XP. A software version is so short and simple that it is much easier to fully evaluate, budget, track, and correct it. In fact, the Planning Method Used in XP (with the participation of business personnel and developers and their respective roles) has long been used in most modern software enterprises, but because the project is too large, it is difficult to develop a complete plan at the beginning. In XP, people only need to track and manage small projects for one or two months, which virtually reduces the risk of planning.
2. Metaphor
In XP, metaphor is often used to replace the architectural design in the traditional development process. From the perspective of development guidance, the metaphor seems to be inaccurate and easy to misunderstand. However, for developers in the same project team with a similar background, metaphor is easier to understand and communicate. It is hard to imagine that two programmers can communicate effectively in the face of a huge architecture diagram, and the metaphor solves this problem well.
Iii. Simple Design
I don't know when to start. Developers are used to designing for tomorrow. A developer designs a complex class inheritance structure to improve the so-called flexibility of the program. No one knows that this value is not worth it. Not every part of the software needs to be extended. However, traditional software developers are forced to do so. If you are not prepared in advance, you will be caught off guard and pay a heavy price for changes.
However, in XP, the small version release method makes the change not so terrible, and the wide adoption of refactoring makes the code always more flexible when needed. In addition, because your code will always be reviewed by others (Code collective ownership and Pair Programming), you can avoid too simple pursuits and ignore important details.
Iv. Test priority
No code. How can I test a program? This is the easiest way to misunderstand test priorities. Test Priority makes developers more aware of how programs will be used. By thinking about different test cases, developers can also better understand the extended functions of the program. More developers can obtain an accurate user manual through test cases. In this user manual, describes all the input and output results that the author considers, which not only facilitates people to understand the program, this increases the chance of discovering program errors (missing test cases often reflect some usage situations ignored by the author ).
V. Pair Programming
Can two programmers sit together to improve development efficiency? Isn't a programmer a group of arrogant cats used to stand out from the crowd and lift their heads high?
This is not the case. With a correct, reasonable, and achievable goal, programmers can not only coexist peacefully, but also cooperate with each other to create excellent and high-quality programs. Communication has always been an important topic in software project management, and Pair programming provides a very effective communication channel. In addition, paired programming also makes it easier for new people to integrate into groups. Under the guidance of several senior programmers, it is easier for them to find out the context of the program and grasp the idea of the program. This method is easier and more effective than regular training. For all programmers in the team, Pair programming is an opportunity to understand the design ideas of others. Through Pair programming, the collective ownership of code can be better realized, it can also reduce the risks caused by staff flow.
The biggest benefit of Pair programming is that it can greatly reduce the possibility of potential changes in the program. Two people exchange their different understandings of the program through communication, making it easier to identify possible changes or errors in the program, making the program more reliable and robust.
Vi. Continuous Integration
Integration has always been one of the most laborious tasks. The code that was originally working well cannot run when it is put together. Even worse, there are hundreds of Alibaba Cloud error codes. No one knows where these error codes come from. This is the most difficult stage for almost every project. programmers must gather together, read a large number of interface definition files, view code repeatedly, and make continuous commitments.
Continuous integration is the solution to the above problems. Through the integration of multiple and small increments, we can always locate errors at the fastest speed (because of the small amount of code added), combined with a large number of test cases, we can also ensure that every integrated version is as reliable as possible.
In addition, continuous integration can provide us with a working version at almost any time. We can use this version for internal discussion and testing, customer presentation, customer testing, and minor version release, this makes it unnecessary for us to spend too much time repairing and completing existing programs to generate a demo.
The above briefly describes the advantages of the six best practices that will often cause controversy in XP. This article will discuss some issues that need to be paid attention to when implementing XP.
I. Applicability
The XP theory clearly states that XP is a lightweight method suitable for small and medium teams to develop software when their needs are unclear or rapidly changing. This means that XP does not apply to all situations. Before you plan to implement XP, you may need to carefully evaluate the specific situation of the project to determine whether you really need to use XP.
2. association between best practices
One feature of XP is that the best practices it honors are almost always closely related to other practices. when implementing a best practice, if other practices are not implemented at the same time, it is often difficult to achieve the initial goal. Therefore, when implementing XP, You need to carefully study the associations between practices to determine the best implementation solution.
3. Loose Environment
XP is a natural way to work. It advocates that programmers complete their work in the most natural way. This is often unacceptable for managers who are used to strict management systems of traditional development methods. As a result, although the highest decision maker decided to implement XP, the management could not (or unwilling) provide developers with a relaxed environment. In a rigid box, developers do not actually reply to the question, and they pretend to be practicing XP, but in fact they are still walking on the road (you can see many such examples, for example, some bluffing test cases ).
Iv. Endure changes
The impact of XP on traditional software project management may make many managers feel uncomfortable. Maybe once XP is implemented, it will bring huge changes to the project team. If such changes make you feel fear, please be patient for the moment. You cannot be sure that these changes are not good unless you see them with your own eyes. It's not too late to decide.
5. coming soon
The process of implementing XP cannot be too hasty. The best way is to implement it first in some project teams, and do not need to implement all practices simultaneously during implementation (but pay attention to the problems related to each practice ). Sometimes you will find that, after some practices are implemented, other practices become a matter of course. After careful evaluation and confirmation of XP's effectiveness in the project team, it will be gradually promoted within the enterprise. If necessary, voluntary principles should be adopted, members of the project team decide whether to implement XP.
The above is my understanding of XP in the software engineering process course and in my daily work and study.