The Pragmatic Programmer

From Journeyman to Master

@rodolfoprr

O livro

What Makes a Pragmatic Programmer?

• Early adopter/fast adapter;
• Inquisitive;
• Critical thinker;
• Realistic;
• Jack of all trades.

#1 Care About Your Craft

#2 Think! About Your Work

Chapter 1

A Pragmatic Philosophy

The Cat Ate My Source Code

#3 Provide Options, Don't Make Lame Excuses

Software Entropy

#4 Don't Live with Broken Windows

Stone Soup and Boiled Frogs

#5 Be a Catalyst for Change

#6 Remember the Big Picture

Good-Enough Software

#7 Make Quality a Requirements Issue

Your Knowledge Portfolio

Building Your Portfolio

• Invest regularly;
• Diversify;
• Manage risk;
• Buy low, sell high;
• Review and rebalance.

Goals

• Learn at least one new language every year;
• Read a technical book each quarter;
• Read nontechnical books, too;
• Take classes;
• Participate in local user groups;
• Experiment with different environments;
• Stay current;
• Get wired.

#8 Critically Analyze What You Read and Hear

Communicate!

• Know What You Want to Say;
• Know Your Audience;
• Choose Your Moment;
• Choose a Style;
• Make It Look Good;
• Involve Your Audience;
• Be a Listener;
• Get Back to People.

#9 It's Both What You Say and the Way You Say It

Chapter 2

A Pragmatic Approach

The Evils of Duplication

#10 DRY - Don't Repeat Yourself

How Does Duplication Arise?

• Imposed duplication;
• Inadvertent duplication;
• Impatient duplication;
• Interdeveloper duplication.

#11 Make It Easy to Reuse

Orthogonality

#12 Eliminate Effects Between Unrelated Things

Reversibility

#13 There Are No Final Decisions

Prototypes and Post-it Notes

You can prototype

• Architecture;
• New functionality in an existing system;
• Structure or contents of external data;
• Third-party tools or components;
• Performance issue;
• User interface design.

#14 Prototype to Learn

What details can you ignore

• Correctness;
• Completeness;
• Robustness;
• Style.

Domain Languages

#15 Program Close to the Problem domain

Chapter 3

The Basic Tools

#16 Use the Power of Command Shells

WYSIWYG vs. WYSIAYG

#17 Use a Single Editor Well

#18 Always Use Source Code Control

Debugging

Psychology of Debugging

#19 Fix the Problem, Not the Blame

A Debugging Mindset

#20 Don't Panic

#21 Don't Assume It—Prove It

Debugging Checklist

• Is the problem being reported a direct result of the underlying bug, or merely a symptom?
• Is the bug really in the compiler? Is it in the OS? Or is it in your code?
• If you explained this problem in detail to a coworker, what would you say?
• If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
• Do the conditions that caused this bug exist anywhere else in the system?

Chapter 4

Pragmatic Paranoia

#22 You Can't Write Perfect Software

Did that hurt? It shouldn't. Accept it as an axiom of life. Embrace it. Celebrate it. Because perfect software doesn't exist. No one in the brief history of computing has ever written a piece of perfect software.

Design by Contract

#23 Design with Contracts

Liskov Substitution Principle

When to Use Exceptions

#24 Use Exceptions for Exceptional Problems

How to Balance Resources

#25 Finish What You Start

Chapter 5

Bend or Break

Decoupling and the Law of Demeter

#26 Minimize Coupling Between Modules

It's Just a View

#27 Separate Views from Models

Chapter 6

While You Are Coding

Programming by Coincidence

#28 Don't Program by Coincidence

How to Program Deliberately

• Always be aware of what you are doing;
• Don't code blindfolded;
• Proceed from a plan;
• Rely only on reliable things;
• Don't just test your code, but test your assumptions as well;
• Prioritize your effort;
• Don't be a slave to history.

Do you really think this code needs refactoring? It works good…

Refactoring

When Should You Refactor?

• Duplication;
• Nonorthogonal design;
• Outdated knowledge;
• Performance.

Real-World Complications

#29 Refactor Early, Refactor Often

Tips

• Don't try to refactor and add functionality at the same time;
• Make sure you have good tests before you begin refactoring;
• Take short, deliberate steps.

Code That's Easy to Test

#30 Design to Test

Test harnesses should include the following capabilities

• A standard way to specify setup and cleanup
• A method for selecting individual tests or all available tests;
• A means of analyzing output for expected (or unexpected) result;
• A standardized form of failure reporting.

#31 Test Your Software, or Your Users Will

Evil Wizards

#32 Don't Use Wizard Code You Don't Understand

Chapter 7

Before the Project

The Requirements Pit

#33 Don't Gather Requirements—Dig for Them

#34 Work with a User to Think Like a User

#35 Use a Project Glossary

Not Until You're Ready

#36 Listen to Nagging Doubts—Start When You're Ready

Good Judgment or Procrastination?

The Specification Trap

#37 Some Things Are Better Done than Described

Chapter 8

Pragmatic Projects

#38 Organize Around Functionality, Not Job Functions

Ruthless Testing

#39 Test Early. Test Often. Test Automatically

#40 Coding Ain't Done 'Til All the Tests Run

What to Test

• Unit testing;
• Integration testing;
• Validation and verification;
• Resource exhaustion, errors, and recovery;
• Performance testing;
• Usability testing.

Obrigado.