I’ve learned a lot from Uncle Bob’s Book The Code Clean Way, which explains how to write high-quality code from the smallest details of coding. Uncle Bob has written a book the programmer’s professional quality, the book is not in-depth knowledge of programming details, but from the Angle of the programmers work described what behavior is not professional, which could lead to project delay, which can lead to low efficiency and so on, which also has a lot of very good professional advice.

Improve professional quality, make oneself become a professional programmer, this is not a simple matter, technical ability, communication skills, work attitude, and so on are constituted a staff professional factor evaluation, the lack of any one could make us less professional, if we can apply the theoretical knowledge in the book with to work, It can be said that it will be great for our career.

I’ve summarized some of the key points in the book so that I can often go back and think about how I’ve combined theory and practice and how I could have done it better. Bacon, in On Reading, says that some books may be read by deputy, and a summary of his notes is enough; but this should be confined to the less important books, or a book will become, like distilled water, tasteless. The summary below, like distilled water, doesn’t sound like much to read, but some of the ideas are thought-provoking and hopefully helpful.

Chapter 1 – Professionalism

  1. Professionalism means taking responsibility

  2. Do no harm

    The error rate cannot be zero without destroying software functions, but it is the responsibility of professional programmers to make it wirelessly close to zero; It is extremely unprofessional to send out code that you know is flawed without QA finding any problems. Remember that any code you don’t know is flawed in some way, QA is not a bug catcher. Automated QA — Unit testing and acceptance testing; Don’t break structure, refactor ruthlessly, and stick to code design principles.

  3. The professional ethics

    Work time to solve your employer’s problems, not your own; Know the field of work; Keep learning.

  4. Practice – Software development skills and productivity can also be improved with practice by consistently repeating simple exercises called “kata.” Kata takes the form of a simple programming problem to be solved. The goal is not to find a solution, but to train your fingers and brain.

  5. cooperation

    Program together, practice together, design together, plan together.

  6. Coaching — teaching and learning.

  7. Understand the business domain

  8. Align with the employer and put yourself in the employer’s shoes.

  9. humility

    Confident in your abilities and therefore willing to take safe risks; Be aware of your ego.

Chapter 2 – Saying No

“Yes is yes, no is no. Don’t say try.”

  1. Against the role

    Master communication skills. Don’t say “try and see.” Communication should be clear, and stand your ground when there may be a risk.

  2. High stakes moment

    It’s the high-stakes moments when the need to say “no” is greatest, sending the clearest message to the higher-ups.

  3. Be a team player

    A true team player makes it clear what can be done and what can’t, based on his best abilities.

  4. The cost of saying yes

    In the rush to finish, certain sacrifices must be made, such as code quality.

Others: Sometimes, providing too much detail just invites more micromanagement

Chapter 3 – Saying Yes

  1. Commitment to language

    Verbally. Heart seriously. Do it.

  2. Recognize the signs of a lack of commitment

    Words like “need/should,” “hope/wish,” and “let’s” are likely signs of a lack of commitment

  3. What does a real commitment sound like

    The key is that you have a clear factual statement about what you are going to do and a clear deadline/time frame for completion.

  4. Keeping your promises will make you a conscientious developer

  5. When professionals answer in the affirmative, they use promise language to ensure that the promise is clearly understood.

Chapter 4 – Coding

  1. To prepare

    The code should work, solve problems, integrate with existing systems, and be highly readable.

  2. Make sure sleep, health, and lifestyle adjustments are optimized so that you can focus on your work and produce great code.

  3. Flow area

    This is the kind of hyper-focus that you get into when you code, but it narrates into a narrow state of vision, which makes it possible to write code very efficiently, but it also has the downside of narrate, where you may not be able to assess the global dimension of your code.

  4. Interrupt, block

    Interruption interrupts thinking, and blocking is a state of not being able to think. Pair programming can surface these problems in some ways. The companion can recover the interrupted thought after being interrupted, and the companion can reactivate your thought when you are blocked.

  5. Creative input

    Reading widely and learning all kinds of knowledge can activate one’s creativity and increase the number of opportunities for inspiration.

  6. Keep the rhythm

    Instead of being stuck in a problem solver, taking a break from the problem can help your brain search for solutions in a different and more creative way.

  7. Schedule delays

    Measure progress against targets periodically, using three timelines that take into account multiple factors: optimistic projections, nominal projections, and pessimistic projections.

  8. Don’t give in when you can’t get things done. Don’t give in when you can’t get things done. Don’t give in when you can’t get things done.

  9. Define “done”

    Completion is not the submission of finished code to source control. Teams should have a clear definition of “done.” Generally speaking, a development task is not complete until the code has fully passed the acceptance tests.

Chapter 5 – Test-driven Development

  1. The three laws of TDD

    Don’t write production code until you’ve written failed unit tests;

    If a unit test fails, no more unit test code is written;

    Production code is just enough to pass failed unit tests, don’t write too much.

  2. The advantage of TDD

    Deterministic — Testing gives you more confidence that the code works

    Reduce defect injection rate

  3. The courage to reimagine

    Having a reliable set of tests completely eliminates the fear of changing your code.

  4. The document

    Following the three laws of TDD, each unit test written is an example and is the best underlying documentation.

  5. design

    To write tests, you must find ways to decouple functions from other functions;

    Tests written after the fact are just defensive, whereas tests written now are offensive, and the author of the tests written after the fact is already constrained by the existing code.

  6. The limitations of TDD

    Even with comprehensive testing, it is possible to produce bad code because the test code can be written badly, so it should be treated as if it were production code.

Chapter 6 – Practice

To sum up: The only way to do anything fast is to practice, repeat the coding process, and make quick decisions, so that your brain can safely think of higher-level problems.

Chapter 7 – Acceptance testing

  1. Acceptance tests are defined as tests written jointly by the business and the developer to determine that requirements have been completed.

  2. automation

    Acceptance testing should be automated, which can save unnecessary costs.

  3. Continuous integration

    Make sure that unit tests and acceptance tests run every day in a continuous integration system.

It is important to keep continuous integration systems running, and integration failures should be dealt with immediately.

Chapter 8 – Testing strategies

  1. Business people write happy-Pathtests for normal paths, while QA writes tests for corner, boundary and unhappy-path.

  2. Automated test pyramid

    Use test-driven development to generate unit tests;

    Acceptance tests define system requirements;

    Continuous integration ensures a steady increase in quality;

    System testing to ensure correct system construction;

    Human exploratory testing ensures that it performs well under human control, while being creative in finding as many “oddities” as possible.

Chapter 9 – Time Management

  1. Truth about meetings: They are necessary; The meeting wasted a great deal of time.
  2. Choose carefully which meetings you attend and politely decline when necessary.
  3. Avoid wasting attention points
  4. Avoid priority confusion

Chapter 10 – Estimation

  1. Different people have different opinions about estimates

    A lot of times, there’s a big difference between what the business side thinks is a promise and what the developer thinks is a guess.

  2. An estimate is a guess, it is not a number, the estimated result is a probability distribution.

Chapter 11 – Pressure

  1. The best way to stay calm under pressure is to avoid situations that lead to stress, such as making commitments.

  2. Throwaway code that is “fast and messy” is an oxymoron. Messy leads to slowness, and stress can be avoided by keeping the system, code, and design as clean as possible.

  3. Discipline in crisis

    If your discipline is the best way to do your job, stick to it, even in a crisis.

    If you give up ON TDD in a crisis, you don’t really believe TDD is helpful.

  4. To cope with stress

    Don’t panic; Maintain communication; Rely on discipline principles; Ask for help.

Chapter 12 – Collaboration

  1. Programmers and People

    We didn’t choose to be programmers because we liked working with people. That’s the average of the group, and we, the programmers, still enjoy the most deadpan meditation, lost in problem solving.

  2. Programmers and programmers

    The worst symptom of a dysfunctional community is that each programmer builds a wall around his or her own code and refuses to let other programmers have access to it. This is a “perfect recipe” for disaster.

  3. pairing

    Working in pairs is the best way to share knowledge, and the best way to review code, and systems should not contain code that has not been reviewed by other programmers.

Maybe we didn’t do it because we could work with people through programming, but unfortunately programming means working with people.

Chapter 13 – Teams and Projects

  1. Only by overcoming individual differences, tacit cooperation and mutual trust can a truly cohesive team be formed. Of course, this needs a process of “fermentation”.
  2. Professional development organizations assign projects to cohesive teams rather than building teams around them.

Now that you have seen here, don’t stop to click a like, star, github, no advertising, make a friend 🤝.