This is the first day of my participation in the August More text Challenge. For details, see: August More Text Challenge

97- Things – Every -x-should-know

License: Licensed BY CC BY-SA 3.0.

Welcome to like, bookmark and comment ~ O(∩_∩)O

  • This melon does not translate word for word, but take its essence, understanding abstract, combined with their own writing expression, and share with you. Recognize good programming concepts, to be excellent ~

Technical debt

We programmers at the beginning of receiving demand, is not the way to make a completely correct assessment of the entire demand! As a result, most of the time, we are faced with unforeseen problems during code iterations.

In this case, it’s often a choice between “do it fast” and “do it right”!

Quick implementation is tempting because it can respond quickly to product or customer requests! However, it is highly likely to cause code clutter (due to insufficient initial design).

You might be thinking to yourself, “Ok, just do it first, and we’ll tweak it later.”

When does god know this “free”? ! As feature after feature, and time goes by day after day, your promise of “free optimization” will eventually become a technical liability!

When the technical debt more and more, more and more, our code will inevitably go to a road of no return – code 💩 mountain!

So, promised to optimize the code, it should be as soon as possible! Technical debt will generate interest!

Functional programming

Lately, functional programming has become more and more popular in the mainstream programming community!

Mastering the Functional Programming paradigm can greatly improve the quality of your code. Understand it deeper and apply it, and your designs will exhibit a higher degree of referential transparency (such as pure functions).

Functions have almost no side effects, which is very important! One of the biggest pitfalls of imperative code is that variable assignments and references are messy, and it’s very expensive to try to figure it all out.

Functional programming often distributes responsibility to more and smaller functions! The passing of arguments between these functions is very explicit, without arbitrary references to external mutable variables. This is easier to debug and reduces the bug of variable reference assignment confusion.

We look forward to more of functional programming! Some people assert that functional programming and object-oriented programming map each other, like Yin and Yang in Tai Chi.

Observe the user

We all tend to assume that other people think the same way we do, but that’s not the case! Psychologists call this the false consensus effect.

This phenomenon explains the distance between the user and the programmer. Users do not consider how the computer works, computing time, technical models……

The best way to learn about users is to watch them. An hour of observing what the user thinks is more effective than a day of guessing what the user thinks!

As I mentioned earlier, there is a natural gap between business requirements and the arrival of technology. To bridge this gap, programmers need to learn to observe requirements! As you observe, keep asking yourself: Why is he or she doing this? This is a better methodology than spending a lot of time guessing!

Automatic coding standard

Every project has project specifications, coding standards, which are expected to constrain and regulate the coding behavior of developers. But when it comes to the final delivery, it’s often a mess. Why is that?

There are many reasons, may be someone did not hear clearly, may not fully understand, may not agree, may agree but because it is difficult to practice the final choice to give up…… So, if you can’t automate coding standards, it’s hard to do!

In fact, we have a number of tools available to generate code quality reports and to document and maintain coding standards. It also automates the format code and enforces validation where possible.

We want to make sure that code formatting is part of the project build and is run every time the code is compiled; Use static code analysis tools to scan code for redundancies or errors. Learn to configure some automated scanning tools, test code, check code;

These behaviors should be updated, supplemented, and improved over the iterations of the project.

Simple programming is beautiful

All developers should remember:

Beauty of style and harmony and grace and good rhythm depends on simplicity.

What is beautiful code? This can be a very subjective question. People who study humanities and arts have a different view of beauty than people who study science and technology. But simplicity is the basis of most arguments.

Our code needs to implement:

  • Can read;
  • Can be maintained;
  • Rapid development;
  • Keep it simple;

You can find out by reading the source code. No matter how complex the application or system is, keep it simple! They have a centralized approach and a single responsibility.

Clean, simple, and testable code ensures that the system is maintainable over time, and thus can be developed at a faster rate. Once again: Simple is beautiful!

Refactoring to the

Almost every programmer has to refactor existing code. Before you refactor, it is recommended that you read the following:

  1. The first step in refactoring is to evaluate the existing code and the tests you’ve written. This helps you understand the strengths and weaknesses of your existing code, and then preserve the strengths and avoid the weaknesses. If the refactored code is worse than the original code, this step is not sufficient.

  2. Refactoring does not mean overwriting everything! No matter how ugly the code was, it’s never a good idea to throw it away completely. Because you’re throwing away months (or years) of tested, battle-tested code. There may be a method or bug fix logic that you don’t know yet. Brand new code can have the same mysterious error, which can take a lot of time and effort!

  3. Several small refactorings are better than one big one! This can also be called progressive refactoring of code. It’s no joke that massive refactoring can be stressful and can break down if you run into tough problems.

  4. After each refactoring iteration, make sure the tests pass. This is very important! If the existing test scenarios are insufficient to cover the changes you have made, add new tests. Don’t throw test cases into old code without thinking it through.

  5. Just because you don’t like the style or structure of the old code doesn’t justify refactoring it! Personal preferences will always change, and personal preferences will not necessarily be favored by others.

  6. Adopting new technology is not a good enough reason to refactor either! Unless a cost-benefit analysis shows that the new language or framework will lead to significant improvements in functionality, maintainability, or productivity, it is best to leave things as they are.

  7. Remember: refactoring does not always guarantee that new code will be better!

Be careful of reuse

When two distinct parts of the system perform some logic in the same way, you might think of writing a common library and then reusing it. That’s what the teachers teach! Code reuse, component reuse, common library reuse Balabala……

In practice, however, the two parts often change into different businesses, so reuse becomes coupled. Dependencies increase, and the veins of the system intertwine.

Actual practice also shows that the use of technology should be based on context, otherwise it will not generate value, but additional cost.

Be careful whether you use other people’s libraries or if you share them with others.

Scout rules

It’s a Scout rule to “always keep your campsite cleaner than you found it!” Robert Stephenson Smyth Baden-Powell, head of the British Scout Association, says this from the start: Try to make the world a little better than you find it.

We should follow this rule in code development as well! If everyone follows this simple rule, the fate of the code will be summed up.

Leaving a mess of code in your programming is the same as leaving a pile of garbage in your camp, and it’s unacceptable! It’s more like a general social rule.

Prioritize self-examination

When we look for problems, we wonder if something is wrong with the compiler, interpreter, operating system, application server, database, memory manager, but it turns out that they are very, very rare.

Assuming these tools are widely used and mature enough, you have no reason to doubt that it was their mistake that led to your mistake.

When locating a problem, check yourself first.

Holmes said: eliminate all possibilities, and whatever remains, however improbable, is the truth!

Good work sharps good tools

It is an old saying that if a worker wants to do a good job, he must sharpen his weapon first.

It’s important to choose the right tools for development! This mainly refers to components, third-party libraries, frameworks, and so on.

They can bring many conveniences:

  • The basic code can be built with tools;
  • Using components and frameworks is less likely to cause errors than writing it yourself.
  • High-quality libraries are maintained by high-quality development, and professional work is done by professional people.
  • Consider purchasing tools to increase your productivity;

Things to watch out for:

  • Find out the tool interface specification, does its model, protocol, etc., match your project?
  • Reduce the configuration of the tool, if it is very complex configuration, it may be difficult to maintain and extend!
  • Pay attention to the license terms, copyright issues;
  • Pay attention to the problem of charges, some tools are local 1 range of free, local range of charges;

Clear type definition

Once upon a time, we had very basic data structures: bits, bytes, and characters. Later, stacks, queues, hashes, linked lists, etc. “Computer science” puts a lot of effort into mapping the real world into our restrictive data structures.

Define exactly and clearly the type of code. Make it clear and let the next person know.

At the same time, having a clear type definition will help you encapsulate your code later.

Programming is design

Imagine waking up and the construction industry being transformed, with materials being created out of thin air and built by robots.

In this way, the design cost is greater than the construction cost. A company that can complete a design quickly will have an advantage in the market.

If the construction is not a problem, we just have to redesign it, or fix it, because there is no cost to produce the materials. The quality of construction began to deteriorate, caused by repeated incomplete designs.

This rambling talk about the construction industry is actually happening in the software industry. We can develop a project quickly, not just throw it away. Then quickly develop a……

Design is a creative work rather than a mechanical work.

Programming is design, development cost is small, design cost is more important.

Canonical code format

Research shows that developers spend a fair amount of time looking for an answer to the question “where to fix it”.

Therefore, we need to pay attention to canonical code format. This allows us to quickly scan the code and locate the problem.

The code layout should be compact, consistent, and clearly visible.

There are non-programming people who say: Code sometimes looks like poetry.

True standard code is exactly like this! Not only a non-professional person can feel the beauty of it ~

Independent CodeReview

We should be consistent with CodeReview, which improves code quality and reduces error rates.

Maybe we had bad memories at CodeReview (rookies got hung up at the beginning), and a lot of developers didn’t like it. Some companies have people who do CodeReview reviews, and developers must abide by the rules of the reviewer. Most of them tend to be strict and formal. In fact, this approach is the opposite. It takes time for the reviewer to learn a lot of code detail, which can be a huge bottleneck.

CodeReview would be much more effective if it were spontaneous, and everyone created and maintained coding guidelines together! Finding errors is not the goal; finding good coding is the goal. So when you’re doing CodeReview, it’s best to be gentle. Make an appointment to build together weekly or monthly.

Making CodeReview fun is key! This will not only optimize the code, but also unite the team and make progress together.

Give reasons for coding

We should carefully consider the correctness of each block-level code and give reasons that convince us why we should write it that way.

There are at least simple logical reasons for conditions, loops, the use of classes, functions, etc.

Such as:

  • Avoid goto statements because they cause coupling with the remote end;
  • Avoid modifiable global variables, which can cause dependencies between parts.
  • Each variable should have as small a scope as possible, as this does not affect external variables;
  • If you need to use nesting, wrap it as a function because the code is cleaner.
  • The function should have no more than 4 input parameters, which can reduce the time to find the variable reference assignment.
  • .

We need to get into the habit of constantly reasoning out reasons why the code is written the way it is!

This will benefit you immensely!

Keep comments

Code comments are very important!

The author was given a low grade for not commenting his code on a programming test in school.

Comments themselves are not malicious; they are as much a programming necessity as basic branching or looping constructs.

Bengua previously wrote a post titled “How to Comment code in five Minutes? , which has detailed details about the notes, interested students can go to read.

When we read someone else’s code, we usually look at the comments first. So, getting in the habit of constantly maintaining comments will go a long way with your code

Effective comments

What is a valid comment?

Comments can express things outside the code and explain what the code can’t explain.

There is also a book saying that code is comment, and prioritizing saying what you want to say in code.

  • Comments should be short and clear;
  • Tell everyone why you wrote the comment, not what the code is! The “what” should be left to the code itself;
  • Keep your comments up to date and match your code;

Continuous learning

As programming becomes more and more popular, one day you may not be needed anymore. Your job will be replaced. What would you do?

Continuous learning may be one of the answers to help you, and here are some suggestions:

  • Read books, magazines, blogs, Wikipedia, and good learning sites;
  • If you really want to immerse yourself in a technology, write some code.
  • Learn from the awesome people around you. You’ll learn more from them.
  • Subscribe to some good blogs;
  • Dig deep into the frameworks and libraries you use, and you’ll see how they excel.
  • Fix problems carefully, document them, and share them;
  • Talk to people about technology, or teach them technology, and it helps you understand.
  • Join a learning interest group;
  • Learn about The Pragmatic Programmers, expanding The technology stack;
  • Improve learning efficiency, pay attention to learning methodology;
  • Go back to school;
  • .

Programming technology changes quickly, so stay tuned!

Convenience is not the norm

We may do some temporary API design for convenience, which leads to a lot of problems;

The authors give an example:

  • He didn’t want the other classes to have to make two separate calls to do it.
  • If it’s almost the same as this method, why would I make another method? Why not write a judgment switch to do that?
  • .

This is very purposeful, but it reduces the readability of the API;

There should be a better strategy for API design (e.g., using the term variety) than using convenience as a standard.

Remember: no English word looks like this, so please don’t design an API like this, even if it looks “more convenient” ~

MakeUpYourRoomBeQuietAndDoYourHomeWork
Copy the code

Early deployment

We usually do deployment at the end of a project, but deployment is the first thing the demand side wants to see.

If deployment is left behind, the process becomes even more complicated by situations such as adapting assumptions about the environment in your code.

Deploy early, improve visibility, be available early, and finish is more important than perfect.

It is also an important indicator of team productivity.

OK, the above is the first series of sharing (a total of 5), pay attention to the column, the series of continuous tracking ~

I’m Anthony Digger, output exposed input, technology insight life, see you next time