Lecture
Extreme Programming (English Extreme Programming , XP ) is one of the flexible methodologies for developing software. The authors of the methodology are Kent Beck, Ward Cunningham, Martin Fowler and others.
The name of the methodology comes from the idea of applying useful traditional methods and practices of software development, raising them to a new “extreme” level. So, for example, the practice of executing code revision, which involves testing by a programmer of a code written by another programmer, in the “extreme” version is “pair programming”, when one programmer is coding and his partner is continuously looking at the same time code.
The twelve basic techniques of extreme programming (for the first edition of the book Extreme programming dialogue ) can be combined into four groups:
XP involves writing automatic tests (software code written specifically to test the logic of other software code). Special attention is paid to two types of testing:
The developer cannot be sure of the correctness of the code written by him until all tests of the modules of the system developed by him have worked. Module tests (unit tests) allow developers to make sure that each of them individually works correctly. They also help other developers understand why this or that piece of code is needed, and how it functions — as you study the test code, the logic of the code being tested becomes clear, as you can see how it should be used. Module tests also allow the developer to refactor without any concerns.
Functional tests are designed to test the functioning of logic formed by the interaction of several (often quite impressive size) parts. They are less detailed than unit tests, but they cover much more - that is, tests that affect a larger amount of code during their execution have a greater chance to detect any incorrect behavior. For this reason, in industrial programming, writing functional tests often has a higher priority than writing unit tests.
For XP, an approach called TDD (from test-driven development) is a higher priority. In accordance with this approach, a test is first written, which initially does not pass (since the logic that it has to check does not yet exist), then the logic necessary for the test to pass is realized. TDD, in a sense, allows you to write code that is more convenient to use - because when writing a test, when there is no logic yet, the easiest way is to take care of the convenience of the future system.
The main goal of the planning game is to quickly form a rough work plan and constantly update it as the task conditions become more and more clear. Artifacts of the planning game are a set of paper cards on which customer stories are written, and an approximate work plan for issuing the following one or more small versions of the product. The critical factor by which this planning style turns out to be effective is that in this case the customer is responsible for making business decisions, and the development team is responsible for making technical decisions. If this rule is not fulfilled, the whole process falls apart.
The “customer” in XP is not the one who pays the bills, but the end user of the software product. XP asserts that the customer has to be in touch all the time and is available for questions.
Pair programming assumes that all code is created by pairs of programmers working on the same computer. One of them works directly with the text of the program, the other looks at his work and monitors the overall picture of what is happening. If necessary, the keyboard can be freely transferred from one to another. During the work on the project, the pairs are not fixed: it is recommended to mix them up so that each programmer in the team has a good understanding of the entire system. Thus, pair programming enhances the interaction within the team.
If you perform the integration of the developed system often enough, then you can avoid most of the problems associated with it. In traditional methods, integration is usually performed at the very end of work on a product, when it is considered that all the component parts of the system being developed are completely ready. In XP, the integration of the entire system code is performed several times a day, after the developers have verified that all module tests work correctly.
Refactoring is a technique for improving a code without changing its functionality. XP means that once written code in the process of working on a project will almost certainly be redone many times. The developers of XP ruthlessly rework the previously written code in order to improve it. This process is called refactoring. The lack of test coverage provokes refusal to refactor due to the fear of breaking the system, which leads to a gradual degradation of the code.
Versions (releases) of the product should come into operation as often as possible. Work on each version should take as little time as possible. In addition, each version should be quite meaningful in terms of utility for business.
The earlier the first working version of the product is produced, the earlier the customer starts to receive additional profit at the expense of it. It should be remembered that the money earned today is more expensive than the money earned tomorrow. The sooner the customer starts to use the product, the earlier the developers will receive from him information that meets the requirements of the customer. This information can be extremely helpful when planning your next release.
XP assumes that in the process of working conditions of the problem can change several times, which means that the product being developed should not be fully and completely projected. Attempting to design a system in detail at the very beginning of work is a waste of time. XP assumes that design is such an important process that it needs to be carried out continuously throughout the entire project. Design should be carried out in small stages, taking into account the constantly changing requirements. At each time point, you should try to use the most simple design that is suitable for solving the current problem, and change it as the conditions of the problem change.
Architecture is an idea of the components of the system and their interconnections. Developers need to analyze the software architecture in order to understand where in the system it is necessary to add new functionality and what the new component will interact with.
The system metaphor is an analogue of what is called architecture in most methods. The metaphor of the system gives the team an insight into how the system is currently working, where new components are added, and what form they should take.
Choosing a good metaphor makes it easy for a group of developers to understand how the system works. Sometimes it's not easy.
All team members must comply with common coding standards during the work. Thereby:
If the team does not use uniform coding standards, it becomes more difficult for developers to perform refactoring; there are more difficulties when changing partners in pairs; by and large, project promotion is impeded. As part of XP, it is necessary to ensure that it is difficult to understand who is the author of a particular piece of code — the whole team works in a unified way, like one person. The team must form a set of rules, and then each team member must follow these rules in the encoding process. The list of rules should not be exhaustive or too voluminous. The task is to formulate general guidelines that will make the code clear for each of the team members. At first, the coding standard should be simple, then it can gradually become more complicated as the experience is gained by a group of developers. You do not need to spend too much time on the preliminary development of the standard.
Collective ownership means that each team member is responsible for the entire source code. Thus, everyone has the right to make changes to any part of the program. Pair programming supports this practice: working in different pairs, all programmers become familiar with all parts of the system code. An important advantage of collectively owning code is that it speeds up the development process, since any programmer can eliminate it when an error occurs.
The right of each programmer to change the code leads to the risk of errors introduced by programmers who believe that they know what they are doing, but do not consider some dependencies. Well-defined unit tests solve this problem: if unexamined dependencies generate errors, then the next run of unit tests will fail.
Comments
To leave a comment
Software and information systems development
Terms: Software and information systems development