First, the contents of the experiment
(i) Agile Development and XP
The purpose of the software development process is to improve the efficiency of software development, operation and maintenance, and improve the quality of software, customer satisfaction, reliability and maintainability of software. It is not enough to have ideas of all kinds of processes, and we have a series of tools to ensure that these ideas can operate efficiently in practice. A common formula is: Software engineering = development process + tools. Agile Development (development) is a human-centric, iterative, and progressive approach to development. "Agile Processes" are a collection of values and methodologies.
Among them, extreme programming (EXtreme programming,XP) is a new and fast software development method. The XP team uses on-site customers, special planning methodologies, and ongoing testing to provide rapid feedback and comprehensive communication:
- XP is a methodology developed to target software that meets customer needs
- XP is a practice-based software engineering process and thought
- XP believes that code quality is more important than people generally think.
- XP is ideal for small, responsible, self-motivated teams to develop software that requires uncertainty or rapid change
XP software development is what is expressed through the XP guidelines:
- Communication: XP believes that communication between project members is key to the success of the project and regards communication as the main driver of coordination and cooperation in the project.
- Simple: XP assumes that the future cannot be reliably predicted, and it is economically unwise to consider it now, so you should not think too much about the future but should focus on the urgent needs.
- Feedback: XP considers the system itself and its code to be a reliable basis for reporting on the progress and status of the system development. The feedback of system development status can be used as a means to determine the progress of system development and determine the next development direction of the system.
- Courage: It represents XP's view that people are one of the most important aspects of software development. In the development of a software product human participation throughout its entire life cycle, is the courage to eliminate the dilemma, let the team to the local optimal left behind, to achieve more significant goals. Demonstrates XP's basic trust in "people make projects successful".
The basis for successful use of a practice in an XP environment is presented through the rules of XP, including: Quick feedback, hypothesis simplicity, incremental changes, advocating for change, and quality of work.
XP software development is the cornerstone of XP activities, including: coding, testing, listening, design.
(ii) Coding standards
Programming standards include: Descriptive names, clear expressions, straightforward control flow, readable code and annotations, and the importance of consistently using certain rules and idioms when pursuing these content.
The program does not have the most basic indentation, it is difficult to read, this problem is easier to solve in eclipse, we can click on the Eclipse menu Source->format or use the shortcut key ctrl+shift+f in accordance with Eclipse specification indentation.
A very important part of the code standard is how to name packages, classes, variables, methods, and so on, so that you can name your code to go up a notch immediately. The general naming conventions in Java are:
- To embody their own meanings.
- Terms for packages, classes, variables
- Method name with movable bin
- Package name all lowercase, such as: IO,AWT
- The first letter of the class name should be capitalized, such as: Helloworldapp
- The first letter of a variable name is lowercase, such as: UserName
The first letter of the method name is lowercase: setName
(iii) Pair programming
Pairing programming is an important practice in XP. In pair programming mode, a pair of programmers work side-by-shoulder, equally, and in complementary way. They sit in front of a computer, facing the same monitor, working with the same keyboard and the same mouse. They analyze together, design together, write test cases together, encode together, do unit tests together, do integration testing together, write documents together, and so on. There are two roles in pairing programming:
- The driver (Driver) is the person who controls the keyboard input.
- The Navigator (Navigator) plays the role of pilotage and reminding.
How to pair programming, why pair programming, the focus is:
- Drivers: Write design documents, conduct coding and unit tests, and other XP development processes.
- Navigator: Review the driver's documentation, the driver's implementation of the development process such as coding, consider the coverage of unit tests, think about the need for and how to refactor, and help drivers solve specific technical problems.
- Drivers and pilots constantly rotate their roles and do not work for more than an hour, and take 15 minutes off each hour of work. The navigator has to control the time.
- Active participation. Any task is the responsibility of the two people, and the responsibility of all. There is no "My Code", "Your Code" or "his/her code", only "our code".
- There are only horizontal gaps, and there is no level difference. They are pairs, and although they may have different levels of seniority, both sides have equal decision-making rights in terms of analysis, design, or coding.
Teamwork is a spirit that is emphasized in many places, and the smallest team is a one-to-two team, and the team spirit starts with pairing programming. The most important thing for people to get along with in social life is honesty, empathy and mutual benefit . There will be differences in pairing programming, how to cooperate more effectively to do things wrong .
(iv) version control
The collective ownership of XP means that everyone is responsible for all the code, which in turn means that everyone can change any part of the code. Pair programming contributes a lot to this practice: by working in different pairs, all programmers can see the full code. One of the main advantages of collective ownership is to increase the speed of the development process, because any programmer can fix it once there is an error in the code. This means that the code is placed in a place where everyone can easily get it, and we call it a code repository. This leads to another topic called versioning (version control).
Versioning provides a number of benefits for both teams and individuals.
- Versioning provides item-level undo (undo) functionality: Nothing is a finalized version, and any error must be easily rolled back. Let's say you're using the world's most complex word processing system. It has all the features you can think of, that is, the DELETE key is not supported. Imagine how cautious and slow you are when typing, especially when a large document is approaching the end of the day, a careless will start again (imagine you select all the text, accidentally pressed the DELETE key, because there is no undo function, had to re-enter). Edit text and versioning are the same, and anytime you need to roll back, whether it's one hours, a day, or a week, it makes your team work free and fast, and is confident about correcting bugs.
- Versioning allows multiple people to work on the same code, as long as they follow certain control principles. There is no longer a case where one person overwrites another person's edited code, causing the person's modification to be invalid.
- The version control system preserves the history of changes made in the past. If you encounter some surprising code, the version control system can easily find out who did it, what was changed, how long it was modified, and if so, why.
- The version control system also supports the release of multiple software versions while developing on the mainline. There is no need for the entire team to stop working when the software is released, and there is no need to freeze the code.
- Version control is also a project-level time machine, you can choose any time to accurately view the project at the time of the situation. This is useful for research and is the basis for reproducing a previously problematic release
(v) Reconstruction
Let's look at the concept of refactoring first:
Refactoring (refactor) is to change the structure within the software without changing the external behavior of the software, making it easier to read, easy to maintain, and easy to change.
One of the key prerequisites in refactoring is to "not change the external behavior of the software", which guarantees that we will not bring new bugs to the original system while reconstructing the original system, so as to ensure the security of the reconstruction. How to ensure that the software external behavior is not changed? The reconstructed code should be able to pass the unit test. How can you make it easier to read, easier to maintain, and easy to change? The design pattern gives the goal of refactoring.
VI) Practical projects
1. Project Introduction: Realize the Visualization and application of Gobang game.
- Code:
- Run:
(eight) Experimental summary
Learn from this experiment the raname of refactoring: How to modify a name. It is now quick and easy to modify the name of a program when it is accidentally misspelled, or if it needs to be modified to make it more meaningful. I think it is very practical and meaningful to write the code later. In the experiment, I also encountered a lot of problems, such as in the refactoring of the package function, because there is no time to select the age, name, ID to make the code encapsulation failed, but by consulting the students to finish the final problem is solved.
Experiment three Java Agile Development and XP