When it comes to the key practices of XP, this chart comes out.

Look familiar? Isn’t there a lot of stuff that we actually covered in the last article? Yes, there may be some concepts that you are well aware of, but others that you have never heard of at all. Today, let’s study hard once and for all.

You see every link in this picture? The ones on the inside are about programming methods, the ones in the middle are about group practices, and the ones on the outside are about delivery and management, and we’re learning from the inside out.

Programming method (I) : pair programming

When it comes to pair programming, it’s probably interesting to anyone who writes code. But on second thought: two people with a computer, one to write and the other to see, this painting style is not a little ambiguous… Cough, if this is to write code also good, if see some other what bad things are really very easy to have an accident, after all, our code farmers taste is not easy to handle. Okay, let’s get to the point. Two people writing a piece of code feels like a huge waste. Yes, there are a lot of skeptics, and you don’t see many companies in The country, big or small, that actually do pair programming. Why is that? Mainly because this approach is not suitable for our now more and more volume of the domestic Internet industry, after all, we need to work overtime to achieve a person when two people, how can let two people to do one thing, it is obviously against the boss’s values ah.

However, there must be something to be said for agile practitioners to suggest this approach. Such as:

  • None of the decisions are made by one person

  • At least two people are familiar with every part of the system

  • It’s almost impossible for two people to ignore a test or other task

  • Changing the mix (that is, pairing different people) allows knowledge to spread better across the organization

  • Code is always being reviewed

  • Pair programming is more efficient than single programming

There are other advantages that are not to be listed. At first glance, it looks good, but as mentioned above, in China, there may be some extreme programming hobbyist companies that use it, but most companies, or 99% of companies you won’t see it.

Programming Approach (II) : Test Driven Development (TDD)

Presumably this is not strange to you code farmers, from the point of view of our code, is to write the test before writing the code, and then let our code pass the test before it is completed development. Typical frameworks are various unit testing frameworks, such as JUnit and PHPUnit. Well, to be honest, in all my years of development, I’ve never used one. Why is that? Again, it’s a little bit less efficient. However, the final product quality of this development method is really unspeakable.

Of course, there are also preconditions to use TDD. The first is the support of the leader and the team, the second is the perfect coding specification of the team, and the third is that the overall level should not be too inferior. Because if you write the test wrong in the first place, you can’t write the code right. In addition, abusing these unit tests can lead to an extreme pursuit of perfect 100% test coverage, which is also undesirable. Most of the time, from 60 to 80, we can get there with 100 points of effort, and from 80 to 95, we can get there with 500 points of effort. But to go from 95 to 99 might be 100,000 points of effort, and 99 to 100 might be 10 to the NTH power of effort. When we get into this situation, we often lose more than we gain.

What is the core of TDD to measure? In the unit test stage, the core algorithms need to be tested most, such as the calculation of discount amount in e-commerce projects and the calculation of rebate, etc. In code architecture, these tend to be the problems that the service layer solves, so our primary test target should be the service layer code.

From the hierarchical architecture, the control layer distributes requests, receives parameters, and does the test of effectiveness. Model layer to deal with data persistence, must pay attention to the security and integrity of the database data, do a good test in this aspect. The service layer, our common computing part, is the core of the system, and this is where unit testing really needs to be concerned. Therefore, consistent with the conclusion above, our most important test is the core algorithm or core logic of the service layer.

Of course, you can also write services in the control layer, or you can write services in the model layer, in short, find the key core processing business logic and algorithm areas, strengthen the test coverage of this area, not blindly based on the overall test coverage, this is an important aspect of TDD to better use.

Theory is theory, in fact, I do not have too much practical experience in this aspect, but I also feel that the test coverage can not explain everything, here I hope that experienced students can share relevant experience, you can leave links in the comments or add friends to reprint the article oh!

Programming method (3) : reconstruction

The word is even more familiar to people who write code, and many of them, when they move to a new company, the first suggestion is let’s refactor the code of the old project, because it was written too X. Of course, the idea is always good, but the reality is harsh, and true refactoring doesn’t mean we have to make every piece of code you like. True refactoring is iterative refactoring derived from agility. In both cases, we usually start refactoring a piece of code.

  1. Before implementing a feature: Try to change the existing code structure to make it easier to implement the new feature

  2. After the feature is implemented: Review the code you just wrote to see if you can further optimize it

An important concept in refactoring is Don’t Repect Your Self, also known as the DRY principle. From a development perspective, don’t let the same piece of code appear twice. In addition, refactoring is closely related to other elements of XP, such as collective ownership of code, making code available to everyone, and through pair programming, your refactoring can be found and pointed out. Test-driven development needs to be in place to ensure that your refactoring doesn’t cause problems. Simple design allows you to focus on the core of the refactoring process and write the simplest code that can implement the functionality.

By doing so, we have ensured that courage in XP is what it means to be brave enough to refactor.

Programming method (four) : simple design

Remember the simple principles at the heart of XP? Yes, design is important, but we should start with the simplest design and improve it iteratively and incrementally, rather than making a complex design at the beginning. For simplicity, it’s not that all design is small, it’s just that we need to make it as simple as possible, get it up and running as soon as possible, and continue to validate and refine it through constant release.

I heard a story before, which is also a joke between programmers. At the beginning of a company is a variety of sophisticated technologies, a variety of high-concurrency processing, the introduction of a lot of Ali, Tencent functional architecture practice. The result? The daily peak is a pitiful few hundred days. And how long did this project last? Hundreds of people, a year of development, and nothing.

Fortunately, most companies don’t do that anymore. Even many companies approach new projects in the form of MVP(minimum viable version). This is a good thing and worth advocating. So, what are some tips for simple design in XP?

  1. Write test code

  2. Keep each class responsible for one thing (single responsibility principle)

  3. Demeter’s Law (Least Knowledge Principle)

  4. DRY principle

  5. Simple design requires simple thinking, the courage to refactor, and the habit of refactoring regularly

Group practice 1: Continuous integration

Continuous integration is also a term we programmers hear a lot about, and many of us even use and practice continuous integration tools like Jenkins and Travis CI. But you know what? These tools were born out of XP’s influence.

What are the key points of continuous integration? Constantly compile and integrate code, and as soon as you commit your code to Git, the test environment starts unit testing, and if it doesn’t pass, it raises an exception, and if it does pass, it packages the code. This keeps the code in a releasable state at all times. Therefore, integration at any time, as often as possible, and as much automation of the integration and testing process as possible is the fundamental concept of continuous integration.

In a proprietary company, there will be a fixed time for code to go live, and a faster time may be once a week. The minimum standard that continuous integration is expected to achieve is daily integration, where the code is brought online on a daily basis. Of course, with these modern continuous integration tools, we can actually commit, integrate and go live.

Group practice ii: Metaphor

At first glance, the word metaphor seems mysterious. What does it mean? The official explanation is that “a metaphor is a linguistic device used to suggest similarities between things that are not literally similar”, which, in colloquial terms, abstracts key concepts such as design models and development patterns into metaphors. Just as the classic saying that you can explain a database to someone who doesn’t know anything about software development, I’m sure you’ll use a lot of metaphors as well. For example, a database is a bookstore, and we need to find the books we want from the shelves of the bookstore, and so on.

In XP, metaphors are used to enhance mutual understanding between the client and the programmer, to digest knowledge, and to guide design development. Specifically, it can help us:

  1. Seek consensus

  2. Create a shared vocabulary (a dictionary for our team to communicate with customers)

  3. An important tool for innovation (sometimes the right metaphor can inspire more)

  4. Describe the architecture (to make abstract concepts easier to understand)

conclusion

Is there much to cover today? That’s ok, because we have 13 key XP practices and an article to follow. If you haven’t noticed, XP practices are all about software development, and you can’t help it. Kent Back is a software guru himself. You know what? Martin Fowler, a pioneer in the practice of design patterns and a good friend of refactoring author Martin Fowler, also contributed much of the book’s content, and is the founder of XP and TDD (JUnit), to name a few. In the next article, we will continue to worship the work of the masters and continue our XP journey.

Reference Documents:

Textbook of a Training Institution

User Stories and Agile Methods

“Effectively Pass the PMI-ACP Exam (2nd Edition)”

Agile Project Management and PMI-ACP Test Taking Guide