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. . . All are problems encountered at work and bloody lessons. .
1. Accurate version number
"You must be accurate to the specific version number! Use * to roll directly, ^ and ~ are not OK!" As soon as we arrived in the company in the morning, our server was covered in bloodshot eyes (it was probably what time of morning to go to bed) and complained to me: "Damn, the version in package.json code I wrote before is different from the version that is running on the server. Install the latest one and then reported an error." A few thousand words are omitted here. . .
All right. I'll slap myself in the face first. I used to only use *. . . Most of the time, there is no need to write a dead version number, and it is also possible to use ^ and ~. Scan the blindness:
semver
Version management in node.js
2. Test
Be sure to write test cases. Take me for example. The piece I am responsible for contains the filtering part (using the filter text of the regular Shenma to extract useful text). With test cases, after each change of the filtering rules, it is absolutely true under npm test. Choose the test modules to use according to your personal preferences, mocha, should, tape, tap, supertest, etc.
Try running locally and upload to the server after the test is successful. I have modified the code several times (just changed a few lines) and thought there might be a problem, but as soon as the server was restarted, it hangs up. . Damn it lacks brackets or something. . This problem can also be detected by using editor plugins such as jslint or jshint.
Server code backup. The method I am using: At first there were two identical projects on the server (git library, different file names), one running, and the other as a backup. When there are code changes, go to the backup project to git pull, then stop the running program and start the backup program. If the program does not fail for a period of time, it means that it feels relatively stable, take this project as the main and another project as the preparation. When there is another change, repeat the above steps and the main and backup switch back and forth. If the program fails, switch back to a more stable backup.
3. Use debug
Debugging is inevitable when writing programs. Many people like and are used to using the universal console.log(), including me. . Personally, after I use console.log() to adjust it, either delete it or comment it out. It may be used later if you delete it, but it is very ugly to comment it out. You might as well use the debug module at this time. No node-inspector has been used yet, so no evaluation is made.
4. Keep the code simple
Trying to accomplish more things with less code is also an improvement and test of your own abilities. Includes correct indentation, appropriate variable names, clear code organization, etc. . The code is thinner and beautiful. When something goes wrong, it is faster to check the error. It is better than to figure out what a messy code does and it takes several hours to do it.
If the team is not using CoffeeScript, don't use it. First, others cannot understand your code to help you correct errors. Second, the number of lines that appear after an error is different from the number of lines that are displayed in the coffee code. . . Your own open source project can be used.
5. Ask more advice and keep thinking independently
When I first started working, I was also confused, including technical shortcomings and lack of business logic. I often asked the big guys in the team. Then I will try to make up for technical shortcomings and clarify business logic. Later, I wanted to design an API according to the requirements of PM, which not only took into account the needs of users (the situation of multiple clients), the needs and behavior of clients, the design of database (how to store less redundancy, fewer queries, easy to expand, easy to modify, and different queries), etc. After considering it for more than a week, it almost crashed. . . Although I discussed with Tou Tou many times, it always gives me logic and does not tell me the method. Later, I finally found a pretty good solution. . He later told me that he wanted me to keep thinking independently to solve problems so that I can 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, with comprehensive documentation and very convenient use, which usually meet the needs. If you find that a module can meet most needs, it can be functionally improved or has bugs, you can go to github to add pr. If you find that you cannot find a satisfying module, you can create and publish it on npm to share with you. Of course, if you find that a certain type of module that implements a certain function is very shit, you can also publish a shit.
7. Keep it simple
If you want to display a pie chart, just use HTML5 canvas or CSS3. There is no need to use the C++ canvas library to draw a picture, "the library that depends on is 400+ MB", said this.
8. Good documentation
Good documentation is the most important channel for clients to communicate with server teams. The document is clearly written. If the client request error occurs, you can first check the document (such as what each error code represents), instead of asking the server to discuss every time there is a problem. PS: Some http request examples should be written in curl, rather than objects in js, etc. You may understand it very well, but the client does not understand js.
9. Configuration file
Create a configuration file in each project directory, such as config.js/config.json. Instead of writing it dead in the code. like:
{
"app": 3000,
"mongo": {
"host": "localhost",
"port": 27017
},
"redis": {
"host": "localhost",
"port": 6379
}
...
}
10. Use pm2
Using process management tools such as pm2 is very convenient, and the process can be automatically restarted if it fails. Haven't used forever, no evaluation. . There is also grunt. I haven't used it before, so I won't comment.