Shulou(Shulou.com)06/02 Report--

This article mainly explains "what are the tips that web programmers know". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn what tips web programmers know.

1. Refactoring is the main skill of programmers.

2. The work log can increase the brain capacity.

3. Profiler is used to investigate before face-to-face optimization.

4. Notes are expensive but not expensive. Put an end to the "example notes" like menstruation. The fragmentary reading of notes all over the mountains is actually the background noise.

5. Ordinary programmer + google= super programmer.

Unit testing is always cost-effective.

7. Don't write the framework before writing the implementation. * in turn, extract the framework from the prototype.

8. The code structure is clear, and other problems are not a big deal.

9. Good project style hardliners, one-click testing, one-click release, one-click deployment; bad projects are creepy, word-of-mouth, non-writing, mysterious.

10. Don't be afraid of change, embrace it.

11. Charge frequently. There is only one way for programmers to die: dirt.

12. In programming, isolation is the direction, naming is the key, testing is the protagonist, debugging is the supplement, and version control is the medicine for regret.

13. One line of code, one soldier. Only by forming an organizational system can we have combat effectiveness. The scale of the unit should not be too large, a class of a thousand people, a row of ten thousand people can easily become a mass pit.

14. ReFactor / optimize / repair Bug, and only one thing can be done at the same time.

15. Simple modules pay attention to encapsulation, while complex modules pay attention to layering.

16. The performance of the human brain is limited, and neatness is better than clutter. If you can't read the code, try to sort out the format; if the interface is not easy to use, try to repackage it.

17. The iterative speed determines the work intensity. If you want to be quick and economical, start by simplifying the development process and speeding up the iteration.

18. Forget to optimize and write code. Premature optimization is tantamount to malicious sabotage; forget the code to optimize. Optimization should be based on performance testing, not between the lines.

19. The tool for * is pen and paper; the second best tool is markdown.

20. Leader asks about the time of the task, but if you can't answer it, it may be that the task is not divided in enough detail.

21. It is better to count one more week than one day less. Being too "optimistic" is easy to scare boss.

The most useful language is English. The next possible one is Python.

23. It is better to hear than to see. Draw the result and make it clear at a glance. Debugging time will be greatly reduced.

Resources and code should be subject to version management together. Resource matching errors are far more difficult to troubleshoot than code matching errors.

25. Don't develop based on imagination, develop based on prototype. The value of prototypes is to quickly verify ideas and save time.

26. Serialize the plaintext. Add when necessary, such as binary, obfuscation, encryption, compression, etc.

27. The compiler always knows better about micro-optimization than you do. We can only work in the direction it is not good at.

28. Don't make plans that are too big, too far, or too detailed. Even if it's decided, it won't work.

At least half of the time will be spent on integration. Time, time, time is always not enough.

30. When you run counter to mainstream opinions / methods / styles / habits, review yourself first.

31. Bug takes the initiative to check, whether it's yours or not. This can make your business ability soar and your personal image soar; if your bug is found out by others. Hehe, then you will be very passive ~ ≧ ≦

32. When I don't know how to choose a technical book, I choose a thin one. At least it's not too expensive, and you can finish it.

33. Git is the best. Simple, reliable, free.

34. Only throw assertions to "predictable irrationality".

35. Log should write down the time and classification. And be able to redirect the output.

36. Comments are slightly worse documents. Even better is the clear naming. Let the code tell its own story.

Making wheels is a good way to exercise. If you've seen other wheels.

38. Code review*** is in the form of groups / pairs. If you have some knowledge of the business, the advice will be more valuable (but not absolutely). And it won't be a burden. The administrator's personal review can easily become the bottleneck of team.

39. Do research before asking questions. If you don't get to the point, you are despised and waste your time.

Never underestimate a female programmer (╯ 3 ╰)

Thank you for your reading, these are the contents of "what tips web programmers know". After the study of this article, I believe you have a deeper understanding of what tips web programmers know about this problem, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.