This is the fourth 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 ~

  • The Path to Excellence: Learning 97 Good Programming Concepts (part 1)

  • The Path to Excellence: Learning 97 Good Programming Concepts (part 2)

  • The Path to Excellence: Learning 97 Good Programming Concepts (part 3)

(After a painful reflection, the reading quantity of the first three translations is getting worse and worse, with 20 points for each. Usually, each point takes 10 to 15 minutes and 3 to 5h for the whole article. Time spent, but little effect, reflect on the programming concepts, suggestions are too long, vague, so change the way of thinking, more concise, more perfect!

Code tells the truth

The author wants to say:

  1. Code is the only way to tell people what you really want. Requirements documents don’t always tell the whole story.
  2. Comments are just an auxiliary function. Don’t try to use comments instead of code.
  3. Write code like a poem.

Responsible for building

The author wants to say:

  1. The build script for the project should also be maintained at all times;
  2. The build process should be the responsibility of the R&D team, not the test team or other “quality assurance” team;
  3. It’s important to understand the build process;

Pair programming

The author wants to say:

  1. It’s hard for one person to program with all his heart. There are too many interruptions and distractions.
  2. Try pair programming to promote communication and team integration, learn from each other’s strengths and make progress together;
  3. Pair programming, so that new colleagues quickly get started; (How to play!)

Precisely define types

The author wants to say:

  1. Take a real example: a satellite lost contact because of the program unit calculation error;
  2. With statically typed languages, the compiler can do the checking; With dynamically typed languages, unit testing is relied on;
  3. Define exactly the type of the variable (custom type), rather than just using primitive types such as String or Float;

Avoid error

The author wants to say:

  1. Error reports caused by the user’s incorrect use of the program, which can be predicted and measures taken to avoid;
  2. Providing effective prompt can avoid user operation error;
  3. The system needs zero tolerance for errors, rethinking interactions, and even redesign;

Professional programmer

The author wants to say professional programmers:

  1. The first trait is: responsibility;
  2. Second, teamwork;
  3. The third trait is: intolerance of error;
  4. The fourth characteristic is: craftsman, clean code;

Version control

The author wants to say:

  1. Everything needs to be under version control (source code, documentation, build scripts, test cases, third-party libraries, etc.)
  2. Version control makes some behavior traceable;
  3. Version control reduces friction and conflict between development;
  4. Version control makes teams more efficient;

Put the mouse down and leave the keyboard

The author wants to say:

  1. When you have been thinking about a problem for hours and it hasn’t worked out, put down the mouse, get away from the keyboard and go outside for a change.
  2. You’ll be able to come up with more creative solutions;

Reading the code

The author wants to say:

  1. Programmers like to write code, but they don’t like to read it.
  2. Think about how readable is the code?
  3. You can improve your programming skills by reading code.

The humanities

The author wants to say:

  1. The work of the program is often not simply to write code, it is inevitable to deal with people;
  2. Learning about the humanities can improve your thinking;

To build the wheels

The author wants to say:

  1. Don’t be so quick to dismiss the idea of building wheels over and over;
  2. Reconstructing a wheel can help you gain a deeper understanding of how it works;
  3. The more important aspect of building a wheel is training and gaining experience.

Use singletons with caution

The author wants to say:

  1. The singleton pattern is simple, but it does more harm than good. It is not good for testability and maintainability.
  2. Singleton pattern is easy to cause implicit dependency of code units and cause coupling.
  3. Singletons are bad for unit testing;
  4. The next time you think about implementing or accessing a singleton, think again;

Code bombs

The author wants to say:

  1. Highly coupled code is code bomb;
  2. There are many ways to measure and control code coupling and complexity;
  3. There are two indicators to measure coupling: fan in and fan out;
  4. Use these metrics for tuning;

VAT code

The author wants to say:

  1. You can clean up the mess by restoring the code; (This dot fits in with “Improve code with deleters” mentioned above.)

Single responsibility

The author wants to say:

  1. The principle of single responsibility is one of the basic principles of good design.
  2. It means that a subsystem, module, class, or even a function should not have more than one reason to change;
  3. Taking advantage of a single responsibility to separate things that change for different reasons creates a component structure that can be deployed independently.

Starting from the yes

The author wants to say:

  1. Change your point of view from no to yes and get to work;
  2. When someone makes a ridiculous point, you can ask why before you say no.
  3. Yes stands for cooperation;

automation

The author wants to say:

  1. Repeatable behaviors can be automated;
  2. Automation is not just for testing;
  3. Automate in the IDE as well;
  4. Automation is no mystery;
  5. Learning automation can be learned by doing;

Use code analysis tools

The author wants to say:

  1. Testing is just one of many tools to improve code quality;
  2. Use other code analysis tools, such as Lint, etc.
  3. Try your own custom code analysis tools;

Test the required behavior

The author wants to say:

  1. One of the pitfalls of testing is to measure random behavior, behavior that has nothing to do with functionality;
  2. The test shall be accurate and accurate;
  3. In testing, the interface of the unit under test should be agreed, and the test behavior should be consistent with the required behavior.

Test precisely and concretely

The author wants to say:

  1. Test basic behavior rather than incidental behavior;
  2. The test needs to be accurate and accurate; (Fit with the above little point)

Test when you are free

The author wants to say:

  1. The test server should take advantage of free time such as nights and weekends;
  2. Long-running tests are critical to identifying memory leaks and other stability issues;
  3. This assumes, of course, that automated testing has been applied;

Small sense: although everyone’s advice is different, but after reading it, it seems to point to the same direction – how to do better in this position of programmer! Some of the small points are very sensitive, suitable for deep digging. Some “consensus” may be “consensus” in everyone’s eyes, but I just know ~ mutual encouragement.

OK, the above is the fourth series to share (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