Pull to refresh

13 антисоветов разработчику, желающему написать хороший веб-сайт

Reading time 4 min
Views 3.8K
Привет, разработчики на хабре!

Этот шуточный пост составлен из проблем, с которыми приходится сталкиваться практически постоянно при сопровождении больших и серьезных сайтов.
Это не пост ненависти! Это призыв к прекращению траты своего и чужого времени на исправление неочевидных при первоначальной разработке и использовании проблем.

1. Не проставляйте ключи!


СУБД пишут умные люди. Некоторые из них даже получают за это деньги. Зачем подсказывать им, как устроены данные? Пускай догадываются сами из названий полей и самих данных. В крайнем случае, админы поправят профайлером.


2. Используйте строковые PK вместо числовых!


Ведь использовать 12345 — некрасиво и небезопасно! Намного красивее и безопаснее — 098f6bcd4621d373cade4e832627b4f6. И ни в коем случае не стоит создавать таблицу соответствия строка->int и пользоваться номером в остальных таблицах! СУБД интереснее выбирать по строке, чем по какому-то сухому, скучному и непонятному числу.
Кстати, строку надо генерировать как md5() от ip-адреса клиента, текущего времени и Вашего ника. Пользователи NAT'a поблагодарят.

3. Не используйте таймауты!


Кластер большой, под него выделены дорогие и мощные сервера. Память стоит копейки. Пара процессов там могут подождать и вечность, пока не откликнется введенный пользователем URL. В крайнем случае, система убьет скрипт за слишком долгое время исполнения.

4. Используйте system()!


Это гарантирует Вам переносимость — вдруг кто-то из команды разработчиков языка решит удалить используемую Вами функцию? А консольные аналоги всегда останутся при Вас. Кроме того, несколько форков на обработку запроса — это столько интересной работы планировщику!

5. Не думайте об алгоритмах!*


Если Вам надо найти что-то в отсортированном массиве — пройдитесь по нему по порядку! Больше данных увидите. Тем более, бинарный поиск как-то непонятно работает. Если Вам надо найти подстроку в строке — просравнивайте все, с начала до конца! Странные линейные алгоритмы могут ошибаться.
* На самом деле, надо правильно выбрать баланс между написанными в стандартной библиотеке неэффективными алгоритмами и написанием своего кода. Если Ваша реализация эффективного займет больше трех страниц кода, то надо использовать именно ее, меньше — готовую функцию.

6. Кладите информацию в файл!


Конечно, есть СУБД, но и она неидеальна: просит какие-то странные команды. Нет, чтобы просто дать контент! Обычные файлы намного лучше. Да и админу будет интереснее поднимать кластер с rw /home на кластерной ФС, чем с ro /home на обычной.
Напротив, картинки надо класть в базу и отдавать скриптом — как же тогда контроллировать безграничное скачивание статики?

7. Пользуйтесь модулями, заброшенными в 2006 году!


Действительно, что с тех пор изменилось, да и вообще, изменится? Внутренний API — вещь стабильная. Ну а если там были какие-то изменения, то команда с удовольствием их изучит и получит полезные знания, заставляя этот модуль скомпилироваться и заработать.

8. Пишите рерайты!


Много рерайтов! Пишите изящные, занимающие два экрана инструкции апачевскому mod_rewrite с обратной логикой, RewriteCond'ами и специфичными особенностями. Никогда не сопоставляйте префикс какому-то отдельному скрипту. Веб-серверу интересно матчить каждый запрос по сотне регекспов, выделять в них что-то и вызывать Ваши программы. А админу интересно переписывать их в нормальный вид и на другой веб-сервер.

9. Для авторизации и сессии используйте одну и ту же куку!


Вообще, любой порядочный скрипт должен начинаться с session_start(). Если пользователь авторизовался, то об этом надо сделать пометку в $_SESSION. Пускай фронтэнд сам догадывается, отдавать кешированный ответ, или идти к Вашему скрипту.

10. Обижайтесь, когда Вас не пускают на продакшн!


Вы достаточно хорошо умеете программировать, чтобы править сайт на работающем сервере. На работающем сервере нет FTP? Надо поставить! Работающих серверов несколько? Так за счет пункта 6 Вам поставили кластерную ФС! Код надо тестировать перед публикацией? Ну вылетит ошибка, сразу поправите!
Не используйте систему управления версиями. Откатываются из бекапов, а не из непонятных программ.

11. Не выносите код за пределы DocumentRoot!


Всякие ваши cgi-bin придумали странные глупые люди, которые ничего не понимали в сайтах. Намного лучше, когда выполняется не все из cgi-bin, а все из /, соответствующее регекспу ~ \.php. Не забудьте о замечательной фиче, как path_info — ведь это круто, когда скрипт выглядит как папка! А с тем, чтобы upload/avatar.php.jpg не запускался, как-нибудь разберется и админ.

12. Выполняйте долгие действия внутри клиентского запроса!


Памяти у сервера много, времени у клиента — тоже. Так почему бы не заресайзить 100 картинок из resize.php, запрашиваемого пользователем? Буферизация, не дающая выводить по одной точечке на фотографию? Кривой сервер. Клиентские таймауты? Кривой клиент. Очередь долгих операций — слишком накладно и непонятно клиенту.

13. Не используйте средства вебсервера!


Его писал непонятно кто, мог набажить. Если Вам надо отдать клиенту файл с ограничением по скорости и проверкой куки, забудьте о X-Accel-Redirect+X-Accel-Rate-Limit/X-Sendfile! Отдавайте его своим скриптом, в цикле, по кусочкам. Для ограничения скорости используйте sleep(). Если Вам надо проверить, что картинки не личатся, зарерайтите их на свой скрипт и отдавайте их только после проверки реферера.

Disclaimer


Советы относятся к написанию серьезных сайтов под заказ. Конечно, если Вы пишете OpenSource-CMS/скрипт для широкого пользования, то этими советами пользоваться не нужно.
Я буду рад выслушать любые предложения или дополнения к этим советам, и даже поспорить об их правильности.

Не знаю, в какой блог правильнее разместить, разместил в PHP, так как советы, в основном, относятся к писателям на этом языке.
Tags:
Hubs:
+24
Comments 101
Comments Comments 101

Articles