13 anti-tips to the developer who wants to write a good website

Hi, developers on Habré!

This comic post is made up of problems that one has to face almost constantly when accompanied by large and serious sites.
This is not a post hate! This is a call to stop spending your and other people's time on correcting problems that are not obvious at the initial design and use.

1. Do not put down the keys!

DBMS is written by smart people. Some of them even get paid for it. Why tell them how the data is arranged? Let them guess themselves from the names of the fields and the data itself. In the extreme case, admins correct profiler.

')

2. Use string PK instead of numeric!

After all, using 12345 is ugly and unsafe! Much prettier and safer - 098f6bcd4621d373cade4e832627b4f6. And in no case should you create a string table-> int and use the number in the other tables! DBMS is more interesting to choose by the line than by some dry, boring and incomprehensible number.
By the way, the string must be generated as md5 () from the client's ip-address, current time and your nickname. NAT users will thank.

3. Do not use timeouts!

The cluster is large, with expensive and powerful servers allocated for it. Memory costs a penny. A couple of processes can wait there for an eternity until the URL entered by the user responds. In extreme cases, the system will kill the script for too long a execution time.

4. Use system ()!

This guarantees portability to you - what if someone from the language development team decides to delete the function you use? And console analogs will always remain with you. In addition, a few forks to process a request are so much interesting work for the scheduler!

5. Do not think about algorithms! *

If you need to find something in a sorted array, go through it in order! More data will see. Moreover, the binary search works somehow incomprehensibly. If you need to find a substring in the string - align everything from beginning to end! Strange linear algorithms may be wrong.
* In fact, it is necessary to choose the right balance between inefficient algorithms written in the standard library and writing your own code. If your effective implementation takes more than three pages of code, then you need to use it, less - a ready-made function.

6. Put the information in the file!

Of course, there is a DBMS, but it is also not ideal: it asks for some strange commands. No, just to give content! Regular files are much better. Yes, and the admin will be more interesting to raise a cluster with rw / home on a cluster file system than with ro / home on a regular one.
On the contrary, the pictures should be put in the database and given away by the script - how can you control the unlimited downloading of statics?

7. Use modules abandoned in 2006!

Indeed, what has changed since then, and indeed, will change? The internal API is stable. Well, if there were any changes, the team would be happy to study them and get useful knowledge, forcing this module to compile and make money.

8. Write rewrites!

A lot of rewrites! Write elegant, two-screen instructions to the Apache mod_rewrite with inverse logic, RewriteCons and specific features. Never match the prefix to any separate script. It is interesting for the web server to match every request by hundreds of regexps, to allocate something in them and to call your programs. And the admin is interesting to rewrite them in a normal form and on another web server.

9. For authorization and session, use the same cookie!

In general, any decent script should start with session_start (). If the user has logged in, then you need to make a mark about it in $ _SESSION. Let the frontend guess, give a cached answer, or go to your script.

10. Be offended when you are not allowed into production!

You know how to program well enough to edit the site on a running server. Is there no FTP on the running server? Must put! Are there several working servers? So at the expense of point 6, you have put a cluster FS! Should the code be tested before publishing? Well, the error will take off, immediately correct it!
Do not use a version control system. Rollbacks from backups, not from obscure programs.

11. Do not take code beyond DocumentRoot!

All your cgi-bin came up with strange silly people who did not understand anything in the sites. It is much better when not all of cgi-bin are executed, but all of / corresponding to the regexp ~ \ .php. Do not forget about a great feature like path_info - it's cool when the script looks like a folder! And so that upload / avatar.php.jpg doesn't start, somehow the admin will figure it out.

12. Perform long actions inside the client request!

The server has a lot of memory, the client time too. So why not download 100 images from resize.php requested by the user? Buffering, not allowing to display one dot on the photo? Curve server. Client timeouts? Curve customer. The queue of long operations is too expensive and incomprehensible to the client.

13. Do not use web server tools!

He wrote it is not clear who could incriminate. If you need to give the client a file with a speed limit and check cookies, forget about X-Accel-Redirect + X-Accel-Rate-Limit / X-Sendfile! Give it to your script, in a loop, bit by bit. To limit the speed, use sleep (). If you need to check that the pictures are not personal, download them to your script and give them only after checking the referrer.

Disclaimer

Tips refer to writing serious sites for the order. Of course, if you are writing an OpenSource-CMS / script for public use, then these tips do not need to be used.
I will be glad to hear any suggestions or additions to these tips, and even argue about their correctness.

I don’t know which blog is the most appropriate to post in PHP, since the advice mainly applies to writers in this language.