This article qualifies as an advertisement post. I say it as an advertisement because this article is from the translation preface of the book I translated last year, Understanding Software, and it is a simplification and improvement on the previous edition; I use the word reluctantly because IF you buy the book because you read it, I don’t get any commission. For the translator, my income comes from a fixed payment based on the number of words translated, not the amount of money related to sales.

However, I sincerely recommend that you finish reading this article and even the book. The reason for my recommendation is the same as the motivation for my translation, because it perfectly distills the experience I have accumulated over a long period of time, some of which are evil and cruel. Although the book is based on the author’s own experience, it also makes me feel empathy. I’m sure it will inspire you.

What’s it about?

Before I started translating, I already had a plan for this preface. It was very simple: first talk about why I translated the book, then briefly describe the contents of the book, and finally highlight some valuable chapters. But as I worked on my translation (or reread it), I realized that it was impossible to do because the book covered so much: debugging code, testing strategies, teamwork, performance improvement, and even people.

You must be wondering at this point, so what is the point of the whole book? Isn’t there a unifying theme that justifies their binding?

Yes, the whole book can be summed up in two words – principles. The whole book covers all the various principles you might apply to your development. The goal of this book is to help you become a better developer, as the author begins his introduction and first article. Hopefully, some of the lessons the authors have learned from their past work will help you avoid missteps along the way.

Talk about the principle of

I’ve seen two extremes of how to approach knowledge in the programming world: people who only care about results, who only care about “writing code” and have no idea about “writing good code”; The second group knows all about architectural design and clean code, but can’t translate the methodology into a solution to the actual problems you’re encountering in your code right now.

Years of working experience in Internet companies make me more accustomed to view problems from the perspective of the first type of people. After all, this is determined by the nature of the industry. It is only the race and rapid expansion that matter, and competition does not allow you to have time to think. If you take industry and company considerations out of the equation and look at coding, my biggest puzzle as a programmer is why the code base I handle in every company is so hard to maintain; Why do people always write functions that are 500 lines of code and components that are 1000 lines of code? Why every iteration always ends with overtime, with r&d, test, and product managers groaning; Why do problems keep happening year after year and nobody wants to do anything about it?

DRY — Don’t repeat yourself.

Most programmers love to learn about new technologies and frameworks, and it’s understandable that they have a visceral reverence for reading source code. New technology has the potential to do more with less work and, in a utilitarian sense, add a great touch to our resumes. But just as important as the syntax of the technology itself is the thinking behind it and why it has evolved so far. If you think back, the quality of your tools has nothing to do with the quality of your code. From the era of naked JavaScript, to BackboneJS**, to ** React**, do you see more and more people who can write good code in the team? 支那

Different industries have different requirements for software quality. Apart from whether your industry has the will and resources to address these issues, if so, where should you look for solutions?

In my opinion, the experience left by our predecessors is the most valuable wealth for us to learn from, no matter it is from the traditional software industry or Internet companies. Most of the problems that we’re facing today, that the traditional software industry was facing 10 or even 20 years ago, I can’t say how far they’ve come in solving these problems, but every step they’ve taken has had a profound impact on future generations. There’s nothing mysterious about these lessons, though. Some of the classics are the kinds of programming principles and development patterns you’ve been exposed to, while other, more practical ones are scattered across different channels of writing and dictation, such as this book.

But the daunting part is that most of the principles sound too abstract, even counterintuitive.

I understand the frustration of abstractions. You’ve heard of abstractions by names like maintainability, extensibility, readability, KISS, YANGNI, etc. But what is the measure of readability? How should KISS be implemented in code?

Counterintuitive practices abound. If I told you that your overall development time would go down, not up, in both the short and long run, assuming that you could do some refactoring of your code before you actually developed it. Do you want to believe that? Do you dare to experiment at work?

Unfortunately, there is a complex body of knowledge behind some of these principles, and even if I were to use a mind map to list the concepts behind them, your mind would probably still feel the same. Because many of these principles need to be understood if you have experienced similar code, so is the meaning of chakra.

In his “The Principles of OOD” column, Uncle Bob Martin discusses The characteristics of Bad Design:

  • Sampler code is difficult to change because changes affect so many places
  • Fragility: When you make a change, you can easily damage something in your system that you didn’t expect
  • Immobility: Code is difficult to reuse because it is coupled to functionality in the current system

This series of brief descriptions links the principles involved in programming to the specific symptoms in the code.

Was it difficult to learn? It’s easy to understand them, but it’s another thing to use them in your programming. After all, improving your programming skills isn’t about rote memorization, it’s about deliberate practice. However hard it is, it is easier than going back and trying to undo the damage done by the code.

What if they’re wrong?

I can’t deny the possibility. But most of the time — and I mean most of the time, technology decisions are autocratic. If I have a lot of experience in this area, if I’ve solved enough problems, even if I’ve just been on the project long enough, then I can come up with a better solution to any new problem.

A lot of times these principles aren’t necessarily wrong, they’re counterintuitive enough to make you sound like they’re wrong. Take comments, for example. Many programmers think of comments as a panacea for the stench of code, but

  • Martin Fowler in Refactoring tells you not to annotate anything
  • Uncle Bob Martin tells you in The Art of Clean Code not to comment
  • Jeff Atwood at the CodingHorror tech blog tells you not to comment

So why keep writing comments?

If you’re still skeptical, you have a few options:

The first step is to understand the motivation behind these suggestions. There are reasons behind each of these proposals.” “Start with Why” helps you understand them and magically shifts you from opposing to aligned.

But some of the knowledge may have been passed down by word of mouth that can’t be traced back, or simply left over from the practice of the team. What you need is a “Take a leap of faith.” This means that you need to believe unconditionally at this point and follow it, and then test it later.

Or you have a choice, which is to ignore it, but at the risk of incurring untold consequences.

If you still doubt the principles in this book, I have to mention another reason why I translated this book: much of it coincides with my experience in the field.

Let me give you an example. As I’ve moved from an indie developer’s perspective to a team, project, and process focused perspective, I’ve found that technical issues are no longer the first thing I think I need to solve.

Because even if you find a silver bullet (some kind of best practice), it takes a whole team to get you on the ground and stay on track. There is no need for heroes on a project, and even if there is someone on the team who can write great code, their hard work will soon be eclipsed by the tireless efforts of mediocre people.

The urge to have a “savior” on the team is a red flag, and it’s not usually the case. Then there’s the magic bullet. Have you considered whether everyone on your team can “swallow” the magic bullet? It’s not enough for just a few people to understand the solution and implement it in a project, so how do you build the magic bullet? What’s the bottom line? To put it bluntly, the bottom line is the downscaling of team capabilities.

So how to improve team efficiency, how to help team members grow and raise the bottom line of the team, are all discussed in this book.

Let’s be realistic

Remember the second type of person I mentioned at the beginning? They are also dangerous. If you simply abstract the problem to a certain height, regardless of the implementation, you can get the problem into an extreme situation where everything is solved and nothing is solved. The former is equivalent to “no”, the latter to “so what”. The “isn’t” and “so what” formulations that apply to everything seem irresistible, but when you think about them, they are flawed.

“It’s a micro front end” — sorry, what kind of micro front end are you talking about? How to solve the communication problem between components under different frameworks? What is the granularity of the integration pipeline at build time? What is the versioning strategy for interdependencies between components?

The “so what” mentality is even worse. When the code gets a little better, you get a “friendly” reminder from the pessimists. What’s a drop in the bucket? You’re not the first, but the entire codebase is still behind bars.

This way of thinking about it doesn’t make any sense. Why is code corruption an ongoing process, but why do we want to fix it once and for all in a certain period of time?

It’s normal for your code base to be broken, and the question is how and where to start. They’re not wrong, whether we introduce committer or code review meetings, there will come a time when it won’t stick, and the worst that can happen is that we haven’t made it better, but we’ve ensured that it won’t get worse in the process of trying.

The developer’s competency dilemma described in the previous section “is” Weinberg’s second law of consulting: No matter what it looks like at first, it’s always a human problem.

Is it abstract enough? Is it deep enough? Is it philosophical enough? Enough. But telling the truth isn’t going to help us solve our current problems. If the bottleneck really lies with the team members, what we want to know is, how can I improve the programming ability of the team members? To be more practical, as a startup, I can’t offer very competitive salaries to recruit top talent; Or if I can’t afford to spend too much time retraining, reviewing, refactoring due to delivery pressures, how can my code be saved?

In my opinion, the charm of this book is that it gets rid of its lofty position and “speaks human language”. The author doesn’t just throw a series of golden sentences at you and then you slowly understand them. For some concepts, even common concepts, the author will clarify and define. If he is offering a piece of advice, he will also explain the context and scope of the advice. For the possible obstacles in the implementation process, he also made appropriate predictions and solutions.

I don’t agree with every point he makes in the book, and you’ll have to judge for yourself whether it ultimately suits you, as there are no silver bullets in this area. But I’m sure these will give you some inspiration. From the classic, it is possible to surpass the classic.

This article was also published on Zhihu