Extreme Programming Explained: Embrace Change by Kent Beck

Podsumowanie

Ostatni raz czytałem: 03.2015

Dzięki tej książce poznałem znaczenie wielu najbardziej przydatnych praktyk i zasad, takich jak “Pair Programming”, “Collective Code Ownership”, czy “Assume Simplicity”, które pozwalają na wydajną pracę w zespole.

Jeśli ktoś kiedyś pozwoliłby mi wybrać konkretną metodykę Agile, w której chce pracować, to byłby to Extreme Programming. To dlatego, że jest bardzo nastawiona na programistów. XP opisuje najwięcej dobrych praktyk tworzenia oprogramowania, ze wszystkich metodyk z jakimi się spotkałem.

Poniżej znajdują się notatki, z tematów, które najmocniej ze mną zarezonowały w czasie, gdy to czytałem. Zdecydowanie do przeczytania jeszcze raz.

Dodatkowe linki:

When solving problems:

assume simplicity - treat every problem as if it can be solved with ridiculous simplicity, add complexity in the future where you need it;
keep the change small - in everything
quality work
teach learning
play to win, do not play to not loose
accepted responsibility - do what you feel like doing, as a team member you know what is worth doing for the team/project

4 values

Communication
Simplicity
Feedback
Courage

Komentarz: Obecnie w XP jest 5 wartości. Piątą jest “Respect”.

Wychodzi na to, że czytałem wcześniejszą wersję książki, gdzie było ich 4.

4 basic activities:

You code because if you don’t code, you haven’t done anything
You test because if you don’t test, you don’t know when you are done coding
You listen because if you don’t listen, you don’t know what to code or what to test
You design so you can keep coding and testing and listening indefinitely

Collective code ownership

Collective ownership tends to prevent complex code from entering the system in the first place. If you know that someone else will soon be looking at what you are writing at the moment, you will think twice before putting in a complexity you can’t immediately justify.

Design strategy

As programmers, we get in the habit of anticipating problems. When they appear later, we are happy. When they don’t appear, we don’t notice. So the design strategy will have to go sideways of this “guessing at the future” behavior. Fortunately, most folks can unlearn the habit of “borrowing trouble”. Unfortunately, the smarter you are, the harder it will be to unlearn.

If you know exactly what is going to happen, and you know exactly how to solve it, it is generally better to add what you need now, and add what you need later, too.

What is the simplest solution?

System communicates everything it needs
There is no duplication

Testing strategy

You should test things that might break.

Best quotes

“Really smart programmers sometimes have a hard time with XP. Sometimes the smart people have the hardest time trading the “Guess Right” game for close communication.”

“It is hard to break emotional walls. The smooth running of an XP project relies on the smooth expression of emotions. If someone is getting frustrated or angry and not talking about it, it won’t be long before the team starts to underperform. We have learned to separate our emotional lives and our business lives, but the team can’t function effectively if communication is not kept following, fears acknowledged, anger discharged, joy shared.”

“It’s hard to do simple things. It seems crazy, but sometimes it is easier to do something more complicated than do something simple. This is particularly true when you have been successful doing the complicated thing in the past. Learning to see the world in the simplest possible terms is a skill and a challenge. The challenge is that you may have to change your value system. Instead of being impressed when someone (like you, for instance) gets something complicated to work, you have to learn to be dissatisfied with complexity, not to rest until you can’t imagine anything simpler working.”

”(…) it is much more important to have a handful of tools that you know when not to use, than to know everything about everything and risk using too much solution.”

“On the surface, being an XP programmer looks a lot like being a programmer within other software development disciplines. You spend your time working with programs, making them bigger, simpler, faster. Beneath the surface, however, the focus is quite different. Your job isn’t over when the computer understands what to do. Your first value is communication with other people. If the program runs, but there is some vital component of communication left to be done, you aren’t done. You write tests that demonstrate some vital aspect of the software. You break the program into more smaller pieces, or merge pieces that are too small into larger, more coherent pieces. You find a system of names that more accurately reflects your intent.”

“The most difficult thing I have found about being a coach is that you work best when you work indirectly. If you see a mistake in the design, first you have to decide whether it is important enough that you should intervene at all. Every time you guide the team, you make them that much less self-reliant. Too much steering and they lose the ability to work without you, resulting in lowered productivity, lowered quality, and lowered morale. So, first you have to decide whether the problem you see is enough of a problem that you need to accept the risk of intervening.”

“If you decide you really do know better than the team, then you have to make your point as unobtrusively as possible. For example, it is far better to suggest a test case that can only be implemented cleanly by fixing the design, than it is to just go and fix the design yourself. But it is a skill to not directly say what you see, but to say it in such a way that the team sees it, too.""