https://habr.com/post/359168/

• Разработка веб-сайтов
• PHP

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

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

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

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

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

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

<script src="/script.js?v=%текущая дата%"></script>
// вместо
<script src="/script.js"></script>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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