XP method learning summary and thinking about the development of the group
Many of the XP methods can find shadows during the current company's development process. After reading relevant information, you can get a lot of gains from it, and the following will list some of the key points I think it is very helpful.
In XP, each person emphasizes that each person has the right to revise, in this way, in the group, it has been acquired inside the team. In the group, the principle should be implemented in the group, encouraging each member to reasonably modify the code of the entire system, according to individual Experience, such modifications are generally advantageous, even if they lead to some small influence, they can generally be overcome.
Emphasized the use of time, in fact, repeatedly emphasized in the XP method, some normalized discussions and a large number of documents are a useless work, thinking about it, how much is we swallowed in such useless ? Of course, this principle is not advocating non-document, the generation of documents should be determined according to the specific environment. It is difficult to determine a fixed mode of document, and the role of documents is to solve the difference in information communication, for example, in order to Solving communication with users, it is necessary to provide a simple number of paper system descriptions, this is not unfold here. In addition, XP emphasizes the simple principles throughout the development process, emphasizing "lightly load", so in our project, we must implement such ideas in our own thoughts, for a while to code, write comments, Design, test is effective, this is also a basic principle that is confirmed in XP: the code can pass all information, the work is the most direct work for the code, and the though think is to design it. Better code, the comment is to improve the readability of the code, the test is to improve the correctness of the code, all all this is work directly or indirectly, in practice, many people find that some are not practical Document repeated usage is quite low, so this principle is quite large to me, but also makes me focus on coding, design and testing, and can dispense some of my previous doubts: If you don't write Beautiful and standardized documents illustrate that our team's development efficiency is low, and it also shows that our product quality is not guaranteed, and it also shows that our company's competitiveness is low?
As for repeated emphasis on XP, I was also impressed by the advantages that were embodied in it, but the analysis of their operability and some objective factors, I think it can only be in subconsciousness. Programming The way, can also take some less obvious practical applications, such as some time to draw some key programming tasks, with the group member is written, and another person uses paper, pen or other tools in the process of writing code. Design and conception, or a person encoding, another person finds some relevant information, design test example, etc., as for the standardization of test cases, the design of documentation, etc., etc., it can be used, which can The amount is alleviated.
XP
The respect for developers and some degree of liberalization, in fact, such thoughts are also characterized by software development industries, software development is a brain power intensive job, and the personal factors of developers have a considerable amount of software products. Quality, as far as possible to create a comfortable working environment according to the hobby of developers, it is also indirectly in the quality of software products, and there are
XP
Such emphasized strict tests are supervised, and managers can feel relieved to wait for qualified and robust software products.
