The Clean Coder by Robert C. Martin: Book Notes

Get Started. It's Free
or sign up with your email address
The Clean Coder by Robert C. Martin: Book Notes by Mind Map: The Clean Coder by Robert C. Martin: Book Notes

1. Development

1.1. Coding Professionalism

1.1.1. Your code must work Never write 3am code: It's crap even if it works, and that crap will be copied and pasted everywhere Never write code when distracted with personal thoughts Same analogy for driving, driving needs your focus, don't drive when distracted Learn how to manage your time with those problems. Spend some blocks of time throughout the day working on both to ease your mind and allow you to code Avoid the 'zone' True the zone will allow you to write more code however that's not an indicator your more productive The zone causes tunnel vision and causes you to lose sight of the big picture Pair programming makes it near impossible to enter the zone Avoid listening to music and headphones - this doesn't usually help you code, it helps you stay in the zone which is undesired The zone causes you to be rude to interruptions - extremely unprofessional to be rude Writers Block Pair Program Reduce debugging time to a minimum Do this with TDD Layers constantly retrying cases, surgeons re-opening up patients are unprofessional No False Delivery Worst unprofessionalism of all

1.1.2. Your code must solve the problem set for you by the customer Not the requirements given, it is up to you to negotiate with the customer the true solution to their problem

1.1.3. Your code needs to follow solid engineering principles

1.1.4. Your code must be readable by other programmers (clean code)

1.1.5. Help Help Others your responsibility to be available to help each other unprofessional to sequester yourself in a cubicle and refuse the queries of others If needed - set office hours Offer to help, don't wait to be asked Accept Help Mentor junior developers personally

1.2. Test Driven Development

1.2.1. It just works! Surgeons don't have to defend hand-washing Developers don't have to defend TDD

1.2.2. 3 Laws You are not allowed to write any production code until you have first written a failing unit test You are not allowed to write more of a unit test than is sufficient to fail -- and not compiling is failing. You are not allowed to write more production code that is sufficient to pass the currently failing unit test

1.2.3. Benefits Certainty tens of unit tests written a day makes me certain the code works when I wrote it and still works today Defect Injection Rate Proven to reduce the amount of bugs dramatically Courage Bad code is scary to fix without unit tests so often it doesn't get fixed When developers lose their fear of cleaning, they clean Documentation Each unit test defines how the system should be used Implicit, constantly updating, constantly added documentation Design Following the laws forces you to be able to test your code If tests are written after the code is written, it's written defensively and will force the implementation to work

1.2.4. TDD is NOT Religion Magic Formula Does not guarantee the benefits and you can still write bad code with it You can even write bad tests Always be practical or appropriate professionals should never follow a discipline when that discipline does more harm than good

1.3. Practicing

1.3.1. Kata a precise set of choreographed movements that stimulates one side of a combat Attempt to practice so much to reach perfection Practicing over and over how to solve a particular problem You already know the solution, but practicing the problem solving motions of TDD is the goal Examples The Bowling Game Integer Square Root Prime Factors Word Wrap

1.3.2. Wasa Two-man kata Ping-pong pair programming pattern When you both really know the kata Switch it up and add constraints in the tests speed & memory Make it competitive and fun

1.3.3. Randori free-form combat Wasa with more than 2 people People rotate through while the code is projected on the wall Can go in order, people can skip, move around, etc no specific rules just with more people

1.3.4. Broaden Your Experience Open Source projects Practice on your own time, its not your employers responsibility to keep you sharp

1.4. Acceptance Testing

1.4.1. Premature Precesion Business wants to know exactly what they are going to get, programmers want to know exactly what they are supposed to deliver Both want a precision that simply cannot be achieved Uncertainty principle requirements when implemented often aren't really what is desired in the end Estimation anxiety Late Ambiguity

1.4.2. Automated Always why?

1.4.3. Who writes them? Ideally - stakeholders and QA realistically - business analysts and QA analysts test happy paths QA tests unhappy paths If developers are forced to write them Should not be the same developer who implemented it

1.4.4. When to write? Should be written before the implementation begins Mid-sprint should have all the acceptance tests written and failing

1.4.5. Negotiate It is your professional responsibility to negotiate with whom has written the test and make a better test when necessary NEVER be passive-aggressive Example: X has to run in under 2 seconds Negotiate on average 2 seconds "not what requirements say" realistically though it's the only way run test 15 times and average is less than 2 seconds

1.4.6. NOT unit tests not redundant test things very differently

1.5. Testing Strategies

1.5.1. QA Should never find any bugs But probably still will Should be a part of the team

1.5.2. Test Automation Pyramid (coverage %) 5% Manual Exploratory NOT automated, nor scripted NOT written test plan of this kind of testing Some teams will have a specialist do this, others will declare a day or two of 'bug hunting' to bang on the system 10% System tests Ultimate integration tests across the entire system NOT test business rules written by system architects and technical leads 20% integration tests choreography tests - how well the assembly of components dances together NOT test business rules Written by system architects or lead designers of the system typically not executed as part of CI 50% component tests Acceptance tests of specific components Written by QA and business with assistance from development apart of continuous integration suite 100% unit tests written by programmers for programmers as close to 100%, generally in the 90s of true coverage Image

1.6. Collaboration

1.6.1. With Employers First responsibility is to meet the needs of your employer understand business goals collaborate with managers, business analysts, testers and other team members to understand understand the business and keep it afloat

1.6.2. With Programmers owned code Programmers should never own a piece of code Collective Ownership Break down all walls of code ownership and have the team own the code Pairing Many programmeres dislike the idea clearly the most efficient way to solve the problem Professionals Pair

1.6.3. Cerebellums Need to be close to team members need to hear frustrated mutters, serendipitous communication Need to communicate as a unit Some may work better alone for just themselves but that doesn't mean the team works better when you work alone And its unlikely you work better when you work alone

2. Behavioral Professionalism

2.1. Professionalism

2.1.1. Do no harm Don't lookout for yourself, lookout for the project and the customers We must not create bugs Impossible? QA Should Find Nothing! All code should be covered with automated unit tests Delivering function at the expense of structure is a fool's errand You must be able to make changes without exorbitant costs Merciless refactoring

2.1.2. Work Ethic 168 Hours per week 40 hours to solve your employers problems 20 hours on your career 56 hours for sleep 52 hours for everything else Minimal list Software Professional should be conversant with Design patterns Design principles Methods Disciplines Artificats Continuous Learning Practice Kata Mentoring Know your domain Read a couple books on the new topic Spend some time with the experts and try to understand their principles and values Identify with your employer

2.2. Saying No

2.2.1. Professionals speak truth to power, and have the courage to say no to their managers

2.2.2. Being a Team Player Telling the truth, committing to realistic estimates and not backing down is best for everyone Don't allow anyone to lie to try to make the team sound better, its not beneficial to anyone, the project, the company or the customer

2.2.3. Trying Admitting you can try harder implies you have not been trying hard It applies you and your team to a new commitment that no one really thinks is plausible Don't accept you need to try to meet a date that is not agreed upon by the team A professional is already trying, there is no magic pixie dust to make us work better on demand Say no to trying Response: I could try to levitate, but I promise you I won't I could try to change lead in to gold Don't stop by washing your hands and saying no If your boss is not taking 'no' seriously, make it clear his/her boss needs to be told the truth, or you will tell them

2.3. Saying Yes

2.3.1. Language of Commitment Making a Commitment Say you'll do it Mean it Actually do it Most communicated commitments are never real commitments "Yeah, we really need to get some new routers" Ask a team members to run tests -> "Sure. I hope to get to it by the end of the day" Management to the team -> "We have to move faster" Recognizing Lack of Commitment Signs of non commitment How to Commit "I will... by..." Bad Excuses Don't allow vagueness

2.4. Time Management

2.4.1. Meetings Truths Necessary Huge Time Wasters ~$200/hr/attendee Declining need to use your time wisely don't accept meetings unless it is a meeting for which your participation is immediately and significantly necessary to the job your doing now Your management should help keep you out of unnecessary meetings Leaving When the meeting gets boring, leave remaining in a meeting that has become a waste of time for you and you can no longer significantly contribute is unprofessional Have an Agenda and a Goal When invited, try to get the details of agenda and how much time is alloted for them When meeting gets side tracked ask the new topic be tabled and the agenda be followed

2.4.2. Arguments/Disagreements Data is the best way to argue, not relentless arguing Run experiments or do some simulation or modeling Sometimes flipping a coin is best If one path works out great, otherwise you can go down the other path Pick a time frame in which to decide if path's need to change Passive aggressive behavior is unprofessional 'This is how he wants it so this is how he will get it' If an argument must truly be settled, ask each of the arguers to present their case to the team in 5 minutes have the team vote

2.4.3. Focus-Mana Good nights sleep Moderate caffeine Recharging long walk conversation w/ friends meditate power nap listen to podcast Muscle focus bike riding carpentry building models gardening

2.4.4. Pomodoro Technique 25 minute timer politely decline all interruptions to get back to them within 25 min

2.4.5. Avoidance Priority Inversion Convincing yourself something else is more important to avoid doing the real work Unprofessional - Don't do!

2.4.6. Blind Alleys technical pathways that will lead no where The Rule of Holes: When you are in one, stop digging

2.5. Estimation

2.5.1. What Is an Estimate? Business sees them as Commitment Commitment Developers sees them as Guesses Estimate A Guess no commitment is implied Missing an estimate is not dishonorable An Estimate is a probability distribution

2.5.2. Program Evaluation and Review Technique PERT Trivariate analysis Expected duration Standard deviation Example Sequence Calculations

2.5.3. Wideband Delphi Team of people assemble, discuss a task, estimate the task, and iterate the discussion and estimation until they reach agreement Flying Fingers Planning Poker Affinity Estimation Trivariate Estimates

2.5.4. Law of large numbers break up tasks into smaller tasks and estimate them independently

2.6. Pressure

2.6.1. analogy Don't want your surgeon to stop best practices while under 'dead'lines

2.6.2. Avoid Pressures Commitments avoid committing to deadlines we can't meet help the business meet goals set by others but don't take ownership of the commitment Stay Clean "quick and dirty" is an oxymoron Crisis Discipline How you behave in crisis shows what you truly believe in Choose the methods you feel comfortable following in a crisis, then follow them all the time.

2.6.3. Handling Pressure Don't Panic Don't stay up all night, sit and frett, or rush, none of these things will help solve the problems Slow down and think the problem through Communicate Let your team and superiors know you are in trouble Discuss the best plans to get out of trouble, ask for their input Avoid creating surprises for anyone Rely on your disciplines TDD more Refactor harder Get Help Pair Program!

3. Management / Mentorship

3.1. Teams & Projects

3.1.1. Does it Blend? No such thing as a half of person Gelled Team takes time for a team to form Magical about a gelled team Which came first, Team or the Project? Team should not be formed around availability to work on a project Team should be first class decesion

3.1.2. Teams are harder to build than projects

3.2. Mentoring

3.2.1. Manuals Good books, manuals, api's are great mentors that can reach lots of people

3.2.2. Working with someone learning how they work, their tricks, the best that they know of how to do things

3.2.3. Hard Knocks learning everything on your own most developers progress this way very slow, very hard, not fun

3.2.4. Apprenticeship Masters 10+ years of experience lead of multiple projects coordinate multiple teams Maintain technical role by reading, studying, practicing, doing and teaching Journeymen Trained, competent and energetic Learn how to work well in teams and become team leaders Knowledgeable about current technology but typically lack experience w/ many diverse systems Teachers Apprentices/Interns Graduates start here Closely supervised by journeymen Need intense pair programing Ought to last a year

3.2.5. Craftsmanship definition someone who works quickly, but without rushing, who provides reasonoable estimates and meets commitments knows when to say no, but tries hard to say yes a professional Convincing People can't convince people to be crafstmen can't convince them to accept craftmanship Acceptance is not so much rational as much emotional Make craftsmanship observable

3.3. Tooling

3.3.1. What Bob Martin Uses Source Control Open Source tools are usually your best option Enterprise controls usually suck 2008 switched to GIT IDE VI EMACS Eclipse/IntelliJ Issue Tracking Start small, grow as needed Bob is using Pivotal Tracker Continuous Builds Jenkins If the build fails, stop the presses and resolve the issue Unit Testing Tools JUnit RSPEC foro Ruby NUnit for .Net Midje for Clojure CppUTest for C(++) Component Testing Tools FitNesse (written by Bob) Others UML/MDA Not worth it Assumes the problem is code/design No great diagramming language today that solves real problems