10 lessons learned in six months with node.js

Forget housing prices, traffic jams, smog... Let's start with my six months of experience using node. js... It is the problem that meets on the job, blood lesson.

1. Exact version number

"Be precise to the version number! Use * to roll directly, ^ and ~ are not ok!" When I arrived at the company in the morning, the head of our server had blood in his eyes (I think he went to bed in the early morning) and complained to me: "damn, the version in the previous written code package. Json is not the same as the version the server is running. Install the latest one and report another mistake." Omit thousands of words here...

All right. I hit myself in the face first. Used to only use *... Most of the time there is no need to write the version number, use ^ and ~ can also be. Scan the blind:

semver
Version management in node.js

2. The test

Be sure to write test cases. In my case, the block I'm responsible for contains the filter section (filtering text with something regular to extract useful text). With the test case, after each change of the filter rule, NPM test, no problem. Select test modules to use according to personal preference, mocha, should, tape, tap, supertest and so on.

Try to run it locally and upload it to the server after the test is successful. I changed the code several times (just a few lines) thinking that something might go wrong, only to have the server fail as soon as I restarted it. No brackets or something. This problem can also be detected by using editor plug-ins such as jslint or jshint to detect low-level syntax errors.

Server code backup. The approach I'm using so far is to start with two identical projects (git repository, different file names) on the server, one running and the other running as a backup. When code changes, go to the backup project git pull, then stop the running program, start the backup program. If the program did not fail after a period of time, that is, feel more stable, the project as the master, another project as backup. When there are changes, repeat the above steps, the main and backup switch back and forth. If the program fails, switch back to a more stable backup.

3. Use the debug

Writing g programs is not without debugging, many people like and get used to using the versatile console.log(), including me. On a personal note, I either deleted or commented out the console. Log () when I was done. I'm going to delete it and maybe use it again, but I'm going to comment it out. This is a good time to use the debug module. I haven't used the node-inspector yet and don't evaluate it.

4. Keep your code simple

Trying to do more with less code is also a test of your ability to improve. This includes correct indentation, proper variable names, clear code organization, and so on. The code is streamlined, beautiful, and when something goes wrong, it's faster to look it up than if it took hours to figure out what a mess of code was doing.

Don't use CoffeeScript if the team isn't using it. One is that no one else can read your code to help you correct errors. Second, after the error display error line number and the number of lines of coffee code is not the same... Your own open source projects can be used.

5. Ask and think for yourself

At the beginning of the work, I was also confused about various problems, including the lack of technology and the lack of business logic. Then I will try to make up for the technical shortcomings and clarify the business logic. Later, I had to design an API according to the requirements of PM, not only to consider the needs of users (multi-client situation), the needs and behavior of the client, the design of the database (how to save less redundancy, fewer queries, easy to expand, easy to modify, difference query), etc., considered for more than a week, nearly crash... Although I discussed with the leader many times, he always gave me logic and did not tell me the way. Then finally found a kind of not bad solution. He also told me later that he wanted me to think independently to solve problems so that I could improve.

Use existing libraries

At present, there are nearly 9W third-party modules on NPM, which can be found on NPM if you want to use them in theory. If you find that a module can meet most of the requirements, you can have functional improvements or bugs, you can go to github to discuss pr, if you find that you can't find the module to meet the requirements, you can create your own and NPM publish to NPM and share with everyone. Of course, if you find that a certain type of module that implements a certain function is shit, you can also publish it.

7. Keep it simple

If you want to show a pie chart, use HTML5 canvas or CSS3. There is no need to draw a picture with the canvas library of C++.

8. Good documentation

Good documentation is the most important channel for the client to communicate with the server team. The documentation is clear, so if a client request goes wrong, you can review the documentation (such as what each error code represents) rather than go to the server and discuss it every time something goes wrong. PS: some examples of HTTP requests are written with curl instead of objects in js, etc. You may understand them well, but the client doesn't understand js.

9. Configuration files

Create a configuration file in each project directory, such as config.js/config.json. It's not written in code. Such as:

{
  "App" : 3000,
  "Mongo" : {
      "The host" : "localhost",
      "Port" : 27017
  },
  "Redis" : {
      "The host" : "localhost",
      "Port" : 6379
  }
  .
}
10. Use the pm2

This process management tool, such as pm2, is very convenient, the worst process to hang can automatically restart. Never say no to forever. We don't use grunt, we don't judge.