10 (not) obvious tips for novice web developers

The Internet already has a lot of books, articles, and the same posts on Habré for beginners. But, as for me, there are a number of nuances that are usually or not mentioned at all (apparently, they are considered obvious), or they are mentioned very rarely. And these are not tips from the series “learn the code of other developers”, “use git”, “make backups” or “wash your hands before going to the production-console”. These are mundane, practical things that come with some experience. Some of them are not useful if you use the most modern approaches to development, some of them are universal. Specifically, in this post, the PHP developer’s experience is expressed, but in fact a lot of items are suitable for other development stacks.

If you are a beginner web developer - welcome under the cut, Senior’s are unlikely to find something new there for themselves.

1. Flush caches of static files

The obvious thing, however, novice developers often come together with this problem. Not everyone uses advanced build systems and deployment frontend, and therefore many good old approaches work like

<script src="/script.js"></script> <link href="/style.css" rel="stylesheet" type="text/css" /> 

No, there is nothing bad in it, everything works and will work. The problem also occurs when changing these files. The developer makes changes, fills in the prod, writes to the customer. The customer checks - and says that nothing works for him. And why? Because his browser keeps in cache the old version of files. And all other users - the same thing. Trite? Of course! But they attack this rake very often. The solution is simple - add a random GET parameter. For example:
')

 <script src="/script.js?v=% %"></script> //  <script src="/script.js"></script> 

before each commit of the modified file. The web server will simply ignore this parameter, but the browser will pull the file again, because the url has changed.

2. Do not store important files in a public directory.

A common scheme: “I will do code.backup.zip at the root, deflate it, and delete it. I quickly, who there knows that there is such a file. " The problem is that almost all sites from time to time crawl bots that stupidly sort out obvious links like /update.sql , /backup.sql , /config.php.bk , etc. There are hundreds of options in their database. Therefore, such leaving the files “in a quick way” in the open access can easily go sideways. And leave them on an ongoing basis - so just come out.

If it is very hot - create files with absolutely random names. But it's better not to do that at all. Do not be elusive Joe.

3. Development and Production sites are always different servers.

The approach in which production and development is rotated on one server is also often encountered. Sometimes, with a special increase, even the connection keys to the database (which are also on the same server) coincide, and only the name of the databases differ. What is fraught with:

1. trite to confuse, and mess things up on the "combat" system. Do not amuse yourself with the illusions "Yes, I am always very attentive"
2. accidentally put food I did experiments on the dev site, something went wrong, devoured all the resources / put the database - OP, and you also had the main site at the same time
3. get problems when updating the software version on the server. Decided to transfer the project from php5.6 to 7.2? And both sites are spinning on the same server, and making different versions for different domains is a pain. Do not immediately fill in the prod, right? So there was a problem with the test site.

In general, the rule is simple - production site (and its database) is always a separate server.

4. Verify local configs and server configs.

In large projects, where there is a separate shaman admin, docker (or vagrant), many servers, a balancer, etc. - this problem, of course, will not arise. He rolled the image of the environment - and drove. However, let's face it - there are many who still use the “updated file - uploaded via FTP” approach, and getting a project like this to a novice developer is just to spit. And then there are problems when locally everything worked, but on the prode it disappeared. Therefore, always verify the identity of environments. Sometimes a minor version of some software (like php 7.0 on the prod and 7.2 locally) can break everything.

5. Log complex operations as carefully as possible.

Young (not in terms of age - but in terms of experience) developers often forget about logs, hoping that the framework or a web server will do this. This is so, but such logs will help catch only very gross errors, such as syntax errors or incorrect queries. Therefore, when developing complex functionality, always write to the logs everything you can, this will greatly facilitate life in the future. You don’t write a highload project like a Facebook competitor, where you have to worry about losing an extra millisecond to write to the log, right?

6. Check whether you are keeping everything in the version control system

All novice developers know that all code needs to be stored in a version control system like GIT or SVN. But at the same time, they often forget about other things that should also be backed up:

1. crontab. Imagine the situation - on the project 20 cron-tasks, and, suddenly, something happened to the server. The code and database in our backups, we are great. But for what time it was what crown - you have to remember, because we did not store it anywhere else
2. Web server settings are different from the default. If any special settings are necessary for the web server to work, it is necessary to store this information somewhere, otherwise the next time you move / reconfigure / change the developer, a lot of time will be spent again
   
3. binary dependencies that need to be set by hand. The following is often encountered: the project uses, for example, memcached - but this is not written anywhere. The next developer will definitely be delighted when searching for everything you need to run. Of course, you don’t need to push the binaries into GIT, but it’s great to leave a file like README.

7. Do not use products like phpMyAdmin on an ongoing basis.

This is generally a popular moment. Especially on shared-hosting. What is so bad: security problems (are you sure that tomorrow there will be no vulnerabilities in such a product?), Reliability issues (web server crashes — no way to reach the database), convenience problems (need to feed a big backup? It's a long time. Plus web server configs need to rule). Solution - use a direct connection to the database, preferably via an SSH tunnel, without leaving the port open directly.

By the way, it intersects with point number 2 - bots are looking for the first one to open phpMyAdmin (immediately after wp-admin.php)

8. Do not remove anything as long as possible.

This is the so-called soft-delete approach. You have a good system in which the user can download files, and can delete. Before deleting, you have three questions in the style of "And do you really want to delete the file?" You are sure that the user will not be able to delete anything accidentally. Believe - can. Therefore, if you have no competitor facebook, and you do not need to work with terabytes of files / messages - do not delete anything once again. Sooner or later it will come in handy.

9. Do not believe your eyes

Sometimes there are cases that are completely unsettling. You clearly see one thing - and the code says the opposite. You see at the output of 4 characters - and the code considers them as 9. The fault is the invisible characters. Especially critical when working with some PDF files or something like when everything looks good - the parser swears. Well, or colleagues joked and threw an invisible symbol in the code while you were away for a _{nice debag!} There may also be similar problems with multibyte encodings.

The solution - yes it is not as such, you just need to know about the opportunity, and this will already save you a lot of time in this situation.

10. Write the code politely

And finally, a little funny advice. Do not use for debug what you should not show to the client. Sometimes, well, I really want to zadabazhit code with something like

 if(everythingIsBad()){ die('FUCK'); } 

But, similar to advice number 3 - do not bewilder yourself with illusions “I will never forget to remove the debug code”. Otherwise, when it comes out on a production site, it will be very awkward to explain what it is and why it flaunts on the main page.

At one time, these tips would save me a lot of time and effort. I hope someone will find them useful for themselves, and even better - add them in the comments.