Советы начинающим web-разработчикам

Mykola Sarry -

В интернете уже есть полно книг, статей для начинающих. Но, как по мне, то существует ряд нюансов которые обычно или вообще не упоминаются (видимо, их считают очевидными), либо же упоминаются очень редко. И это не советы из серии «изучайте код других разработчиков», «используйте git», «делайте бекапы» или «мойте руки перед походом в production-консоль». Это обыденные, практические вещи, которые приходят с некоторым опытом. Часть из них не пригодится если вы используете самые современные подходы к разработке, часть из них универсальны. В этом посте выражен опыт PHP разработчика, но на самом деле множество пунктов подходят и к другим стекам разработки.

Если вы начинающий веб-разработчик — добро пожаловать под кат, Senior-ы вряд ли найдут там для себя что-то новое

Сбрасывайте кеши статических файлов

Очевидная вещь, однако с данной проблемой часто стыкаются начинающие разработчики. Далеко не все используют продвинутые системы сборки и деплоя frontend-а, а поэтому много где работает старый добрый подход вроде

Нет, в этом нет ничего плохого, всё работает и будет работать. Проблема же возникает при изменении этих файлов. Разработчик делает изменения, заливает на прод, отписывает заказчику. Заказчик проверяет — и говорит что у него ничего не работает. А всё почему — потому что его браузер держит в кеше старую версию файлов. И у всех остальных пользователей — то же самое. Банально? Конечно! Но наступают на эти грабли очень часто. Решение простое — добавлять случайный GET параметр. Например:



// вместо

перед каждым коммитом изменённого файла. Веб-сервер просто проигнорирует этот параметр, а вот браузер потянет файл заново, потому что url изменился.

Не храните важные файлы в публичной директории

Распространённая схема: «сделаю code.backup.zip в корне, выкачаю, и удалю. Я же быстро, кто там знает что есть такой файл». Проблема же заключается в том, что практически все сайты время от времени сканируют боты, которые тупо перебирают очевидные ссылки вроде /update.sql, /backup.sql, /config.php.bk, итд. Вариантов в их базе — сотни. Поэтому такое оставление файлов «по-быстрому» в открытом доступе может легко выйти боком. А оставлять их на постоянной основе — так точно вылезет.

Если уж очень припекло — создавайте файлы с абсолютно случайными именами. Но лучше вообще так не делать. Не стоит быть неуловимым Джо.

Development и Production сайты — это всегда разные серверы

Подход при котором на одном сервере крутится и production и development сервер тоже часто встречается. Иногда, при особой упоротости, совпадают даже ключи поключения к БД (которые тоже на одном сервере), и отличаются только название баз. Чем чревато:

Перепутать, и натворить делов на «боевой» системе. Не тешьте себя иллюзиями «да я всегда очень внимателен»
Случайно положить прод. Делал эксперименты на дев-сайте, что-то пошло не так, выжрало все ресурсы/положило БД — ОП, и у вас заодно прилёг основной сайт
Получить проблемы при обновлении версии софта на сервере. Решили перевести проект с php5.6 на 7.2? А оба сайта крутятся на одном сервере, и сделать разные версии для разных доменов — та ещё боль. Не заливать же сразу в прод, верно? Вот и возникла проблема с тестовым сайтом.

В общем, правило простое — production сайт (и его БД) — это всегда отдельный сервер.

Сверяйте локальные конфиги и конфиги сервера

В крупных проектах, где есть отдельный шаман админ, docker (или vagrant), много серверов, балансер итд — эта проблема, конечно же, не возникнет. Накатил образ окружения — и погнал. Однако посмотрим правде в глаза — много где до сих пор используют подход «обновил файл — залил через FTP», и получить такой проект начинающему разработчику — как раз плюнуть. И вот тогда возникают проблемы, когда локально всё работало, а на проде — отпало. Поэтому всегда сверяйте идентичность окружений. Иногда минорная версия какого-нибудь софта (вроде php 7.0 на проде и 7.2 локально) может всё круто сломать.

Логируйте сложные операции как можно тщательнее

Молодые (не в плане возраста — а в плане опыта) разработчики часто забывают о логах, надеясь на то что это сделает фреймворк или же веб-сервер. Так то оно так, но такие логи помогут поймать только очень грубые ошибки, вроде ошибок синтаксиса или неправильного запроса. Поэтому при разработке сложного функционала всегда пишите в логи всё что можете, это значительно облегчит жизнь в будущем. Вы же не пишете highload проект вроде конкурента Facebook, где стоит беспокоиться о потери лишней миллисекунды на запись в лог, не так ли?

Проверьте всё ли вы храните в системе контроля версий

Все начинающие девелоперы знают что весь код нужно хранить в системе контроля версий вроде GIT или SVN. Но при этом часто забывают о других вещах которые тоже следовало бы бекапить:

  1. crontab. Представьте ситуацию — на проекте 20 cron-задач, и, вдруг, что-то случилось с сервером. Код и база данных у нас в бекапах, мы же молодцы. А вот на какое время стоял какой крон — придётся вспоминать, потому что это мы нигде отдельно не хранили
  2. Настройки веб-сервера отличные от умолчания. Если для работы веб-сервера необходимы какие-то специальные настройки — обязательно надо где-то хранить эту информацию, иначе при следующем переезде/перенастройке/смене разработчика будет снова потрачена куча времени
  3. Бинарные зависимости которые надо ставить руками. Часто встречается следующее: проект использует, например, memcached — но об этом нигде не написано. Следующий разработчик обязательно будет в восторге при поиске всего необходимого для запуска. Конечно, сами бинарники пихать в GIT не надо, но оставить файлик вроде README — будет замечательно.

Не используйте продукты вроде phpMyAdmin на постоянной основе

Вот это вообще популярный момент. Особенно на shared-хостингах. Чем это плохо: проблемы безопасности (вы уверенны что завтра не найдут уязвимости в таком продукте?), проблемы надёжности (упал веб-сервер — к базе не достучаться), проблемы удобства (нужно скормить большой бекап? Это надолго. Плюс конфиги веб-сервера надо править). Решение — используйте прямое подключение к БД, желательно через SSH-тоннель, не оставляя открытый порт напрямую.

Кстати, это пересекается с пунктом номер 2 — открытый phpMyAdmin боты ищут в первую очередь (сразу после wp-admin.php)

Не удаляйте ничего как можно дольше

Это так называемый подход soft-delete. У вас есть хорошая система, в которой пользователь может загружать файлы, а может удалять. Перед удалением у вас стоит три вопроса в стиле «А вы точно хотите удалить файл?» Вы точно уверенны что пользователь ну никак не сможет удалить что-то случайно. Поверьте — сможет. Поэтому, если у вас не конкурент facebook, и вам не надо работать с терабайтами файлов/cообщений — не удаляйте ничего лишний раз. Рано или поздно это пригодится.

Не верьте своим глазам

Иногда бывают случаи которые полностью выбивают из колеи. Явно видишь что-то одно — а код говорит о обратном. Видишь при выводе 4 символа — а код считает их как 9. Вина этому — невидимые символы. Особенно критично при работе с какими-нибудь PDF-файлами или чем-то вроде того, когда на вид всё хорошо — а парсер ругается. Ну или же коллеги пошутили, и подкинули невидимый символ в код, пока вы отошли на обед, приятного дебага! Так же могут быть подобные проблемы с многобайтовыми кодировками.

Решение — да его нет как такового, следует просто знать о возможности, и это уже сэкономит вам много времени в подобной ситуации.

Пишите код вежливо

И напоследок немного забавный совет. Не используйте для дебага то что не стоит показывать клиенту. Иногда ну очень хочется задебажить код чем-то вроде


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

Но, аналогично совету номер 3 — не тешьте себя иллюзиями «я никогда не забуду убрать дебаг код». Иначе когда такое вылезет на production-сайте — будет очень неловко объяснять что это и почему оно красуется на главной странице.

Вместо заключения

Казалось бы что эти советы глупые и банальные. Но на практике я встречаю разработчиков, которые нарушают эти принципы.