10 (не) очевидных советов начинающим WEB-разработчикам +25

В интернете уже есть полно книг, статей, да и тех же постов на хабре для начинающих. Но, как по мне, то существует ряд нюансов которые обычно или вообще не упоминаются (видимо, их считают очевидными), либо же упоминаются очень редко. И это не советы из серии «изучайте код других разработчиков», «используйте 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-сайте — будет очень неловко объяснять что это и почему оно красуется на главной странице.

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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (72):

  1. Softer
    /#11369146 / +1

    1. Для себя с делал такую схему (прошу помидорами не кидаться, это pet-ptoject :) ):
    * В движке (в моем случае — PhalconPHP) есть метод который отдает случайное число (генерит новое, сохраняя его в memcached, или сразу достает оттуда если оно уже сохранено).
    * В шаблонах прописано что-то вроде

    <script src="/script.js?v=<?=$STATIC_VER?>"></script>

    * В админке есть кнопка «Сброс статик-кеша» которая банально киляет элемент из мемкеша. Причем даже к CI прикрутить не сложно.
    работает уже года 4, если не 5 сбрасывая как кеш браузера так и кеш nginx-а на фронте.

    • vlreshet
      /#11369174

      ИМХО — нормальное решение, я бы помидором не кинул)
      надо и себе такое к laravel прикрутить

      • Softer
        /#11369176

        Ну мало ли — щас набегут любители «продвинутых систем сборки и деплоя frontend-а»… :)

        • vlreshet
          /#11369180

          Cо словами «а наааам в webpack-е для такого надо всего-лишь поставить три плагина и написать небольшой конфиг!» :D

          Шутки шутками, а не стрелять из пушки по воробьям не люблю) У самого проект на самом новом laravel — но статика работает «по-классике», без изворотов.

          • SerafimArts
            /#11369246

            В Laravel это идёт из коробки. Достаточно просто создавать json файлик манифеста или воспользоваться их mix'ом, который сам его генерирует.

          • kinjalik
            /#11370984 / +1

            Для генерации рандомного числа в webpack даже плагины не нужны — можно в выходной файл встроить хэш этого файла — scripts.[hash].js

          • Fesor
            /#11371364

            но статика работает «по-классике», без изворотов.

            Есть масса людей которые деплоят проекты по классике, через git, без изворотов.

            • NickyX3
              /#11372140 / +1

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

              • vlreshet
                /#11372284

                По-классике и олдскульно это не поверх ssh, а через FTP (именно FTP, не SFTP), в блокноте.

        • kalininmr
          /#11369656

          ну… есть решения покрасивше.
          я для шаблонизатора сделал тег который вставляет время изменения файла.
          пишу
          {% fmodts "/res/script.js?v={ts}" %} получаю /res/script.js?v=1527110460
          наверное лучше было сделать фильтром

          • Softer
            /#11369666

            Я тоже думал про mtime, но каждый раз дергать медленный диск… (да, про дисковый кеш знаю, но все же...)

            • kalininmr
              /#11369688

              а он не каждый раз проверяется.
              только при первой компиляции шаблона.
              то есть если воркер перезапустился(кнопкой или по лимиту).

              • Softer
                /#11369702

                Вот. Шаблона. В моем же случае вся статика — вынесена на отдельный домен и отдельный репозиторий. Равно как и View от Phalcon'а. И для того чтобы обновить статику мне нужно обновлять шаблоны? Как-то не оптимально выходит, ИМХО…

                • kalininmr
                  /#11369708

                  они пересобираются при каждом запуске воркера.
                  тоесть надо перезапустить воркеры или подождать, они там периодически перезапускаются.

      • Fedcomp
        /#11369866 / +1

        в laravel уже проще некуда mix который идет из коробки. Но полагаю в среде php костыли изживаются годами.

      • polearnik
        /#11370266

        в ларавеле есть mix () Зачем вам костыли и велосипеды? а еще лучше использовать github.com/Elhebert/laravel-sri тут вам и хэши для безопасности

    • Graphite
      /#11369440 / +3

      Насколько я помню все современные HTTP серверы поддерживают уже много лет If-Modified-Since привязанный к mtime. Т.е. при обновлении файла на диске сервер начнет вместо 304 отдавать 200 с новой Last-Modified. Есть причина этим не пользоваться?


      Почему-то именно у php разработчиков я постоянно вижу совет добавить дату или случайное число для обновления кэша на клиенте.

      • ellrion
        /#11369566 / +1

        Обычно на nginx ставят для статики метку кэша очень большую. И тогда на сервер даже запросы не идут.

      • paw-p
        /#11369578 / +1

        Причина неиспользования может быть в том, что есть еще заголовок Expires. Он указывается время, до которого контент трактуется как свежий. И только по истечении этого времени производится валидация контента заголовками If-Modified-Since или If-None-Match. Т.е. пока у вас не истекло время Expires браузер будет использовать закешированную версию и единственный метод сбросить кеш — указанный в статье, т.е. поменять сам URL.

        • superconductor
          /#11370286

          Есть заголовок cache-control, которым можно гибко настроить когда и зачем клиенты будут ходить на сервер. Самое тупое no-cache по действию эквивалентно совету из статьи, но лучше проставить must-revalidate и добавить etag.

          • vlreshet
            /#11370288

            no-cache по действию эквивалентно совету из статьи
            Прочитайте внимательно ещё раз. no-cache — это не использовать кеш вообще. Совет из статьи — способ для единоразового сброса кеша. Как в браузере почистить, то же самое. Таймштамп генерируется не каждый раз, а только один раз, вручную, при изменении кода.

            • superconductor
              /#11370304

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

      • AlexanderY
        /#11369920

        Лет 5 назад наткнулся на неприятный баг в Safari. Были настроены заголовки на веб-сервере. Все браузеры их учитывали, даже IE. А вот Safari игнорил — брал файлы из кэша, пока вручную его не почистишь. Поэтому пришлось использовать костыль в виде get-параметра.

    • ilyaplot
      /#11370560

      <script src="/script.js?v=<?=md5_file(__PATH_TO_SCRIPT_JS)?>"></script>


      В таком случае изменять script.js можно с любой частотой, не задумываясь о версии. Если изменилось содержимое, измениться и хэш

      • sumanai
        /#11370638

        Ага, и либо перечитывание файла каждый раз при запросе, либо тот же кеш, только в другом месте.

  2. Melkij
    /#11369178

    Иногда минорная версия какого-нибудь софта (вроде php 7.0 на проде и 7.2 локально)

    Это очень даже major версия. И совершенно легально поведение может быть изменено. Вот в действительно минорных релизах (это 7.0.х, 7.2.х и т.д.) — редкость.

    А вообще совет — поинтересуйтесь политикой нумерования используемого у вас ПО. Бывают интересные фокусы, вроде mysql, где первый стабильный релиз 8.0 ветки — это внезапно 8.0.11. А более ожидаемый 8.0.0 — это dev версия. Аналогично первый стабильный 5.7 был за номером 5.7.9. Сообщество PHP же отдельно выделяет 7.2rc, 7.2beta, а 7.2.0 — готовый первый релиз.

    • SirEdvin
      /#11369286 / +2

      Вообще-то, согласно нормальной semver терминологии — вторая цифра это минор, а третья — патч.

      • youngmysteriouslight
        /#11369300 / +1

        Насколько я понял, смысл комментария был в том, что если софт не использует semver, рассчитывать на поведение в соответствии с семверной терминологией не стоит.
        В т.ч. вторая цифра может указывать обратнонесовместимые мажорные изменения.

      • Melkij
        /#11369314

        Вот поэтому и совет поинтересоваться политикой нумерации каждого используемого ПО.
        Для php актуально по-прежнему, mysql до 8.0, postgresql до 10.0, да и ядра linux до 3.0 тоже — major версия нумеруется первыми двумя цифрами, minor — третья. Так переход php 7.1 к 7.2 — major change, включая incompatible API change.

      • VolCh
        /#11371592

        Это не стандарт. Некоторые вендоры приходят к нему, а некоторые нет.

  3. Akdmeh
    /#11369240 / +4

    11. Изучайте систему, на которой работают серверы. Вы должны понимать Linux. Если работаете с PHP — должны понимать, что делает nginx, php-fpm, почему в 2k18 можно жить без Apache
    12. Читайте ru.highload
    13. Если PHP — читайте как Библию «PHP: The Right way»
    14. Изучите, что такое тестирование и начинайте его применять как можно скорее. В частности, обратите внимание на Codeception
    15. Прежде чем написать любую библиотеку — потратьте несколько минут и изучите, не существует ли уже такой (немаловажно, проверьте, чтобы она поддерживалась и развивалась). Библиотеки обычно написаны с учетом многих багов серверов, браузеров, устройств и позволят вам не натыкаться на них самостоятельно.
    16. Нет. Ваш собственный фреймворк не будет работать лучше и быстрее. Изучите существующий фреймворк, а лучше два-три. То время, которое вы потратите на поддержку и переписывание своего фреймворка в новых условиях и на написание библиотек под него — можно потратить на написание реальных проектов.
    17. Пишите без ошибок. Ваш код не должен выбрасывать ни малейших notice, если они возникают — учитесь их сразу же устранять.
    18. Работа с сайтом через браузер — не единственный канал общения с приложением. Изучите, как запускать приложения в консоле и какие преимущества это вам предоставляет.

  4. wirtwelt
    /#11369280 / +1

    Супер! Сразу два совета прям в руку ) Категорически благодарен и желаю вам всяческих успехов, здоровья и хорошего настроения

    Разрешите вопрос от новичка с восьмилетним стажем колхозного веба )
    Извиняюсь, долгое время беспокоит как раз решение по совету 3, то есть развертывание обновлений и окружения. В интернете много информации, всякие докеры и прочее. По факту все выглядит для меня слишком страшным и новомодным, временами ненадежным.

    Если не трудно, посоветуйте, что почитать или куда посмотреть по развертыванию обновлений, при условии двух задач: 1) что-то быстро вот прям сейчас поправить, вроде опечаток, кнопок или оформления страниц и 2) залить большую страшную фичу/раздел сайта, со своим кодом и таблицами в БД.

    Сейчас просто «git push» и «git pull» на master. Это еще терпимо, но с базой все очень плохо — ручное обновление, создать таблицу, поправить ключи, прописать индексы. Жуть. Не научно, криво, косо, бесит, но как лучше сделать — все руки не доходят найти и прочитать, и главное — внедрить в уже работающие на старой схеме проекты, не поломав ничего

    • zharikovpro
      /#11369360 / +1

      Про базу посмотрите словосочетание «database migrations tool». Вот пример инструмента. Если используете популярные фреймворки типа Laravel, в них работа с миграциями БД уже встроена, смотрите доки.

      • wirtwelt
        /#11369504

        Спасибо, посмотрю. Интереснее не база, а чтоб прям целиком, код и база, поэтому упомянул docker, но как им практически пользоваться для этой цели я пока не понял

        • zharikovpro
          /#11369562

          Это очень общий вопрос. В чем конкретно трудность? Накатили код, провели миграцию. Или провели миграцию, накатили код. Выбирайте любой порядок. Бывает правда что для некоторых случаев нужно писать код, который умеет работать (хотя бы временно) со старой и новой версией базы на момент переключения. Но это отдельная история, все сильно зависит от ваших задач.

        • IgorSaf
          /#11370316

          Делаю следующим образом — миграции для БД используются встроенные во фреймворк, хранятся вместе со всем остальным кодом в репо. Сразу после git pull на сервер делается что-то в духе php index.php migrate (накатывается миграция). Таким образом и код, и БД поддерживаются актуальными в две строки в консоли

    • vlreshet
      /#11369474

      Пожалуйста, рад что пригодилось! :) А какие советы «прям в руку»?)

      • wirtwelt
        /#11369518

        1 — буквально на прошлой неделе был косяк с кешированным JS, кнопочки у клиента не нажимались, я знал про прием, но не использовал
        3 — обсуждали повышение мощности сервера, но develop и production лежат на одной машине, и базы просто названием отличаются, ваш совет очень кстати получился
        7 — спустя полгода после старта проекта до сих пор в корне лежит myadmin )) под Basic Auth, но тем не менее

        Отчасти еще 8, но тут много спорных моментов, удалить vs скрыть, спорить не берусь, согласен на 80% что в подавляющем большинстве случаев выгоднее скрыть, не удаляя безвозвратно данные

  5. batment
    /#11369298 / +1

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

    Мало того, даже с разными серверами на разных URL можно подумать, что находишься в админке на стейджинге, и сделать что-то плохое. Такую проблему проще всего решить какой-нибудь явной меткой, например плашкой DEV / PROD где-нибудь на видном месте.

    • vlreshet
      /#11369632

      Лично я себе в stylish прописал правило для продакнш-адреса. На нём всё дико красное, и не заметить это не возможно.

    • kost
      /#11369830

      Я делал favicon.ico разных цветов для dev/stage/prod серверов.

  6. Samouvazhektra
    /#11369404

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

    Но при этом важно не палить токены/пароли

    • vlreshet
      /#11369480 / +2

      А тут простое правило — конфиг никогда не коммитится. Можно хранить примеры конфигов в гите, но сами конфиги — нет.

      • Softer
        /#11369684

        Коммит конфига — не самое страшное…
        А вот когда «разработчик» пишет В КОНФИГЕ что-то вроде

        if ($server_hostname == "MyLovelyTest") {
        // Тут настройки
        }
        elseif ($server_ip == "127.0.0.1")
        {
        // Тут настройки локалхоста
        }
        else
        {
        // Настройки прода
        }
        

        причем все в гите, с захардкожеными путями (и доменами) и в файле с названием вроде ClassLoader.php… Убивать хочется просто от воспоминания…

        • vlreshet
          /#11369742

          Ууух, круто будет запустить это на локальной машине ($server_hostname != «MyLovelyTest»), да на правильно настроенной виртуально машине ($server_ip != «127.0.0.1»).

          Жесть конечно, не поспорить.

      • Fedcomp
        /#11369868

        конфиги очень даже комитятся, они просто данные из ENV подсасывают.

      • YemSalat
        /#11370586

        Альтернативный вариант — использовать в конфиге ENV переменные.
        (Упс, не обновил страницу — опередили :)

  7. achekalin
    /#11369692

    приятного дебага!

    Хорошая пасхалка, спасибо!

  8. artemt
    /#11369694 / +5

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

    Давным давно, в незапамятные времена устроился я в некую контору, разрабатывающую сайт по заказу авиабилетов. Вышел в первый день на работу. Сразу задание — поправить хранимку в базе.
    — Разработка у нас ведётся на продакшн базе данных, — сразу огорошил тимлид.
    — Так как же работать? — удивился я.
    — Аккуратно. Всё-таки, там люди билеты заказывают…
    Тут я испугался.


    Через месяц я ошибся. Передал не тот параметр в html форме и вместо редактирования организации проскочило удаление. Пошёл глянуть в базу и захолодело. На таблице организаций стояло каскадное удаление сотрудников. А на таблице сотрудников каскадное удаление авиабилетов. Сразу обратился к тимлиду.
    — Ерунда, — ответил он — Эта организация фейковая, для опытов.
    Потом подумал и глубокомысленно произнёс — Надо бы бэкап базы сделать.
    — А когда последний раз делали? — наивно спросил я.
    — Полтора месяца назад…
    Вот здесь мне по настоящему стало страшно.


    Как-то подвис рабочий комп. Я кнопку жёсткой перезагрузки нажал, а на мониторе ничего не происходит. Нажал ещё раз. Смотрю, что-то народ суетится.
    — Что такое? — спрашиваю.
    — Продакшн сервер упал! — отвечают.
    — А где он?
    — Да вот же, слева от твоих ног.
    — А где мой рабочий комп?
    — Справа от твоих ног...


    Два месяца там проработал. Стивена Кинга с тех пор без улыбки читать не могу.

    • vlreshet
      /#11369746

      А вы не интересовались, в чём была мотивация такого странного подхода?)) Не то чтобы этому могло быть хоть какое-то адекватное оправдание — тут просто интересно. Ладно бекапы не делают, ладно сервер под ногами стоит… но поднять тестовую базу — это же раз плюнуть…

      • artemt
        /#11369782

        Нет, не спросил. Сразу ошалел, что в первый же день на продакшн отправили. А потом сработал эффект "здесь так заведено".


        А "заведено" было странно. Нельзя читать новости на рабочем месте. Пусть так. Но мне сделали замечание, что я MSDN читаю...

      • artemt
        /#11370220

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


        Нужно было поднять бэкап базы для правки легаси проекта. Я автоматически назвал базу ХХХ_dev. И тут прилетел привет от бывшего коллеги. Он где-то в коде использовал имя базы и она должна называться именно ХХХ, Sic! Так как там production и developer сервера различались, то я просто плюнул и назвал ХХХ.

  9. springimport
    /#11369758

    Хорошо быть новичком :)
    Вот бы такие понятные и определенные советы для сложных вещей, а то как посмотришь — у той технологии такие минусы, у той — другие и во весь рост встает выбор из меньших зол.

  10. f0rk
    /#11369780

    Мне вот интересно, любители добавлять таймстампы в урлы считают, что разработчики браузеров придумали кеширование чисто из вредности?


    Для справки, в девтулзах в хроме есть галочка "disable cache".

    • vlreshet
      /#11369790

      А всех пользователей вы тоже попросите эту галочку поставить?

      А вообще вы, видимо, не уловили суть. Таймштамп ставится один раз — при изменении файла. То есть кеш сбрасывается только один раз. Так что разработчики браузеров не зря старались кеш продолжает работать. А таймштамп в ссылке — всего-лишь способ инвалидировать (обновить) кеш.

      • f0rk
        /#11369816

        А всех пользователей вы тоже попросите эту галочку поставить?

        У них пусть по ttl инвалидируется, в большинстве ситуаций — это ок.


        Таймштамп ставится один раз — при изменении файла.

        Да, наверное прочел невнимательно, но я бы ограничился только выкаткой критичных фиксов таким образом.


        Меня просто что-то стригерило, наверное потому что много раз видел именно в шаблонах фигню типа "script.js?" + now()

        • vlreshet
          /#11369828

          «script.js?» + now() — ну это дичь, само собой. Об этом речи не идёт

          критичных фиксов таким образом.
          Ну, мне кажется редко бывают случаи некритических изменений. Если это багфикс (любой) — его нужно распространить как можно быстрее всем. Если это новая фича — под неё уже наверняка написан html, так что нужно выкатить тоже оперативно. Разве какой-нибудь лёгкий редизайн, или вроде того… Но, опять таки, если у нас не проект на миллион пользователей в день (которые могут и сервер положить, если все одновременно пойдут свежий скрипт тянуть) — то я бы обновлял таким путём все изменения. Другое дело что если из 10 скриптов на проекте обновили только один — то, наверное, нет смысла обновлять кеш и остальным (в случае глобального таймштампа на всю статику в проекте).

          • f0rk
            /#11369834

            могут и сервер положить

            на больших проектах скрипты в cdn лежат, но уменьшать счета за трафик — безусловно благое дело :)

  11. f0rk
    /#11369832

    del

  12. neurocore
    /#11369944

    «9. Не верьте своим глазам» — вообще универсальное правило для любого программиста. Наши органы восприятия неидеальны и нужно принимать это как данность. Поэтому всегда нужно перепроверять свой код различными способами: отладка, тесты, подсадить коллегу с вопросом «что здесь написано?»

  13. qrck13
    /#11370022

    Вместо «FUCK» отлично подойдет что-то маскирующее вроде «REMY SPEAK» (https://www.youtube.com/watch?v=NVOL3tMDzEs)

  14. Bloodshark
    /#11370278

    Ещё совет: изучите как работает linter.
    А встроенный линтинг в редакторе сэкономит кучу времени, де-факто подсказав о незакрытой скобке или другой случайной опечатке.

    • zzzmmtt
      /#11370440

      Либо сразу юзайте нормальную IDE

  15. tinoajato
    /#11370280

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

    Да. Работало так год на одном серваке, пока не уговорил начальника сделать по нормальному. Буквально через месяц случайно сломал dev, хотя был очень аккуратен. Бэкапы делаются, вроде не страшно, но нервы сильно потрепало бы восстановление…

  16. artiom_n
    /#11370394

    10 (не) очевидных советов начинающим разработчикам

    Вы считаете, что разработка ограничивается WEB?

    • vlreshet
      /#11370678

      Резонное замечание. Исправил заголовок

  17. oxidmod
    /#11370646

    IMHO, обычно достаточно корректных заголовков и CDN-a

  18. Raftko
    /#11370902 / +1

    Восьмой совет «Не удаляйте ничего» может быть неправильно истолкован. Не превращайте проект в помойку. Всякие index.php1,index.php2,index.phpBK,__index.php и прочие старые версии файлов, для них есть системы контроля версий. Закомментированные куски «авось пригодится» туда же. Старые классы, функции, которые «да это старая реализация, сейчас уже новые функции везде используются». Всё удалять. Только перед этим убедитесь, что действительно нигде не осталось старой зависимости:)

    • zzzmmtt
      /#11371590

      Насколько я понял автора, речь не о коде, речь о пользовательских файлах (аватары, документы, музыка, etc).

    • t_kanstantsin
      /#11371654

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