20165212 Experiment 3 - Agile Development and XP Practice

20165212 Experiment 3 Agile Development and XP Practice

Experimental content

1. XP Basics

2. XP Core Practices

3. Related tools

Summary of experimental knowledge points

(1) Agile development and XP

• Software Engineering: The process of applying a systematic, orderly, and quantifiable approach to the development, operation, and maintenance of software
• Software engineering includes the following areas:
  • software requirements analysis
  • software design
  • software build
  • software test
  • Software maintenance
• Software development process: People have many techniques, practices, habits, and ideologies in the process of developing, operating, and maintaining software. Software engineering unifies these related technologies and processes into a system called "software development process"
• The purpose of the software development process: to improve the efficiency of software development, operation, and maintenance, and to improve software quality, user satisfaction, reliability, and software maintainability
• Common formula:
  • 软件工程=开发流程+工具
  • 软件=程序+软件工程And 软件企业=软件+商业模式(given by Mr. Zou Xin)
• Common development process:
  • RUP(Rational Unified Process)
  • PSP(Personal Software Process )
  • TSP(Team Software Process )
  • Agile Process
  • ……
• Agile Development: It is a human-centered, iterative, step-by-step development method
• Extreme programming (eXtreme Programming, XP ): is a new and fast software development method. The XP team uses on-site customers, ad hoc planning methods, and continuous testing to provide rapid feedback and comprehensive communication:
  • XP is a methodology developed with the goal of developing software that meets customer needs
  • XP is a practice-based software engineering process and thought
  • XP considers code quality more important than people generally think
  • XP is especially suitable for small responsible, self-motivated teams to develop software with uncertain or rapidly changing requirements
• XP软件开发是什么样的Expressed through the XP Criterion :
  • Communication: XP believes that communication among project members is the key to project success, and sees communication as the main driver of coordination and cooperation among projects.
  • Simple: XP assumes that the future cannot be reliably predicted, and it is economically unwise to think about it now, so instead of thinking too much about the future, focus on the immediate.
  • Feedback: XP considers the system itself and its code a reliable basis for reporting the progress and status of system development. The feedback of the system development status can be used as a means to determine the system development progress and decide the next development direction of the system.
  • Courage: Represents XP's view that people are the most important aspect of software development. In the development of a software product, people's participation runs through its entire life cycle. It is the courage of people to get rid of difficulties and let the team forget about the local optimum and achieve more important goals. It shows XP's basic trust attitude towards "people make projects succeed".
• The evidence for the successful use of a practice in an XP environment is XP的法则presented by including:
  • quick feedback
  • Assume simplicity
  • Incremental change
  • advocate for change
  • quality work
• The cornerstones of XP software development are XP的活动, including:
  • coding
  • test
  • listen
  • design

(2) Coding standard

• An important realization in writing code is that "programs are mostly meant for people to see", and programming standards make code easier to read and understand, and even guarantee fewer bugs in it.
• Programming standards include:
  • descriptive name
  • clear expression
  • Straightforward control flow
  • Readable code and comments
  • The importance of using certain rules and idioms consistently when pursuing these
• Typography in coding standards is a good example, although typography does not affect the functionality of a program, it can affect readability. The layout of the program pursues clarity and beauty, which is an important factor in the style of the program.
• General naming rules in Java:
  • to reflect their meaning
  • nouns for packages, classes, variables
  • method name with verb object
  • The package name is all lowercase, such as: io, awt
  • The first letter of the class name should be capitalized, such as: HelloWorldApp
  • The first letter of the variable name should be lowercase, such as: userName
  • The first letter of the method name should be lowercase: setName
  • ...

(3) Pair programming

Pair programming is an important practice in XP. In the pair programming model, a pair of programmers develop work side by side, equally and complementary. They sit side by side at a computer, face the same monitor, use the same keyboard, and work together with the same mouse. They analyze together, design together, write test cases together, code together, do unit testing together, do integration testing together, write documentation together, etc.

• There are two roles in pair programming:
  • The driver is the person who controls the keyboard input.
  • Navigator (Navigator) plays the role of navigating and reminding.
• How to pair program:
  • Driver: Write design documentation, do coding and unit testing and other XP development processes.
  • Navigator: Review the driver's documentation, the driver's execution of the development process such as coding; consider the coverage of unit tests; think about whether and how to refactor; help the driver to solve specific technical problems.
  • The pilot and navigator constantly rotate roles, do not work more than an hour continuously, and take a 15-minute break for every hour of work. The navigator has to control the time.
  • Actively participate. Any task is first and foremost the responsibility of two people, but also the responsibility of all. There is no "my code", "your code" or "his/her code", only "our code".
  • There is only a difference in level, there is no difference in level. The two are paired. Although everyone may have different levels of qualifications, both parties have equal decision-making rights in analysis, design or coding.
• When disagreements arise in pair programming, you should对事不对人

(4) Version Control

• code repository
• The benefits of version control:
  • Version control provides project-level undo functionality: nothing is finalized, and any errors must be easily rolled back. Suppose you are using the most complex word processing system in the world. It has all the functions imaginable except that it does not support the DELETE key. Imagine how careful and slow you are when typing, especially when you are nearing the end of a very large document, and you have to start all over again by accident (imagine you select all the text and accidentally press the DELETE key, because There is no undo function, you have to re-enter). Editing text is the same as version control, rollbacks are required at any time, whether it's an hour, a day, or a week, giving your team the freedom to work quickly and confidently to fix bugs.
  • Version control allows multiple people to work on the same code, as long as certain control principles are followed. There will never be a situation where one person overwrites another person's edits, rendering that person's changes invalid.
  • Version control systems keep a history of changes made in the past. If you come across some surprising code, a version control system makes it easy to find out who did it, what was changed, when, and if you're lucky, why.
  • The version control system also supports the simultaneous release of multiple software versions while being developed on the mainline. There is also no need for the entire team to stop work or freeze the code when the software is released.
  • Version control is also a project-level time machine, you can choose any time and see exactly what the project is like at that time. This is useful for research, and is the basis for reproducing a previous release with a problem.

(5) Refactoring

• Refactoring concept:

Refactoring is to change the internal structure of the software to make it easier to read, maintain and change without changing the external behavior of the software.

• A very key premise in refactoring is " not changing the external behavior of the software ", which ensures that we will not bring new bugs to the original system while refactoring the original system, so as to ensure the safety of refactoring.
  • How to ensure that the external behavior of the software is not changed: The refactored code must pass the unit test .
  • How to make it easier to read, easier to maintain, and easier to change : Design patterns give refactoring goals.
• Four motivations for modifying software:
  • Add new features
  • The original function has bugs
  • Improve the structure of the original program
  • Optimize the performance of legacy systems
• Where to refactor: Bad Smell - Duplicated Code
  • The simplest Duplicated Codeis [two methods in the same class contain the same expression (expression)]. At this time, all you need to do is to Extract Methodextract the repeated code, and then let both places call the extracted piece of code.
  • Another common case is [two sibling subclasses contain the same expression]. To avoid this, just use it for both classes Extract Method, and then use it for the extracted code Pull Up Method, pushing it into the superclass.
  • If the code is only similar, not exactly the same, then you have to use Extract Methoda method to separate the similar parts from the differences and form a single method. Then you may find that you may be able to apply Form Template Methoda Template Methoddesign pattern.
  • If there are methods that do the same thing with different algorithms, you can choose the clearer one and use Substitute Algorithmthe algorithm to replace the other method.
  • If two unrelated classes appear Duplicaded Code, you should consider using one of them Extract Class, distilling the duplicate code into a separate class, and then using the new class in the other class. However, it is also possible that the method in which the duplicated code is located should indeed belong to only one class, and another class can only call it, or the method may belong to a third class, and the other two classes should refer to this third class. You have to decide where the method is most appropriate and make sure it doesn't appear anywhere else once it's placed.
• A complete refactoring process:
  1. Check out code from the version control system codebase
  2. Read and understand code (including test code)
  3. find bad smell
  4. Refactoring
  5. Run all Unit Tests
  6. Check in code into the code base

Experimental results

Submit point one

Submit point two

Submit point three

Submit point four