Programming is essentially a craft, and since it’s a craft, there’s a lot of personal skill and experience involved.

“Broke Windows theory,” DRY (Don’t Repeat Yourself), tracer bullets, orthogonality. Do you remember what those words mean?

In my opinion, The Programmer’s Practice is a guide to development philosophy written by a master to his apprentice.

It includes software development philosophies such as broken Windows theory, which explains why your code can quickly turn into a mountain of shit. It also covers some useful tips and tools, such as how to make good use of the shell and improve your programming efficiency.

This book has no complex code, no arcane principles, you can read it as a casual book.

The truth mentioned in this book that seems to be understood by everyone is exactly the idea that many code farmers pay the least attention to in their daily work, but should follow.

I have distilled some ideas in the book that I think are still not out of date (after all, this book has a certain number of years, it reads very old sense), and share with you, this is also mixed with some of my views and thinking.

First, the philosophy of development

  1. As a developer, you need to be responsible for what you say. You have the right not to take responsibility for things that are too risky and impossible to do.
  2. Don’t give excuses for not being able to do it. When you say it won’t be able to do it, offer your ideas and tell people whether it’s because you need refactoring, time to prototype, or additional resources.

  3. The Broken Window Theory: A broken window, if left unrepaired for a period of time, will gradually bring a sense of abandonment to the residents of the building. So the Windows would break one by one, and people would start littering and scribbling. So don’t tolerate “broken Windows” in your code.

    You know this, too, when you see a bunch of clunky structures and designs on a project you’re writing code on, you automatically start writing code on top of it and it turns into a mountain of shit.

  4. Boil a frog in warm water, and the code will rot undetected. Constantly observe changes in your project, rather than just focusing on your own piece of code.
  5. Value your “knowledge”; it is your asset. Since it is an asset, it is necessary to invest regularly (continuous learning), diversified learning. And periodically evaluate your technical direction. Development is a volatile business, and technologies that are sought-after now will become obsolete in a few years. Always adjust your direction.
  6. When doing requirements, we should think about the rationality of requirements like users, rather than blindly completing the requirements issued by the product.
  7. Make software that gently exceeds user expectations. Give them a little more than they expect, and you can get a lot of credit for going the extra mile when adding features to your system.
  8. When you’re on a large development team, you can assign each person responsibility for all aspects of the work. Assign work around function, not job title. For example, if someone wants to talk about date processing, they go to Mary. If someone wants to talk about data storage, they go to Fred.

Second, development criteria

  1. Don’t Repeat Yourself: Each component in a DRY (Don’t Repeat Yourself) system should be single, unambiguous, and authoritative.
  2. Keep your project orthogonalized: Don’t let systems be coupled to each other. A non-orthogonalized system means that you can change one system and it will affect the other.

Non-orthogonal a typical expression is the front end of the CSS, there are a lot of jokes on the Internet CSS jokes, a modification of CSS will often affect other places, which is also a very painful place CSS. In back-end development, we try to keep systems from interacting with each other, which can be very damaging to the system and very painful when troubleshooting problems.

  1. Make your code design undoable: It can be dangerous if your idea is the only solution to the problem. Users’ needs change rapidly, and your decision is likely to be correct only at the moment, without the final decision. In other words, you should pay attention to and reflect on it all the time. If the current method does not work, is it impossible to recover?
  2. Evaluate your resources: By resources, you refer to a number of code-related resources, such as databases, storage, performance, etc. Before development, it is important to do the calculation and design the code structure well so that it can cope with the changes in the future.
  3. Make as much documentation as possible in the code, not out of it. Otherwise, after a while, your documents will become useless.
  4. You can’t write perfect software: As a developer, you have to have the self-awareness and don’t believe it yourself. So program defensively for the mistakes you might make.
  5. Exception handling: If I delete all the exception handling code, will it still work? If your answer is “no”, then your exception code is being used in a non-exception case. That’s not good.
  6. Leverage metadata: Metadata here can be thought of as configuration files. Put abstractions into code and details into metadata.

We often use configuration files and distributed configuration centers in our daily development. We try to put the data that can be put into the configuration files, which is not only easy to maintain and modify, but also can realize the function of changing application behavior without restarting the application. The code should only be our abstraction of the business.

  1. Think well about system concurrency: Think well about concurrency.

Does this request seem like a common one, everyone does? Many large systems, especially older ones, don’t take concurrency into account (just ask the traditional software companies). Concurrency is actually one of the most common problems in Internet companies, and it’s also a very deep question to ask in all kinds of technical interviews.

  1. Don’t program by accident. Figure out why your program works.

At the beginning of our contact, there are often some codes running through the tune, but even they do not know why. This kind of code is very risky to use online. After all, he may not really work, he may just seem to work!

  1. When to Refactor: When you find these four things, it’s time to refactor.
  • The code violates the DRY rule
  • There are non-orthogonal designs
  • The code became obsolete after the requirements changed
  • There are major performance issues
  1. Rules for refactoring:
  • Don’t try to add functionality at the same time you refactor.
  • Before you start refactoring, make sure you have good tests in place so you can make any changes.
  • Take short, deliberate steps.
  1. When testing, do state coverage, not code coverage.
  2. Learn the shell: Usually we like to use a variety of software with interface, they are characterized by what you see is what you get. But it also has the drawback that what you see is all you see. This can be a bottleneck for efficiency, as there are many things that require a lot of action on the GUI and only one line of code on the shell. So even though it’s a little difficult to get started, it’s a huge productivity boost.

Pay attention to my

I am a back-end development engineer working on the front line of the Internet.

Usually mainly focus on back-end development, data security, welcome to exchange.

  • WeChat official account: back-end technology rambling
  • Making:@qqxx6661
  • CSDN: @ Man Three Dao Dao
  • Zhihu: @ back-end technology ramble
  • Nuggets: @ pretty three knife knife
  • Tencent cloud + community: @ back-end technology ramble
  • Blog Garden: @ Backend Technology Ramble
  • Bilibili: @Man three knives

Main contents of the original article:

  • The development of actual combat
  • Technical interview
  • Algorithm problem solving/data structure/design patterns
  • The program life

Personal public number: back-end technology rambling

If the article is helpful to you, please classmates thumb up forward the collection of three, your support is a great encouragement to me ~