Six bad habits in Web development and those in Web Development

Six bad habits in Web development and those in Web Development

At Usersnap, we have over 20 years of experience in organizing website development. We believe that these past experiences allow us to better distinguish between good, bad, and ugly website development. Now we don't want to focus on the negative part, but this time, we will make a summary of the past.

 

1. Send 20 key points by email

Sending emails of 20 key points to others listing all bugs, functional requirements, and rejected requirements is the same as the product. Generally, they may cause criticism or something similar to "Why don't you solve the $ XY problem? Didn't I mention it five weeks ago ?" This question. Once your development manager does not put these conversations into practical plans, you may forget things. Instead of complaining about all these things, your mom has never taught you. Instead, try to teach your customers or managers how to use the Bug tracker or project management tool *. In that case, you will not only save countless times to send lengthy emails, but the recipients will also know more about what work you are busy with recently.

2. CC to the entire team

Copying a question to everyone means you have no idea about who can handle it. This is a problem. If you do this, it is likely that no one will answer or feel responsible for this question. Also, reading these emails wastes a lot of valuable time from irrelevant personnel. Try to find out who is responsible and then send an email to him.

3. Leave the test to others

Let someone test a function, but he doesn't know what was wrong with the function at first. This is another way to waste time on team members. For example, some customers complain that a button in IE does not work. One developer who took over the problem solved the problem, and then another QA tested it and did not even know how to reproduce the problem.

4. War between the front and back ends

Dividing your development team into a fixed part is a bad idea and extremely agile (don't worry, we don't have the habit of using this word ). The distinction between 'frontend 'and 'backbackend' leads to "grabenkämpfe" (or "war between the frontend and backend"), which is undoubtedly not in line with the team spirit. Front-end developers complain that "the background changes are too slow", while backend developers complain that "this is the fifth time this year to modify the API ".

5. Release untested code

It would be a bad idea to publish untested code just because it is the code of HiPPO (the highest paying person. Worse: It happened before work on Friday. Of course, unless you work overtime on weekends...

6. Early Optimization

Yes, it sounds harsh. But before anyone can see your page, they can improve the CSS animation effect, which is no good for doing things. If you still have background tasks or reports, it is not a problem to have them run for 5 to 10 seconds when the service is not loaded. Optimization should be started after everything works normally. We advocate optimization very much. Please refer to the ninth article in our previous article!

Donald Ervin Knuth, a retired Computer scientist and Honorary professor at Stanford University, is The author of The 'Art of Computer Programming 'book. In his essay 'structured programming using a goto statement ', he wrote:

Programmers spend a lot of time thinking or worrying about the speed of irrelevant parts of their programs, which has a great negative impact on code debugging and maintenance. We should forget the efficiency of the nuances. For 97% of the time, premature optimization is the source of all evil. However, we should not miss the critical 3%.

In short: optimization begins before you figure out what you want to optimize, which may cause various unnecessary troubles and errors.

We should, I mean, do not advocate product changes without backup or development without clear ideas and instructions. Fortunately, you don't often encounter these errors.