6 Bad Habits in Web Development_html/css_WEB-ITnose

At Usersnap, we have over 20 (total) years of experience in organizing website development. We think these past experiences give us a good idea of ​​what constitutes good, bad, and ugly website development. Now we don't want to focus on the negatives, but for once, we're going to summarize the bad points from the past.

1. Send 20 key points by email

Send 20 key points by email to others, listing all bugs, functional requirements and other people’s bugs Rejection of requests is the same issue as for goods. Usually they come with accusations or questions like "Why don't you fix $XY? Didn't I point it out five weeks ago?" Once your development manager doesn't translate these conversations into actionable plans, you risk forgetting things. Instead of complaining that your mom never taught you all these things, try teaching your clients or managers how to use a bug tracker or project management tool*. That way, not only will you save countless hours of sending lengthy emails, but the recipients of the emails will also have a better idea of ​​what you've been busy with lately.

2. CC the entire team

CCing everyone on the issue means: You have no idea who can handle the issue. This approach has its own problems. If you do, chances are no one will answer or feel responsible for the problem. Also: reading these emails wastes a lot of valuable time of irrelevant people. Try to find out who is responsible and email only that person.

3. Leave testing to others

Having someone test a feature without knowing what was wrong with it in the first place is another way to waste team members’ time. . For example: A customer complained that a certain button in the IE browser did not work. One of the developers who first took over the issue solved it, and then another QA guy tested it without even knowing how to reproduce the issue.

4. The war between front and backend

Dividing your development team into fixed parts is a bad idea and extremely un-agile (don’t worry, we don’t have a habit of using that word) ). Distinguishing between ‘front-end’ and ‘back-end’ leads to a “Grabenkämpfe” (or: war between front-end and back-end), which is undoubtedly not in the spirit of the team. Front-end developers will complain that "backend changes are too slow", while back-end developers will complain that "this is the fifth time the API has been modified this year."

5. Release untested code

It is absolutely a bad idea to release untested code just because it is the code of HiPPO so-and-so (the one with the highest salary) idea. What's even worse: this happened before get off work on a Friday. Of course, unless you work overtime on weekends, that's a different matter...

　6. Optimize too early

　Yes, it sounds a bit harsh. But starting to improve CSS animations before anyone has seen your page won't do you any good. If you have background tasks or reports, it's not a problem to let them run for 5 to 10 seconds while the service is not loaded. You should start optimizing after everything is working properly. We still strongly advocate optimization, please see Article 9 in our previous article!

Donald Ervin Knuth, a retired computer scientist and emeritus professor at Stanford University in the United States, is the author of a collection of selected works on computer programming Author of The Art of Computer Programming´. In his paper 'Structured Programming with goto statements' he writes:

Programmers spend a lot of time thinking about, or worrying about, the speed of unimportant parts of their programs, which can make the code less interesting. Debugging and maintenance work have a significant negative impact. We should forget about the subtleties of efficiency, and for 97% of the time: premature optimization is the root of all evil. However, we should not miss the critical 3%.

In short: starting to optimize before you figure out what you want to optimize will bring all kinds of unnecessary trouble and errors.

We should, I mean, I would not advocate making changes to the product without backing up or developing without clear ideas and instructions. But luckily, you won't encounter these errors very often.