Extreme Programming Explained

XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork which allow us to accomplish things we previously could not even imagine. XP Includes:

* A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect.
* A body of practices proven useful in improving software development, The practices complement each other, amplifying their effects. The are chosen as expressions of the values.
* It's short development cycles, resulting in early, concrete, and continuing feedback.
* XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
* XP Creates and maintains a comprehensive suite of automated tests, which are run and rerun after every change to ensure a quality baseline. XP always keeps the system in deployable condition. Problems are not allowed to accumulate.
* XP insists that only the highest priority task are addressed.
* XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates.
 * XP  is like driving because: "Driving is not about getting the car going in the right direction. Driving is about constantly paying attention, making a little correction this way, a little correction that way." This is the paradigm for XP, Stay aware. Adapt. Change.
* XP embraces five values to guide development: communication, simplicity, feedback, courage, and respect.

   - Communication: When you encounter a problem, ask yourselves if the problem was caused by a lack of communication.
   - Simplicity: Is the most intensely intellectual of the XP values. 
   - Feedback: XP teams strive to generate as much feedback as they can handle as quickly as possible. They try to shorten the feedback cycle to minutes or hours instead of weeks or months. The sooner you know, the sooner you can adapt.
   - Courage: Is effective action in the face of fear. Sometimes courage manifest as a bias to action. If you know what the problem is,  do something about it. Sometimes courage manifest as patience. If you there is a problem but you don't know what it is, it takes courage to wait for the real problem to emerge distinctly.
   - Respect: If members of a team don't care about each other and what they are doing, XP won't work. If members of a team don't care about a project, nothing can save it. For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected. I am important and so are you. 

Principles:

Humanity. People develop software, that's the way because we need to pay attention to: Basic Safety, Accomplishment (Opportunity to contribute to their society), Belonging (The ability to identify with a group from which they receive validation and accountability and contribute to its shared goals), Growth (Opportunity to expand their skills and perspective). Intimacy (The ability to understand and be understood deeply by others).

Economics:  Solving the highest priority business need first maximizes the value of the project.

Mutual Benefit: I write automated tests that help me design and implement better today, I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road. 
I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter later.
Mutual benefit is the most important XP principle.

Diversity: In order to think of multiple ways to solve problems, and to implement solutions. Development teams need diversity. Two ideas about design present an opportunity, not a problem. The principle of diversity suggest that the programmers should work together on the problem and both opinions should be valuated.

Opportunity: Choosing to transform each problem into an opportunity for personal growth, deepening relationships, and improved software. 

Failure: If you're having trouble succeeding, fail. Don't know which of the three ways to implement a story? Try it all three ways. Even if they all fail, you'll certainly learn something valuable.

Quality: Projects don't go faster by accepting lower quality. The don't go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering  quality standards often results in later, less predictable delivery. 

Responsibility: cannot be assigned; it can only be accepted, if someone tries to give you responsibility, only you can decide if you are responsible or if you aren't.

Primary Practices.

Whole Team: People need a sense of "team":
* We belong.
* We are in this together.
* We support each other's work, growth, and learning.

Stories: When your team are doing estimation be sure that your story has all constraints in that case the team can split in task and do it in a informed decision way.

Pair Programming: 
* Keep each other on task.
* Brainstorm refinements to the system.
* Clarify ideas.
* Take initiative when their partner is stuck, thus lowering frustration.
* Hold each other accountable to the team's practices.
In addition: Rotate pairs frequently, personal hygiene and health are important issues when pairing.

Enjoy it: Amazon

Clean Code

Bad Code.

Programmers create problems for themselves when they write code solely to satisfy a compiler or interpreter.

Have you ever been significantly impeded by bad code? If you're a programmer if any experience then you've felt this impediment many times. Indeed, we have a name for it "wading".


Attitude.

Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's our job to defend the code with equal passion.

To drive this point home, what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply. Why? Because the doctor knows more than the patient about the risks of disease and infection. It would be unprofressional (never mind criminal) for the doctor to comply with the patient.

So too is unprofessional for programmers to bend to the will of managers who don't understand the risks of making messes.

LeBlanc's Law

Why we wrote bad code?, Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you didn't have time to do a good job; that you boss would be angry with you if you took the time to clean up your code. We've all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing. We've all said we'd go back and clean it up later. Of course, in those days we didn't know LeBlanc's law: Later equals never.

Kent Beck Rules
* Run ALL the tests
* Contains no duplication
* Express ALL the design ideas that are in the system
* Minimizes the number of entities (classes, methods, functions)

Functions
* Too many arguments
The ideal number of arguments in a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification and then shouldn't be used anyway.
* Flag arguments
Flag arguments are ugly. Passing a boolean into a function is a truly terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing.
* Dead functions
Methods that are never called should be discarded. Keeping dead code around is wasteful. Don't be afraid to delete the function, your source code control system still remembers it.
 
Commented-Out Code

Few practices are as odious as commenting-out code. Don't do this!.

// InputStream resultsStream = formatter.getResultStream();
// StreamReader reader = new StreamReader(resultsStream);
// response.setContent(reader.read(formatter.getByteCount()));

Others who see that commented-out code won't have the courage to delete it. They'll think it is there for a reason and is too important to delete. So commented-out code gathers like dregs at the bottom of a bad bottle of wine.

Quotes
* With functions we measured size by counting physical lines. With classes we use different measure. We count responsibilities.
* Wrapping particular implementations in more abstract methods, is also part to avoid duplication.
* When you're coding, you're an author and you have readers,   indeed the ratio of time spent reading vs writing is well over 10:1
* The fewer methods a class has, the better. The fewer variables a function knows about, the better. The fewer variables a class has, the better.
* Well-defined modules have very small interfaces that allow you to do a lot with a little. Concentrate on keeping interfaces very tight and very small. Help keep coupling low by limiting information.
* Before you consider yourself to be done with a function, make sure you understand how it works. Often the best way to gain this knowledge and understanding is to refactor the function into something that is so clean and expressive that it is obvious how it works.
* Boolean logic is hard enough to understand without having to see it in the context of an if or while statement. Extract functions that explain the intent of the conditional.

Tips
* Don't return null
* Don't pass null as parameter
* Take care about quality on Junit test code
* Follow SRP (Single Responsibility Principle)
* Maintain cohesion, when classes lose cohesion split them.
* If you do something a certain way, do all similar things in the same way.
* Consider polymorphism before using a switch or if/else statements.
* Avoid negative conditionals (Negatives are just a bit harder to understand that positives) So, when possible, conditionals should be expressed as positives. For example:

   if(buffer.shouldCompact())

is preferable to

  if(!buffer.shouldNotCompact())

Amazon Enjoy it.