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

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

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

    Ну. И что?
    Реклама
    Комментарии 101
      +2
      1. Для себя с делал такую схему (прошу помидорами не кидаться, это pet-ptoject :) ):
      * В движке (в моем случае — PhalconPHP) есть метод который отдает случайное число (генерит новое, сохраняя его в memcached, или сразу достает оттуда если оно уже сохранено).
      * В шаблонах прописано что-то вроде
      <script src="/script.js?v=<?=$STATIC_VER?>"></script>

      * В админке есть кнопка «Сброс статик-кеша» которая банально киляет элемент из мемкеша. Причем даже к CI прикрутить не сложно.
      работает уже года 4, если не 5 сбрасывая как кеш браузера так и кеш nginx-а на фронте.
        0
        ИМХО — нормальное решение, я бы помидором не кинул)
        надо и себе такое к laravel прикрутить
          0
          Ну мало ли — щас набегут любители «продвинутых систем сборки и деплоя frontend-а»… :)
            +3
            Cо словами «а наааам в webpack-е для такого надо всего-лишь поставить три плагина и написать небольшой конфиг!» :D

            Шутки шутками, а не стрелять из пушки по воробьям не люблю) У самого проект на самом новом laravel — но статика работает «по-классике», без изворотов.
              +1
              В Laravel это идёт из коробки. Достаточно просто создавать json файлик манифеста или воспользоваться их mix'ом, который сам его генерирует.
                +1

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

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

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

                    +1
                    Есть масса людей, которые кодят на боевом сервере поверх ssh, что вообще еще более по-классике и олдскульно
                      +2
                      По-классике и олдскульно это не поверх ssh, а через FTP (именно FTP, не SFTP), в блокноте.
                        0
                        Нееее, ну все же 2018 год на дворе
                          +1
                          Я уверен, что такие олдскулы будут встречаться и в 2025.
                  0
                  ну… есть решения покрасивше.
                  я для шаблонизатора сделал тег который вставляет время изменения файла.
                  пишу
                  {% fmodts "/res/script.js?v={ts}" %} получаю /res/script.js?v=1527110460
                  наверное лучше было сделать фильтром
                    0
                    Я тоже думал про mtime, но каждый раз дергать медленный диск… (да, про дисковый кеш знаю, но все же...)
                      0
                      а он не каждый раз проверяется.
                      только при первой компиляции шаблона.
                      то есть если воркер перезапустился(кнопкой или по лимиту).
                        0
                        Вот. Шаблона. В моем же случае вся статика — вынесена на отдельный домен и отдельный репозиторий. Равно как и View от Phalcon'а. И для того чтобы обновить статику мне нужно обновлять шаблоны? Как-то не оптимально выходит, ИМХО…
                          0
                          они пересобираются при каждом запуске воркера.
                          тоесть надо перезапустить воркеры или подождать, они там периодически перезапускаются.
                  +1
                  в laravel уже проще некуда mix который идет из коробки. Но полагаю в среде php костыли изживаются годами.
                    0
                    в ларавеле есть mix () Зачем вам костыли и велосипеды? а еще лучше использовать github.com/Elhebert/laravel-sri тут вам и хэши для безопасности
                    +2

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


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

                      +3

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

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

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

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

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

                        0
                        Лет 5 назад наткнулся на неприятный баг в Safari. Были настроены заголовки на веб-сервере. Все браузеры их учитывали, даже IE. А вот Safari игнорил — брал файлы из кэша, пока вручную его не почистишь. Поэтому пришлось использовать костыль в виде get-параметра.
                        0
                        <script src="/script.js?v=<?=md5_file(__PATH_TO_SCRIPT_JS)?>"></script>


                        В таком случае изменять script.js можно с любой частотой, не задумываясь о версии. Если изменилось содержимое, измениться и хэш
                          +2
                          Ага, и либо перечитывание файла каждый раз при запросе, либо тот же кеш, только в другом месте.
                        +2
                        Иногда минорная версия какого-нибудь софта (вроде 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 — готовый первый релиз.
                          +3

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

                            +2
                            Насколько я понял, смысл комментария был в том, что если софт не использует semver, рассчитывать на поведение в соответствии с семверной терминологией не стоит.
                            В т.ч. вторая цифра может указывать обратнонесовместимые мажорные изменения.
                              +1
                              Вот поэтому и совет поинтересоваться политикой нумерации каждого используемого ПО.
                              Для php актуально по-прежнему, mysql до 8.0, postgresql до 10.0, да и ядра linux до 3.0 тоже — major версия нумеруется первыми двумя цифрами, minor — третья. Так переход php 7.1 к 7.2 — major change, включая incompatible API change.
                                0
                                Это не стандарт. Некоторые вендоры приходят к нему, а некоторые нет.
                              +7
                              11. Изучайте систему, на которой работают серверы. Вы должны понимать Linux. Если работаете с PHP — должны понимать, что делает nginx, php-fpm, почему в 2k18 можно жить без Apache
                              12. Читайте ru.highload
                              13. Если PHP — читайте как Библию «PHP: The Right way»
                              14. Изучите, что такое тестирование и начинайте его применять как можно скорее. В частности, обратите внимание на Codeception
                              15. Прежде чем написать любую библиотеку — потратьте несколько минут и изучите, не существует ли уже такой (немаловажно, проверьте, чтобы она поддерживалась и развивалась). Библиотеки обычно написаны с учетом многих багов серверов, браузеров, устройств и позволят вам не натыкаться на них самостоятельно.
                              16. Нет. Ваш собственный фреймворк не будет работать лучше и быстрее. Изучите существующий фреймворк, а лучше два-три. То время, которое вы потратите на поддержку и переписывание своего фреймворка в новых условиях и на написание библиотек под него — можно потратить на написание реальных проектов.
                              17. Пишите без ошибок. Ваш код не должен выбрасывать ни малейших notice, если они возникают — учитесь их сразу же устранять.
                              18. Работа с сайтом через браузер — не единственный канал общения с приложением. Изучите, как запускать приложения в консоле и какие преимущества это вам предоставляет.
                                0
                                Супер! Сразу два совета прям в руку ) Категорически благодарен и желаю вам всяческих успехов, здоровья и хорошего настроения

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

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

                                Сейчас просто «git push» и «git pull» на master. Это еще терпимо, но с базой все очень плохо — ручное обновление, создать таблицу, поправить ключи, прописать индексы. Жуть. Не научно, криво, косо, бесит, но как лучше сделать — все руки не доходят найти и прочитать, и главное — внедрить в уже работающие на старой схеме проекты, не поломав ничего
                                  +1
                                  Про базу посмотрите словосочетание «database migrations tool». Вот пример инструмента. Если используете популярные фреймворки типа Laravel, в них работа с миграциями БД уже встроена, смотрите доки.
                                    0
                                    Спасибо, посмотрю. Интереснее не база, а чтоб прям целиком, код и база, поэтому упомянул docker, но как им практически пользоваться для этой цели я пока не понял
                                      0
                                      Это очень общий вопрос. В чем конкретно трудность? Накатили код, провели миграцию. Или провели миграцию, накатили код. Выбирайте любой порядок. Бывает правда что для некоторых случаев нужно писать код, который умеет работать (хотя бы временно) со старой и новой версией базы на момент переключения. Но это отдельная история, все сильно зависит от ваших задач.
                                        0
                                        Делаю следующим образом — миграции для БД используются встроенные во фреймворк, хранятся вместе со всем остальным кодом в репо. Сразу после git pull на сервер делается что-то в духе php index.php migrate (накатывается миграция). Таким образом и код, и БД поддерживаются актуальными в две строки в консоли
                                      +1

                                      миграции и deployer

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

                                          Отчасти еще 8, но тут много спорных моментов, удалить vs скрыть, спорить не берусь, согласен на 80% что в подавляющем большинстве случаев выгоднее скрыть, не удаляя безвозвратно данные
                                        +1
                                        В общем, правило простое — production сайт (и его БД) — это всегда отдельный сервер.

                                        Мало того, даже с разными серверами на разных URL можно подумать, что находишься в админке на стейджинге, и сделать что-то плохое. Такую проблему проще всего решить какой-нибудь явной меткой, например плашкой DEV / PROD где-нибудь на видном месте.
                                          0
                                          Лично я себе в stylish прописал правило для продакнш-адреса. На нём всё дико красное, и не заметить это не возможно.
                                            0
                                            Я делал favicon.ico разных цветов для dev/stage/prod серверов.
                                            0
                                            Все начинающие девелоперы знают что весь код нужно хранить в системе контроля версий вроде GIT или SVN

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

                                              +3
                                              А тут простое правило — конфиг никогда не коммитится. Можно хранить примеры конфигов в гите, но сами конфиги — нет.
                                                0
                                                Коммит конфига — не самое страшное…
                                                А вот когда «разработчик» пишет В КОНФИГЕ что-то вроде
                                                if ($server_hostname == "MyLovelyTest") {
                                                // Тут настройки
                                                }
                                                elseif ($server_ip == "127.0.0.1")
                                                {
                                                // Тут настройки локалхоста
                                                }
                                                else
                                                {
                                                // Настройки прода
                                                }
                                                

                                                причем все в гите, с захардкожеными путями (и доменами) и в файле с названием вроде ClassLoader.php… Убивать хочется просто от воспоминания…
                                                  0
                                                  Ууух, круто будет запустить это на локальной машине ($server_hostname != «MyLovelyTest»), да на правильно настроенной виртуально машине ($server_ip != «127.0.0.1»).

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

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

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

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


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


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


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

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

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


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

                                                          0

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


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

                                                          0
                                                          О сколько нам открытий чудных
                                                          Готовят просвещенья дух
                                                          И Опыт, сын ошибок трудных,
                                                          И Гений, парадоксов друг,
                                                          И Случай, бог изобретатель
                                                          +1
                                                          Хорошо быть новичком :)
                                                          Вот бы такие понятные и определенные советы для сложных вещей, а то как посмотришь — у той технологии такие минусы, у той — другие и во весь рост встает выбор из меньших зол.
                                                            0
                                                            Ну, мне кажется все не так уж плохо.
                                                            Нет сложных вещей, есть недостаток опыта.
                                                            Во всех отраслях и технологиях есть best practices.
                                                            Просто в какой-то области я или вы оказываемся новичками и не всегда начинаем с RTFM
                                                            Кстати раньше туда чаще посылали :-)
                                                            +2

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


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

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

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

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


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

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


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

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

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

                                                              0

                                                              del

                                                                0
                                                                «9. Не верьте своим глазам» — вообще универсальное правило для любого программиста. Наши органы восприятия неидеальны и нужно принимать это как данность. Поэтому всегда нужно перепроверять свой код различными способами: отладка, тесты, подсадить коллегу с вопросом «что здесь написано?»
                                                                  0
                                                                  Вместо «FUCK» отлично подойдет что-то маскирующее вроде «REMY SPEAK» (https://www.youtube.com/watch?v=NVOL3tMDzEs)
                                                                    0
                                                                    Ещё совет: изучите как работает linter.
                                                                    А встроенный линтинг в редакторе сэкономит кучу времени, де-факто подсказав о незакрытой скобке или другой случайной опечатке.
                                                                      0
                                                                      Либо сразу юзайте нормальную IDE
                                                                      0
                                                                      3. Development и Production сайты — это всегда разные серверы

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

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

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

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

                                                                                0
                                                                                1. Кэш бывает не только фронтовый, но и бэковый. Для фронта использовать нужно сборщики webpack или gulp. Это де факто стандарт. А у бэка кэш может, как файловый, так и в базе и в памяти.

                                                                                2. Мне сложно представить ситуацию, когда новичок будет писать свой велосипед. Все фреймворки имеют только одну расшаренную папку public с единой точкой входа. А весь проект лежит на уровень выше. Если речь идет о каких-то CMS, то это явно уже не программирование.

                                                                                3. На сегодняшний день не использовать системы виртуализации и все лить на разные сервера — это поиметь геморрой размером с арбуз.

                                                                                4. Конфиги сервера и рабочее окружение — это не одно и тоже. Именно поэтому при разработке используют докер, который разворачивается за секунды и позволяет команде работать в одном окружении. А лесть программисту на боевой сервер, а тем более начинающему — даже и не знаю, что на это ответить.

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

                                                                                6. Проверьте, а не залили вы часов в гит все пароли доступа к базе и всяким АПИ. А то знаете, так часто ломают сервак, как вроде пароли знали. А еще и приватные сертификаты в гите — вообще красота.

                                                                                7. Все эти админки с веб морды зло! Их вообще никогда нельзя использовать! И работать на прямую с БД на проде — это еще большее зло! Есть для этого миграции. А все тестирования и другие вещи должны проводиться на тестовом локальном компе. Потом деплоиться на тестовый сервер для проверки работы в боевых условиях, а уже только потом на прод. Никакого прямого доступа к БД на проде не должно быть у программиста!

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

                                                                                9. Не верить свои глазам? Интересный совет. Вспомнился Лесь Поддеревянский: «Пророк Микола видел в жизни все! Но боги смилостивились над ним и ослепили.» Повторюсь, есть дебагер, которым нужно научиться пользоваться с первых дней изучения ЯП.

                                                                                10. Этот код не дебагинг. Это что-то за гранью реального. Для пыхи есть xdebug. Для рунтайм ЯП есть вообще шикарные дебагеры. Отлавливать переменные путем вызова мутных конструкций — это путь в никуда.

                                                                                Я не для троллинга это написал. Статья нужная. Но есть множество других советов, которые неплохо было бы осветить. Так как эти десять немного вызывают у меня сомнения.

                                                                                Иногда я делюсь полезной информацией у себя в блоке (https://cleverman.org/), и там даю некоторые рекомендации, как новичкам так и профи. Если кому-то интересно мое мнение на какие-то темы, то могу написать статью об этом.

                                                                                П.С. Но за статью спасибо, работа нужная и важная.
                                                                                  0
                                                                                  Спасибо за развёрнутый комментарий! Частично попытаюсь ответить.

                                                                                  1. Кэш бывает не только фронтовый, но и бэковый. Для фронта использовать нужно сборщики webpack или gulp. Это де факто стандарт. А у бэка кэш может, как файловый, так и в базе и в памяти.
                                                                                  Об этом написано в самом посте:
                                                                                  Далеко не все используют продвинутые системы сборки и деплоя frontend-а
                                                                                  . Понятно что с вебпаком эта проблема неактуальна, но не все новички с ходу осваивают всё самое новое

                                                                                  2. Мне сложно представить ситуацию, когда новичок будет писать свой велосипед.
                                                                                  Очень странно. Новички, как раз таки, чемпионы в строительстве велосипедов. Потому что знаний разобраться в чужом коде ещё не хватает, но зато энтузиазм через верх хлещет.

                                                                                  3. На сегодняшний день не использовать системы виртуализации и все лить на разные сервера — это поиметь геморрой размером с арбуз.
                                                                                  Совсем не понятно что имелось в виду

                                                                                  4. Конфиги сервера и рабочее окружение — это не одно и тоже. Именно поэтому при разработке используют докер, который разворачивается за секунды и позволяет команде работать в одном окружении. А лесть программисту на боевой сервер, а тем более начинающему — даже и не знаю, что на это ответить.
                                                                                  Вы, видимо, никогда не работали на фрилансе) Иначе вы удивились бы количеству проектов на котором не то что докера — а даже git репозитория нет. И ничего, работают люди, потому что на маленький интернет-магазин торгующий носками никто не будет поднимать четыре сервера с лоад-балансером и деплоем через jenkins. А такие маленькие проекты — как раз «хлеб» многих начинающих

                                                                                  5. Очень часто вижу в разных проектах, как куча фигни пишется в логи на продакшене. Ой, как всегда забыли выпилить всякие тестировщики и отладчики. А потом думаем, почему это все так тормозит и место на диске сжирается. Совет, очень сомнительный, честно говоря. Нужно пользоваться дебагером и тестировать код сразу, не отходя от кассы.
                                                                                  Всё что не в меру то не здраво, согласен. Тут нужно соблюдать адекватный баланс + грамотное логирование, а не тупое сбрасывание всего в один .log файл plain-текстом

                                                                                  7. Все эти админки с веб морды зло! Их вообще никогда нельзя использовать! И работать на прямую с БД на проде — это еще большее зло!
                                                                                  Дык — об этом и говорится. Использовать — только если сииильно припечёт (такое бывает!).

                                                                                  8. Ага, складируйте старый код и половину неактуальных данных в базе.
                                                                                  Складировать код я, как раз таки, не агитировал — для старого кода всегда есть git. А вот неактуальные данные в базе — тут надо быть осторожным, не факт что завтра эти данные вам не понадобятся.

                                                                                  10. Этот код не дебагинг. Это что-то за гранью реального. Для пыхи есть xdebug.
                                                                                  А брекпоинты вы как xdebug-ом ставить будете? А если надо целенаправленно остановить какую-то ветку кода? Да и xdebug иногда как «пушка по воробьям». Подход var_dump + die ещё долго будет жить, особенно у начинающих. Отсюда совет.
                                                                                    0
                                                                                    Если речь идет о фрилансе, то вы пожалуй правы. Трэша всякого хватает. Именно поэтому, если начинающий программист хочет профессионально освоить профессию, то очень важно попасть на реальный проект, где работают настоящие профессионалы. И учиться правильным вещам с первого дня. Потому что, как показывает практика, переучиться подавляющему большинству уже нереально. Конечно с лету освоить миллион нюансов трудно, но нужно идти потихоньку, шаг за шагом, но в правильном направлении. Спуститься в говнокодинг очень легко, вот только выбраться от туда уже нереально.

                                                                                    Что касается хдебага, то конечно же он поддерживает брэкпоинты, и имеет полный набор с блэкджеком и шлю… ами. Вы ведь не хотите мне сказать, что народ пишет код в блокноте? Для пыхи PhpStorm наше все!

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

                                                                                    Но лично я себе не могу представить ситуацию, когда начинающий хирург, прочитав книгу «Хирургия для чайников» уже берет в работу операции. А вот в ИТ — это сплошь и всюду. Абыдна!

                                                                                    Спасибо за ваш ответ. Просвещать народ нужно, но задача эта трудная.
                                                                                      0
                                                                                      И учиться правильным вещам с первого дня.

                                                                                      с первого дня надо усвоить что правильное/не правильное это не слишком инженерные понятия.


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

                                                                                      реально, просто нужно что бы человек во первых был не слишком высокомерным (такие бывают) и во вторых что бы команда, в которую он попал, обладала базовыми навыками общения. И да, это сложнее чем с нуля… хотя опять же не факт. Все равно все сводится к формированию понимания тех или иных подходов. А тут какие-то подходы проще как раз объяснить человеку который повидал вещей а не человеку который рос в стерильной обстановке.


                                                                                      А вот в ИТ — это сплошь и всюду. Абыдна!

                                                                                      Вы еще не забывайте что в ИТ еще работает аналогия, при которой пациенты сами себя любят диагностировать а хирург в процессе операции материт пациента со словами "как же ты надоел диагнозы менять".

                                                                                      0
                                                                                      Ах да, забыл ответить про виртуализацию. Нет нужды поднимать сервера, все настраивать, и за всем этим следить по старинке. Любая современная система виртуализации позволяет вам создать базовый контейнер с рабочим окружением. Делать из него снапшоты и клонировать для своих нужд. Это быстро, удобно и безопасно. Плюс не зависит от железа и других факторов. Создали себе виртуальный контейнер под продакшн. И тут же сделали его клон в один клик. Вот вам и тестовая среда. Пробросили на него тестовый домен, закрыли доступ для поисковиков и тестируете прямо в боевых условиях. Не нужно никаких бэкапов в архивах, миллиона баш скриптов и прочего ужаса. Именно это я имел ввиду, что работа с серверами по старинке приведет к геморрою большого размера :)
                                                                                        0
                                                                                        Вот тут согласен :)

                                                                                        Очень часто мне как админу «нужно» принять проект класса «ай, помогите, все плохо!».
                                                                                        Вот как раз в таких проектах чаще всего стоит 1 железка «все в одном». Это действительно «немного неудобно», тогда как разбитие на мелкие виртуалки а-ля «БД+Прод+Полигон» в разы упрощает управление и облагораживание этого зоопарка.
                                                                                        А вот докер в некоторых ситуациях (но не всех!) ИМХО усложняет…
                                                                                          0
                                                                                          Я считаю, что докер годиться лишь для локальной разработки. Чтобы у всей команды была единая среда. Он быстрый, маленький и настройки ложатся в гит рядом с проектом. А поднимать полноценную виртуалку именно для локальной разработки — это долго и дорого. В конкретных случаях нужно использовать необходимые для этого случая инструменты. К сожалению, серебряной пули не существует.

                                                                                          Довольно часто от проекта к проекту вижу, как люди пытаются не технологию к месту и теме подбирать, а изворачиваются и пишут тонны костылей для одной технологии, которая у них «универсальная» на все случаи жизни. Я для себя так и не смог разгадать эту загадку.
                                                                                            0
                                                                                            Да уж… Пули нет… Был в конторе которая «взяла курс на докеризацию». У меня в поддержке было 300+ доменов. От старинных PHP5.2 костылей до современных сайтов на Symfony и Yii. Ввиду «обязательного желания переводить все на докер» пришлось придумывать костыли… (По сути в докере был только РНР. Директория проекта монтировался. Nginx брал статику прямо с хоста. lsyncd клонировал все в риалтайме на другие ноды). Это был образцовый пример поиска серебряной пули. :) Хорошо что хоть от от мускуля отбился ))))
                                                                                              0
                                                                                              По сути в докере был только РНР.

                                                                                              а что там по вашему еще должно было быть?


                                                                                              Директория проекта монтировался

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


                                                                                              Nginx брал статику прямо с хоста.

                                                                                              nginx был на хосте?


                                                                                              Это был образцовый пример поиска серебряной пули

                                                                                              Подозреваю все же что была какая-то конкретная проблема которую по неумению пытались приготовить как могли. Нет, я тоже видел СТО которые просто где-то что-то прочитали и начинают внедрять без какого либо анализа рисков/профита но в таких ситуациях это вина работников что не смогли разобраться/убедить что профита не будет.

                                                                                                0
                                                                                                а что там по вашему еще должно было быть?

                                                                                                Как минимум полное окружение для работы сервиса.

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

                                                                                                Уволились те кто знали тех кто слышал о реальных авторах. Я бы сказал что не третья, а тридцатая сторона…

                                                                                                nginx был на хосте?

                                                                                                Да

                                                                                                Подозреваю все же что была какая-то конкретная проблема которую по неумению пытались приготовить как могли. Нет, я тоже видел СТО которые просто где-то что-то прочитали и начинают внедрять без какого либо анализа рисков/профита но в таких ситуациях это вина работников что не смогли разобраться/убедить что профита не будет.

                                                                                                Разобрались. Предупредили. Увы. Хоть СУБД отговорили… Вопрос тут не в «разобрались», а в «нафик не сдалось в той ситуации».
                                                                                                  0
                                                                                                  Как минимум полное окружение для работы сервиса.

                                                                                                  Например nginx + mysql? Или вы что-то конкретное имеете ввиду? Приложение же как-то запускается. Или вы про полный цикл сборки с вшиванием исходников в образ?


                                                                                                  нафик не сдалось в той ситуации

                                                                                                  ну я потому и говорю что надо предысторию понимать прежде чем суждения какие-то делать. А так как, с ваших слов, тридцатая сторона все делала и никто ничего не знает — то тут логика простая. Профита нет и выпиливание лишнего решит какие-то проблемы — стоит так сделать. Нет проблем — не трогаем.

                                                                                                    0
                                                                                                    Например nginx + mysql? Или вы что-то конкретное имеете ввиду? Приложение же как-то запускается. Или вы про полный цикл сборки с вшиванием исходников в образ?

                                                                                                    Как минимум nginx+fpm(+по вкусу memcached). Ну и сырцы. Чтобы при разворачивании контейнера получалось готовое для работы (кроме СУБД) окружение.

                                                                                                    Нет проблем — не трогаем.

                                                                                                    Вот! И я почти о том же :)
                                                                                                      +1
                                                                                                      Как минимум nginx+fpm(+по вкусу memcached).

                                                                                                      тогда вы не понимаете философию контейнеров. Это не "дешевые виртуалки" это изоляция процессов. То есть nginx отдельно, php-fpm отдельно, memcached отдельно. Потом все это линкуется. Конечно же профит от таких подходов в виде абстракции от расположения сервисов (то что внутри контейнера крутится, не путать с микросервисами) позволяет более удобно скейлить все. Но если вы будете всегда жить в пределах одного сервера то профита вы не почувствуете, да.


                                                                                                      А вот вшивать исходники в образы это да, удобненько.

                                                                                                        0
                                                                                                        То есть nginx отдельно, php-fpm отдельно, memcached отдельно.

                                                                                                        Да, но статику как-то отдавать надо же. Не, можно сделать контейнеры с nginx+sources, но… Как-то это уже ИМХО перебор.
                                                                                                        Это не «дешевые виртуалки»

                                                                                                        Абсолютно согласен.

                                                                                                        Философию «1 процесс — 1 контейнер» я знаю, но не всегда это бывает к месту. Опять же — ИМХО :)
                                                                                                          0
                                                                                                          Да, но статику как-то отдавать надо же.

                                                                                                          Статика (возможно даже с сорсами) закатывается в отдельный вольюм и линкуется к вебсерверу и пхп
                                                                                                            0
                                                                                                            но статику как-то отдавать надо же

                                                                                                            ну отдавайте, почему у вас статика вынуждена лежать в контейнере с php?


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

                                                                                                              0
                                                                                                              Тут вопрос больше в том, что не понимают толком, что по факту у них может десятками лет работало два приложения — http-сервер и fcgi-сервер, которые шарили между собой папку /var/www
                                                                                                              0
                                                                                                              Если до докеризации был один хост c nginx который статику отдавал сам, а часть запросов адаптировал к, обычно, php-fpm то docker best practice — два контейнера, один nginx со статикой, другой php-fpm с php-исходниками, на второй первый шлёт запросы. При желании можно даже из одного Dockerfile их собирать, просто с разными target
                                                                                                  0
                                                                                                  Я считаю, что докер годиться лишь для локальной разработки.

                                                                                                  Почему вы так считаете?


                                                                                                  Чтобы у всей команды была единая среда.

                                                                                                  в том числе что бы эта же среда была и на серверах, нет?


                                                                                                  К сожалению, серебряной пули не существует.

                                                                                                  к счастью она и не нужна, помимо докера существуют и другие решения. И благо большинство из них совместимы между собой. То есть локально у вас все в докерах крутится, а на сервере под каким-нибудь cri-o или rkt.


                                                                                                  Я не знаю была ли у вас необходимость поднимать на продакшенах специфичный софт (например проприетарные решения над ffmpeg для того что бы каждый кадр снабдить специфичным невидимым ватермарком), который далеко не всегда выходит удачно собрать у себя и постоянно какие-то проблемы. Делаем образ, тестируем его локально, пушим в регистри р в целом с вероятностью 99.9% (оставшийся десятая часть процента на различия между версиям ядра) у нас все будет с этим хорошо.


                                                                                                  Другой аспект — захотели мы разрвенуть быстреько какой-нибудь специфичный сервис по работе с картинками, к примеру — imaginary. docker run -d --restart=always h2non/imaginary .. и все. Или там какой-нибудь keratin/authn-server. Или еще чего готового.


                                                                                                  Словом мне было бы интересно выяснить вашу позицию. Или вы говорите о юзкейсах когда в целом все приложение это php + субд + nginx какой-нибудь?

                                                                                                0
                                                                                                А если в продакшене десяток серверов как одинаковых (половина, например, php+nginx+cron за балансером), плюс mysql, redis, rabbitmq, ELK и т. п., да ещё куча интеграций со сторонними сервисами от инфраструктых типа AWS до платежных и фискальных, которые хорошо если вообще песочницу предоставляют. Создать «базовый контейнер с рабочим окружением» в такой ситуации, особенно если толком никто уже не знает где что за что отвечает, это человеко-год занять может с кучей инцидентов на продакшене.
                                                                                                  0
                                                                                                  С одной стороны вы правы. С другой стороны, если этот хаос не привести в порядок, то владелец этого парка сам себе злобный буратино. Достаточно, чтобы что-то серьезно отвалилось, и большой привет всему бизнесу. На предыдущей работе босс довел девопса до состояния нервного срыва. И тот взял и послал шефа куда подальше и свалил. Наняли нового, через пол года так и смогли разобраться что и как работает, и почему сделано именно так. А боевые сервера — это не код рефакторить. Тут ошибки не допускаются.
                                                                                                    0
                                                                                                    Ну, я же говорю, человеко-год вполне реальная оценка :) и это без «почему», а просто «что и как» в среднего размера не ИТ-бизнеса, в котором бизнес-процессы сильно автоматизированы.

                                                                                                    А насчёт «сам себе злобный буратино» — очень субъективно. Обычно владелец бизнеса ни черта не шарит в технологиях, в лучше случае шарил когда-то, когда господствовал виртуальный хостинг. Он вынужден доверять в этих вопросах кому-то (от CTO до единственного «эникейщика), чью компетентность самостоятельно проверить не может. А в наших „широтах“ привлечение внешнего аудита к состоянию ИТ в организации до сих пор считается ЧП, как для собствеников или топ-менеджеров, так и для отвественных за ИТ — вопрос недоверия, а не штатная процедура. В бухгалтериях вроде прижилось уже, понимают собственники и топы „голова хорошо, а две лучше“, а в ИТ ещё нет.
                                                                                                      0
                                                                                                      Согласен на все 100%. На, опять таки, предыдущей работе рядового программиста, у которого стаж пару лет ковыряния в коде, шеф сделал тим лидом. А причина простая, они много лет знакомы и ему шеф доверяет безгранично. А тот и рад стараться, сразу заделался спецом вообще по всем вопросам. И девопсом стал, и бэкендером и фронтендером, и верстальщиком, и архитектором, и аналитиком, короче всем и сразу. Новые специалисты которые приходили в проект со своим опытом и знаниями сразу прогибались раком. Мол тим лиду виднее, вас взяли не думать, а делать что скажут. Кстати так и довели девопса, который всех послал. Еще такая участь постигла пары сениоров (бэк и фронт). Ваш покорный слуга тоже не выдержал и свалил. Но когда мы подходили к боссу и говорили, что не может один человек без образования и опыта разбираться везде и во всем, мол давайте наймем ИТ аудиторов, раз нам не доверяете, то были посланы в пешее эротическое приключение. Специфика отечественного бизнеса. В итоге проект уже четвертый год пилится «гением» самоучкой, а толковые ребята разбежались. Шеф всем доволен. У меня это в голове не умещается.
                                                                                            0
                                                                                            Спасибо! полезные советы, особенно мне, как «молодому» программисту;)
                                                                                              0
                                                                                              Пожалуйста! Рад что пост оказался полезным)

                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                            Самое читаемое