Top 10 Tips For Beginning Web Developers/Designers
The Internet already has a lot of books, articles. But, as for us, there are a number of nuances that are usually or not mentioned at all (apparently, they are considered obvious), or they are very rarely mentioned.
And this is not advice from the series “study the code of other developers”, “use Git”, “make backups” or “wash your hands before going to the production console.” These are ordinary, practical things that come with some experience.
Some of them are not useful if you use the most advanced approaches to development, some of them are universal. Specifically, this post expresses the experience of the PHP developer, but in fact, many items are suitable for other development stacks.
If you are a beginner web developer – welcome to the cat, Seniors are unlikely to find there for themselves something new
1. Reset static file caches
The obvious thing, however, with this problem, often beginner developers. Not everyone uses advanced assembly systems and frontend-de-production, and that’s why a lot of good old approach works like:
<script src="/script.js"></script> <link href="/style.css" rel="stylesheet" type="text/css" />
No, there is nothing wrong with this, everything works and it will work. The problem arises when you change these files. The developer makes changes, pours on the prod, sends it back to the customer. The customer checks – and says that it does not work. And all why – because his browser keeps the old version of the files in the cache. And all other users – the same. Is it corny? Of course! But come on these rakes very often. The solution is simple – add a random GET parameter. For example:
<script src = "/ script.js? v =% current date%"> </ script> // instead of <script src = "/ script.js"> </ script>
before each commit of the modified file. The web server will simply ignore this option, 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: “We will make code.backup.zip in the root, we will download it and delete it. We quickly, who knows there is such a file. ” The problem is that almost all sites are scanned from time to time by bots that stupidly sort through obvious links like /update.sql, /backup.sql, /config.php.bk, etc.
The options in their database are hundreds. Therefore, leaving such files “in a fast way” in the public domain can easily come out sideways. And leave them on a regular basis – so it will come out right.
If it is very urgent – create files with absolutely random names. But it’s better not to do it at all. Do not be elusive Joe.
3. Development and Production sites are always different servers
The approach in which one server is spinning and production and development server is also often found. Sometimes, with special ripple, even the keys of the connection to the database (which are also on the same server) coincide, and only the name of the databases differs. That is fraught:
- Banal confusion, and mess things up on the “combat” system. Do not fool yourself with illusions “yes, I’m always very attentive”
- We did experiments on the dev-site, something went wrong, devoured all the resources/put the DB/OS, and you also had the main site
- Get problems when upgrading the software version on the server. Have you decided to translate the project from php5.6 to 7.2? And both sites are running on the same server, and making different versions for different domains – that’s another pain. Do not fill it immediately in the food, right? So there was a problem with the test site.
In general, the simple rule – production site (and its database) is always a separate server.
4. Confirm the local configurations and configurations of the server
In large projects where there is a separate administrator shaman, docker (or vagrant), a lot of servers, a balancer, etc. – this problem certainly does not arise. Enchanted the image of the environment – and drove. However, let’s face it – a lot of people still use the “updated file – uploaded via FTP” approach and get such a project to a budding developer – just to spit. And then there are problems when everything worked locally, but on the way out – it’s gone. Therefore, always check the identity of the environment. Sometimes a minor version of some software (like php 7.0 and 7.2 locally) can all break down abruptly.
5. Log complex operations as carefully as possible
Young (not in terms of age – and in terms of experience), developers often forget about logs, hoping that it will make a framework or a web server. So that’s it, but such logs will help catch only very gross errors, like syntax errors or an incorrect query. Therefore, when developing a complex functional, always write anything you can to the logs, this will greatly facilitate life in the future. You do not write a high load project like a competitor to Facebook, where you have to worry about losing an extra millisecond to write to the log, right?
6. Check whether you keep everything in the version control system
All beginning developers know that all the code needs to be stored in the version control system like GIT or SVN. But often forget about other things that should also be backed up:
- crontab. Imagine the situation – on the project 20 cron-tasks, and, suddenly, something happened to the server. The code and the database we have in backup, we are good fellows. But for some time there were some crowns – we’ll have to remember because we did not store it anywhere else
- Web server settings are different from the default. If you need some special settings for the operation of the web server – you must always store this information somewhere else, otherwise, the next time you move/reconfigure/change the developer, you will again spend a lot of time
- Binary dependencies that must be put by hand. Often the following occurs: the project uses, for example, Memcached – but this is not written about anywhere. The next developer is sure to be delighted when looking for everything you need to run. Of course, the binaries themselves do not need to be shoved into GIT, but leaving a file like README will be great.
7. Do not use products like phpMyAdmin on an ongoing basis
This is generally a popular moment. Especially on shared-hosting. Than this is bad: security problems (you are sure that tomorrow will not find a vulnerability in such a product?), Reliability problems (the web server fell – the database cannot be accessed), convenience problems (you need to feed a big backup? For a long time. Plus web server configs it is necessary to correct). The solution is to use a direct connection to the database, preferably via the SSH tunnel, without leaving the open port directly.
By the way, this intersects with point number 2 – open phpMyAdmin bots are looking in the first place (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 “Are you sure you want to delete the file?” You are certain that the user will not be able to remove anything accidentally. Believe, it can. Therefore, if you do not compete with Facebook, and you do not need to work with terabytes of files/messages – do not delete anything again. Sooner or later it will come in handy.
9. Do not believe your eyes
Sometimes there are cases that completely knock out of the rut. Clearly, you see one thing – and the code says the opposite. You see the output of 4 characters – and the code considers them as 9. The fault of this is invisible characters. It is especially critical when working with any 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 went to a nice lunch! There can also be similar problems with multibyte encodings.
The decision – yes it is not as such, you just need to know about the possibility, and this will save you a lot of time in such a situation.
10. Write the code politely
And finally a bit of funny advice. Do not use for debugging something that should not be shown to the client. Sometimes, well, we really want to debug code something like:
if(everythingIsBad()){
die('FUCK');
}
But, similarly to the advice number 3 – do not play yourself illusions “we will never forget to remove the debug code.” Otherwise, when it comes out on the production site – it will be very embarrassing to explain what it is and why it flaunts on the main page.
At one time, these tips would save us a lot of time and energy and we hope that someone will find them useful for themselves, or even better – complement them in the comments.
