10 experiences summarized from using node.js for half a year_node.js

Let’s not talk about housing prices, traffic jams, and smog. . . Let me first talk about my experience using Node.js in the past six months. . . They are all problems encountered at work and lessons learned through blood. .

1. Precise version number

"It must be accurate to the specific version number! Use * to scroll directly, ^ and ~ will not work!" I just arrived at the company in the morning, and the head of our server had bloodshot eyes (I guess he fell asleep at what time in the morning), and complained to me : "Damn it, the version in package.json of the code I wrote before is different from the version running on the server. When I installed the latest one, I got an error again." Omit a few thousand words here. . .

Okay. I slap myself in the face first. In the past, only * was used. . . Most of the time, there is no need to hard-code the version number. You can also use ^ and ~. Scan the blind:

semver
Version management in node.js

2. Test

Be sure to write test cases. Take me for example, the part I am responsible for includes the filtering part (using regular Shenma filter text to extract useful text). With test cases, every time you change the filtering rules, run npm test and everything will be fine. Choose the test module to use according to your personal preference, such as mocha, should, tape, tap, supertest, etc.

Try to run it locally and upload it to the server only after the test is successful. After I changed the code several times (just a few lines), I thought there might be a problem, but as soon as I restarted the server, it crashed. . Damn, I'm missing parentheses or something. . This kind of problem can also be solved by using editor plugins such as jslint or jshint to detect low-level syntax errors.

Server code backup. The method I currently use: Initially there are two identical projects (git libraries, file names are different) on the server, one is running and the other is used as a backup. When there are code changes, go to the backup project and git pull, then stop the running program and start the backup program. If the program does not hang up after a period of time, that is, after it feels relatively stable, this project will be regarded as the main project and the other project as the backup. When there are changes again, repeat the above steps and switch back and forth between active and standby. If the program hangs, just switch back to a more stable device.

3. Use debug

Debugging is inevitable when writing programs. Many people like and are accustomed to using the all-purpose console.log(), including me. . Personally, after I use console.log(), I either delete it or comment it out. Delete it and it may be used in the future. Commenting it out will look ugly. At this time, you might as well use the debug module. I haven’t used node-inspector yet, so I won’t comment.

4. Keep the code streamlined

Trying to accomplish more things with less code is also an improvement and test of your own abilities. Including correct indentation, appropriate variable names, clear code organization structure, etc. . The code is streamlined and beautiful. When something goes wrong, it's faster to go back and check for errors. It's better than spending hours trying to figure out what a mess of code does first.

Don’t use CoffeeScript if your team doesn’t use it. First, others cannot read your code and help you correct errors. Second, after an error occurs, the number of lines showing the error is different from the number of lines of the coffee code. . . You can use it for your own open source projects.

5. Ask for advice and maintain independent thinking

When I first started working, I was confused about everything, including technical deficiencies and business logic deficiencies, so I often asked the experts in the team for advice. 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 the PM. I had to consider the needs of the users (multi-client situation), the needs and behaviors of the clients, and the design of the database (how to store less redundant data, reduce the number of queries, and be easy to expand). Easy to modify, differential query), etc., I thought about it for more than a week and almost collapsed. . . Although I have discussed it with the boss many times, it always gives me logic but does not tell me the method. Later, I finally found a pretty good solution. . He also told me later that he wanted me to think independently and solve problems so that I could improve. .

6. Use existing libraries

Currently, there are nearly 9W third-party modules on npm. In theory, everything you want to use can be found on npm. Of course, there are many excellent modules on npm. The documentation is comprehensive and very easy to use. It is usually satisfactory. need. If you find that a module can meet most needs, has functional improvements, or has bugs, you can submit a PR on github. If you find that you cannot find a module that meets your needs, you can create one yourself and publish it to npm. Share it with everyone. Of course, if you find that a certain type of module that implements a certain function is very shitty, you can also publish a module that is not shitty.

7. Keep it simple

If you want to display a pie chart, just use HTML5 canvas or CSS3. There is no need to use C's canvas library to draw a picture. "Just downloading the dependent libraries is 400 MB," Toutou said.

8. Good documentation

Good documentation is the most important channel for communication between the client and server teams. The documentation is clearly written. If a client request goes wrong, you can check the documentation first (for example, what each error code represents), instead of going to the server to discuss it every time something goes wrong. PS: Try to use curl to write some http request examples instead of using objects in js. Maybe you understand it, but the people on the client don't understand js.

9. Configuration file

Create a configuration file in each project directory, such as config.js/config.json. Rather than hard-coding it into the code. Such as:

{
"app": 3000,
"mongo": {
"host": "localhost",
"port": 27017
},
"redis": {
"host": "localhost",
"port": 6379
}
...
}
10. Use pm2

It is very convenient to use process management tools such as pm2. At worst, the process can be automatically restarted if it dies. Never used forever. No evaluation. . Also, I haven’t used grunt Shenma, so I won’t comment on it.