This is why Technology’s 32nd original article

During the Spring Festival, I read two technology-related books: “The Code Clean Way” and “The Code Clean Way: The Professional Quality of Programmers” by master programmer Uncle Bob.

The Code Clean Way was published in 2010, and it’s mostly about technology-oriented “techniques.” The book is full of tips and rules for making code cleaner.

The Code Clean Way: A Professional Programmer was published in 2016, and its focus is on the art of technology. The book has less to do with code neatness and more to do with software developer professionalism. The book offers a lot of practical advice.

Clean code

Writing code is like writing articles. This is the argument that Uncle Bob promotes in his book.

Douban users have a comment about the book is still good, can be quoted:

I was impressed by Uncle Bob’s assertion that “writing code is like writing articles” and that “master programmers tell systems as stories, not as programs”. I had never heard of writing code as a story or article before. Uncle Bob is brilliant!

How do you write clean code?

The general principle is KISS (Keep It Simple Stupid) : Keep your code Simple and straightforward so that the reader can easily see the designer’s intent.

There are a number of methods and specifications in this book that you can follow to help you write cleaner code.

This is a good book. Four stars because it’s not as good at refactoring code as Refactoring: Improving The Design of Existing Code, as it is at writing code, or as good at designing code as Agile Software Development (Uncle Bob’s own last classic). In addition, the Chinese version of the price is high, the translation quality is also very mediocre.

Reading Notes:

Chapter 1 Clean Code

1. Clean code is focused, with every function, every class, and every module concentrating on one thing.

2. Clean code is straightforward and never hides the designer’s intentions.

3. Clean code should have unit tests and acceptance tests. It uses meaningful names, and the code expresses meaning through their literals.

4. Eliminate duplicate code and improve code expression.

Keep your code clean at all times.

Chapter two meaningful naming

1. Using proper names makes it easier to understand and modify the code.

2. Programming is inherently a social activity.

3. Try to write code that is easy to understand

Chapter III Functions

1. A function should only do one thing (highly cohesive) with no side effects.

2. Reading code from the top down is like reading a newspaper article.

Long, descriptive function names are better than long, descriptive comments.

4. By using exceptions instead of return error codes, the error handling code can be separated from the main path code and simplified.

5. Writing code is a lot like writing articles. Write what you want first, then polish: decompose functions, change names, eliminate duplication.

6, programming is actually a language design art, master programmers to program systems as a story. Use accurate, clear, expressive code to help you tell your story.

Chapter IV Notes

1. Don’t comment bad code —- rewrite it.

2. Put the effort into writing code that is clear and unambiguous, directly guaranteeing that you don’t need to write comments.

Chapter 5 Format

1. Code format is important. Code format is about communication, and communication is a top priority for professional developers.

2. Learn to code from newspaper formats.

Chapter 6 Objects and data structures

1. Objects hide data behind abstraction and provide only functions that manipulate the data. Data structures expose their data without providing meaningful functions.

2. The Law of Demeter: A module should not know The internal details of The objects it operates on.

Chapter 7 Error Handling

1. Use exceptions instead of returning error codes.

2, try-catch-finally, log error message.

3, do not return NULL, do not pass NULL. NULL Object mode, for example: collections.emptyList ();

Chapter ten classes

1. The top-down principle: Make the program read like a newspaper article.

2. Method can be protected for unit testing.

SRP: A class or module should have one and only one reason to change it. Class names should accurately describe their responsibilities. High cohesion.

4. Principle of opening and closing, principle of dependence inversion.

5. Variable names, method names, and class names are all means of adding comments to code.

Chapter 12 Iterative progress

1. Tightly coupled code makes it difficult to write unit tests.

2. Unit testing eliminates the fear that cleaning up code will break it.

3. It’s easy to write code that you can understand, and the main cost of a software project is long-term maintenance.

4. the code should clearly express the author’s intent; The test code can be documented by example.

Chapter 14 Progressive Improvement

1. Programming is a craft. To write clean code, you must first tolerate dirty code, then clean it up!

2. Writing good articles is a process of gradual improvement.

The professionalism of programmers

Uncle Bob tries to answer the following questions in His book, The Code Clean Way: A Professional Programmer:

1. What is a software professional?

2. How do software professionals behave?

3. How do software professionals handle conflict, tight deadlines, and unreasonable management?

4. When should software professionals say “No”? How do you say?

5. How software professionals cope with stress.

As you read the book, you can sense a kind of indefinable positivity to the above questions, along with some practical advice.

This attitude promotes integrity, a sense of honor, self-respect and pride, and the courage to accept the great responsibilities of being a craftsman and engineer.

This responsibility involves working hard and doing a good job; To be good at communication, can talk about things; Manage your time well and be comfortable with tough “risk-reward” decisions.

In addition to duty, there is a sense of divine mission. As an engineer, you know better than probably any manager. Knowing this also means you have a great responsibility to act boldly.

In view of the above problems, I must be incomplete in this article. After all, he is a book, and if I had condensed it into an article, it would have been a bit general.

I would like to share with you one of the points that IMPRESSED me a lot after reading this book, and one that I deeply agree with after years of development.

The author mentions the following points in section 1.4 of professional Ethics:

I don’t want to talk about the platitudes of learning, connecting, and collaborating. I’d like to focus on the two points I’ve flagged: knowing your area and knowing your business area.

I know your field. My field is programmer field. No, it’s too small. My field is the Internet field.

Over the last 50 years, there has been a plethora of ideas, practices, techniques, tools, and terminology in our field, and to be a professional developer you need to understand most of them, and to continue to expand that knowledge.

As a professional programmer, he must understand and update the technology in his field.

Knowing your area is knowing your food area.

As you all know, knowledge is abundant in this industry. We can never learn as fast as we can update our knowledge. Because of this, we need to keep learning while consolidating knowledge. Let yourself be eliminated as late as possible.

Why do we say that this industry is a youth industry?

I think it’s because as you get older and your social roles become more complex, your learning ability and energy will decline. At some point, without anyone telling you, you will feel that your enthusiasm for learning is failing to keep up with this wave of young people.

At this time, you need to look at their core competitiveness.

Everyone’s core competencies are different, but if you pull them up you’ll find that most of them are business related. This is where understanding the business domain becomes important.

Every professional software developer has an obligation to understand the business domain of the solution he or she is developing.

Everyone has different business fields. Take me for example, I have made payment, accounts and loans, and I think I belong to the Internet finance industry.

I believe there are many friends and I in the same industry.

So you’re in the field and you know what UnionPay is?

Why was the network born?

What is a large and small channel?

What is aggregate payment?

What is erqing?

Why is erqing being attacked?

Do you know how important payment licenses are for payment companies?

I know the sentence in no. 217 document of the People’s Bank of China: conduct a comprehensive inspection on the illegal activities of licensed institutions (banks, UnionPay, third-party payment institutions, and local clearing centers) providing payment and clearing services to unlicensed payment institutions. How big is the shock of this sentence for the entire payment industry?

.

These are the questions that come to mind as I write here. This has nothing to do with technology, but there are many more problems related to the field.

I want to express the same thing as in the book.

If you write a financial system, you should know something about the financial field. If you’re writing a travel application, you need to understand the travel industry.

You don’t necessarily need to be an expert in the field, but you still need to study hard and put in considerable effort to understand the business.

The worst, least professional thing to do is to simply write code that follows the rules without understanding the specification definitions for why those businesses need those.

This is a common problem faced by newcomers to the industry. They only care about technology, not business.

The Qiji Community has created an event to share what technologies in your industry or major have changed the most in the past decade and what developments you expect to see in the next decade.

This activity is really a combination of knowing your area and knowing your business area that I talked about above. I think any programmer with a few years of development experience should be able to write a few words and express their opinion. The viewpoint may be very simple, may not be correct, but it also has its own thinking in it.

My response was as follows:

In fact, I don’t think what I’m saying is an opinion. I’ve been in the industry for a few years, and I’ve seen and heard things firsthand.

Some extraordinary and magnificent things are changing all aspects of human life through the business field of Internet finance.

There’s another point in the book that I thought I should share: one of your least favorite things to hear as a leader or collaborator at work is “I’ll try, I’ll try…” In this case. A more responsible, or better, answer is: I’ll be at…. Before… I will finish this task by next Tuesday.

Finally, let’s share one more personal work tip. Friends who used to work with me will notice that I have bluetooth headphones hanging from my ears at all times. In fact, there is no music playing in the headphones. But when I’m doing more complex programming, I’m more productive with noise-canceling headphones without sound. Helps me focus more on what’s in front of me.

The downside of this is that you may come across as unapproachable and aloof. So usually still need more communication with colleagues oh.

All right. Thank you for reading, I insist on original, very welcome and thank you for your attention.

The above.

Welcome to pay attention to the public account [WHY Technology]. I’m going to share some technical stuff here, focusing on Java and being responsible for every line of code. Occasionally, I will talk about life, write a book review, film review. May you and I make progress together.