clean code读书笔记

Pressure makes diamonds.
  No one in your life will teach you more than your children will.
  Shippin without testing the routine had been irresponsible.
  What harm can a software developer do? From a purely software point of view, he or she can do harm to both the function and structure of the software. We'll explore how to avoid doing just that.
  TDD: Test Driven Development.
  What is dangerous is allowing the software to remain static.
  Your career is your responsibility.
  You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.
  Those who cannot remember the past are condemned to repeat it.
  The best way to learn is to teach, so the benefit of teaching is strongly in favor of the teacher.
  Your employer's problems are your problems.
  So when a professional finds himself the butt of a joke, he'll be the first to laugh.
  Do; or do not. Theare is no trying.
  Professionals speak truth to power. Professionals have the courage to say no to their managers.
  Slaves are not allowed to say no. Laborers may be hesitant to say no. But professionals are expected to say no.
  You seem hesitant. Are you sure you can get it down tommorrow?
  You could work overtime.
  I am not asking for the impossible.
  You'll find we tend to be very busy not taking responsibility for things.
  If you don't tell anyone about the potential problem as soon as possible, you're not giving anyone a chance to help you through on your commitment.
  I'm sorry if that messes up your schedule, but it's just the reality we're faced with.
  Professionals are not required to say yes to everything that is asked of them. However, they should work hard to find creative ways to make "yes" possible. When professionals say yes, they use the language of commitment so that there is no doubt about what they've promised.
  Working while distracted creates waste. If you are tied or distracted, do not code. You'll wind up redoing what you did. Instead, find a way to eliminate the distractions and settel your mind.
  Dedication and professonalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so than you can put in eight good hours per day.
  Software is a marathon, not a sprint.
  There is no way to rush.
  Overtime will certainly fail if it goes on for more than two or three weeks. If your boss cannot articulate what he's going to do if the overtime effort fails, then you should not agree to work overtime.
  The three laws of TDD
  1: You are not allowed to write any production code until you first written a failing unit test.
  2: You are not allowed to write more of a unit test than is sufficient to fail and not compiling is failing.
  3: You are not allowed to write more production code that is sufficient to pass the currently failing unit test.
  The tests you write after the fact are defense. The tests you write first are offense. After-the-fact tests are written by someone who is already vested in the code and already knows how the problem was solved. There's just no way those tests can be anywhere near as incisive as tests written first.
  All professionals practice their art by engaging in skill-sharpening exercises.
  The role of the professional developer is a communications role as well as a development role.
  The solution to premature precision is to defer precision as long as possible. Professional developers don't flesh out a requirement until they are just about to develop it.
  Acceptance tests as tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.
  The purpose of acceptance tests is communicaton, clarity, and precision.
  In general, the business writes the happy-path tests, WhileQA writes the corner, boundary, and unhappy-path tess.
  The person who inviting you to meeting is not responsible for managing your time. Olny you can do that.
  When the meeting gets boring, leave.
  The important thing to realize is that remaining in a meeting that has become a waste of time for you, and to which you can no longer significantly contribute, is unprofessional.
  Any argument that can't be settled in five minutes can't be settled by arguing.
  "This is the way they wanted it, and now they are going to get what they are wanted." This is probably the worst kind of unprofessional behavior there is. Never, ever do this. If you agree, then you must engage. Sometimes the best alternative is to simply flip a coin to choose one of the two pasths in question.
  The rule of hole: when you are in one, stop digging.
  Estimation is one of the simplest, yet most frieghtening activities that software professionals face.
  The reason we make estimates is because we don't know how long something will take.
  The best way to stay calm under pressure is to avoid the situation that cause pressure.
  Professionals will always help the business find a way to achive its goals. But professionals do no necessarily accept commitments made for them by the business.
  Sleepless nights won't help you get done any faster.
  Rushing will only drive you deeper into the hole.
  Nothing makes people more angry and less rational than surprises. Surprises multiply the pressure by ten.
  It is unprofessonal to be a loner or a recluse on a team.
  It's good to be passionate about what you do. But it's also good to keep your eye on the goals of the people who pay you.
  The first responsibility of the professional programmer is to meet the needs of his or her employer.
  Professional developers do not prevent others from working in the code. They do not build walls of owership around code.
  Programming is all about working with people.
  Professional development organizations allocate projects to existing gelled teams, they don't form teams around projects.
  I had learned long ago that it is better to ask forgiveness than permission.