Как привести проект в чувство



    Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.

    Так звучит один из популярных вопросов на собеседовании для фронтенд-разработчиков. Я не знаю, что хочет услышать человек, задающий этот вопрос, но у меня есть ответ на его техническую составляющую и бэклог на несколько месяцев вперед.

    Предисловие


    В этой статье я буду опираться во многом на (осторожно, субъективное мнение, подтвержденное только внутренним чувством и количеством репозиториев на github) самый популярный сборщик статики — webpack. Если по какой-то причине в вашем проекте используется другой сборщик, то ничего страшного: аналоги инструментов, про которые пойдет речь, с большой вероятностью найдутся в поиске.

    Но мой совет: если ваш проект не является npm-модулем, переведите сборку статики на webpack, так будет проще.

    Метрики


    Первое, что нужно сделать, это собрать метрики. Они помогут понять, что ситуация стала лучше, а не хуже. Можно начать с веса статики (JS, CSS, HTML, картинки и т.д.). Делается это на удивление просто: собираем продовую версию проекта и получаем вес файлов. Второй важной для нас метрикой можно считать web-performance. Её можно получить с помощью Lighthouse. Проводим замеры, сохраняем оценки. И мы готовы начать.

    Неиспользуемые файлы




    Нам необходимо облегчить себе жизнь за счёт удаления неиспользуемых файлов. Они мешают воспринимать проект, и порой могут сильно путать. К примеру, один раз я удалил файлов на полпроекта, они просто нигде не использовались. Для решения этой задачи можно использовать плагин под webpack — unused-files-webpack-plugin. Подключаем плагин, запускаем сборку, получаем в консоль список мусорных файлов. У плагина есть параметр failOnUnused, значение по умолчанию — false. Если вы хотите сделать проверку строгой, то меняем значение на true, и сборка будет падать, если кто-то оставит в проекте лишний файл.

    Статический анализ кода


    Мы удалили лишние файлы, а значит не попадем в ситуацию, когда после исправлений в конкретном файле оказывается, что он не нужен, и мы впустую потратили время. Первое, что рекомендую установить на вашу IDE, это плагин SonarLint. Он умеет анализировать не только JavaScript, но и множество языков (полный список тут). Устанавливаем, проверяем весь проект, видим ошибки, правим — профит.

    Это, конечно же, не всё. Теперь нужно установить и настроить ESLint. Обратимся за помощью к довольно популярному конфигу от Airbnb: если у вас не React — eslint-config-airbnb-base, а если React — eslint-config-airbnb. Они различаются набором правил. Например, в пакете для React будут прописаны правила от ESLint-плагинов: eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y. Некоторые правила являются вкусовщиной, и если вам не по душе, например, висящие запятые, всегда можно поменять настройку правила.

    Третьим шагом в нашем крестовом походе за стиль кода и качество кодовой базы будет подключение eslint-plugin-sonarjs. Плагин для ESLint никак не заменяет плагин для IDE, а лишь приятно дополняет.

    В первых трёх шагах мы делали упор на JS, но во фронтовых проектах немало стилей, давайте перейдем к ним. Для всего, что не является Stylus'ом, мы будем использовать Stylelint, а для Stylus — Stylint.

    Ожидаемо, что после внедрения SonarLint, ESlint и Stylelint или Stylint будет куча ошибок. Необязательно всё править за один раз, можно временно отключить правила и исправлять их по порядку, или перенастроить их до фикса на warning.

    Зависимости


    Львиную долю кода в проекте составляют зависимости. Во-первых, было бы неплохо знать инструменты, которыми мы пользуемся. Во-вторых, эти самые инструменты могут плохо повлиять на web-performance вашего приложения.

    Идеальным инструментом для решения этой проблемы является плагин под webpack bundle analyzer. Он позволит посмотреть, что у приложения под капотом, найти самые тяжелые зависимости, а также зависимости, которые не должны были попасть в продовую сборку (например, prop-types, redux-devtools, hot-loader и т.д.).

    Но у зависимостей есть еще одна проблема: они любят дублироваться. В большинстве своем из-за неправильно собранных npm-пакетов и разницы между мажорными версиями npm-пакетов.

    Инструмент, который поможет нам найти дубли: duplicate-package-checker-webpack-plugin (да, это очередной плагин под webpack). По аналогии с unused-files-webpack-plugin, его можно настроить на строгую проверку и завершать сборку при найденном дубле. Для этого нужно задать параметру emitError значение true.

    Что мы будем делать с найденными дублями?

    • В любом случае, стоит освежить версии всех зависимостей.
    • Если это не помогло, можно поискать аналог пакета, который создает проблемы. Делать это можно через сервис bundlephobia.
    • Если аналога нет, попробуйте написать функциональность сами.
    • Если писать самому не вариант, сделайте pull request.

    Журналирование




    После очистки кодовой базы от неиспользуемых файлов, правки стиля и разбирательства с зависимостями стоит прикрутить журналирование ошибок. Для этого прекрасно подходит Sentry. Она (он или оно) являлась де-факто стандартом везде, где я работал. Установить Sentry можно двумя способами:

    • скриптом в HTML;
    • как модуль через npm.

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

    CI-пайплайн


    Мы потратили немало времени, и чтобы проект не вернулся к изначальному состоянию, нам нужно автоматизировать все проверки, постаравшись исключить человеческий фактор хотя бы в этих частях.

    Для этого напишем немного скриптов в package.json:

    "scripts": {
     "lint": "stylint src/ && eslint --ext .js,.jsx src/",
     "prod": "BABEL_ENV=production webpack --env=prod --progress",
     "build": "npm run lint && npm run prod"
    }

    Что мы получим:

    • Запускается линтинг JS (из package.json).
    • Запускается линтинг CSS (из package.json).
    • Запускается webpack (из package.json).
    • Запускается unused-webpack-plugin (из webpack).
    • Запускается duplicate-package-checker-webpack-plugin (из webpack).

    Web-performance


    Стоит потратить время на исправление ошибок, найденных Lighthouse (о нем я упоминал в начале статьи). В Chrome вы можете всё проверять вручную: переключитесь в режим разработчика, и попадёте во вкладку Lighthouse. Целесообразно проверять в режиме mobile: если в нём получится добиться хорошего результата, то в desktop всё будет отлично. Также можно использовать CLI.

    Подведение итогов




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

    Чего мы добились:

    1. Очистили проект от мусора.
    2. Стандартизировали стиль кода внутри проекта.
    3. Уменьшили вес кодовой базы.
    4. Улучшили UX.
    5. Настроили мониторинг.
    6. Собрали CI.

    Как минимум, это всё можно использовать как аргумент на вашем performance review.

    P.S.


    Пример проекта с настройками можно посмотреть на github.
    ДомКлик
    Место силы

    Комментарии 32

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

      Я правильно понимаю, что ничего ещё не узнав про проект, его нужды и проблемы, вы предлагает руководству оплатить несколько месяцев вашей работы для того, чтобы почесать ваше ЧСВ?
      Нет, тулчейн и инструкции, без сомнения, достойны внимания, но вот посыл во вступлении странный.
        +1
        В самом начале я упомянул, что бэклога хватит на несколько месяцев вперед. Это не значит, что на всех проектах всё займет одинаковое количество времени. Это, скорее, в среднем по больнице, учитывая, что большую часть рабочего времени мы решаем проблемы бизнеса.

        Нет, Вы не правильно понимаете. Разработчик должен уделять вниманию качеству кодовой базы и ЧСВ тут не при чем. Вы же дома убираетесь? Вот так же нужно убираться и у себя в проекте. В крупных компаниях под техническую квоту закладывают время и дают возможность разработчикам исправить или улучшить кодовую базу. И ни кто не говорит что вы должны только этим заниматься, рефакторинг можно делать постепенно.
          +1
          Знаю, что статья по большей части техническая и хотелось бы узнать больше про то, как это все внедрить и донести необходимость этих действий до начальства и других разработчиков.

          Занимаемся проектной деятельностью. На одном проекте добавил проверку linter-ом и форматирование prettier-ом на pre-commit, чтобы никто не мог плохого закоммитить. Но после моего ухода с проекта, команда «забила» на такую штуку и не стала переносить его дальше на другие проекты, даже не смотря на то, что ощущали плюсы данных настроек и перенос конфигов с одного проекта на другой занял бы максимум 20 минут.
            +3
            Данный вопрос довольно тяжелый, так как к каждому человеку нужен свой подход. Но вот подходы которыми я пользуюсь с бизнесом.

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

            Баги
            Вы можете оперировать тем, что без рефакторинга качество вашего продукта падает с каждой новой фичей. И если вы не уделите этому время, то в скором будущем — возможно вы не сможете реализовать фичу без полной переделки функциональности.

            Пользователи
            Можно попытаться продать рефакторинг улучшением UX. Ведь довольный пользователь — это меньше отказов и больше конверсия.

            Если взять разработку, то все зависит от вашей позиции в команде и от ваших софт скилов. Можно провести конструктивную встречу с командой или тим-лидом. Если Вас не услышали — не отчаивайтесь, возможно на то были причины. Переварите беседу и попробуйте еще раз через месяц. За мою карьеру было и такое, что от желания сделать проект лучше, до выкатки в прод — проходило пол года.
        +2
        Почему в новом проекте должны быть мусорные файлы, косой стиль, нет Sentry и отсутствовать CI?
          +1
          В статье ни где не указано про новый проект.

          Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.

          Более того, это набор чеков, если они все успешно будут пройдены — то вопросов нет, но как показывает практика в каком-то объеме эти шаги Вам будут нужны.
            +1
            Говоря про новый проект, я выражался с учетом контекста статьи:
            на новом для вас проекте


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

            Как чек-лист статья хорошая и техническая, но посыл «у всех плохо, а я знаю как сделать всем хорошо» смущает.
              0
              Это просто лирическое вступление, и как я для себя выяснил — не очень удачное.
          +16
          На незнакомом проекте поудалять файлы автоматической тулзой, сделать кучу правок во всех местах, где ругается линтер, обновить версии зависимостей и добавить сверху ещё одну либу… звучит надежно, как швейцарские часы!
            0
            Вы в праве подождать того момента, пока проект станет Вам знаком и начать его очищать от скверны)
            Вас ни кто не призывает делать это за один день.
            +1
            Стоит потратить время на исправление ошибок, найденных Lighthouse

            Лайтхаус может выдать сотню и на сайте, который заставляет ноутбуки лететь в стратосферу на вентиляторах. Лучше руками запустить приложение и потыкать в него, посмотреть, где что там тормозит, запустить профайлер… Но это ведь всё сложно, лучше довериться маяку!
              0
              Я с Вами согласен от части, руками тоже все можно делать и более того, если хочется пойти дальше то это будет необходимо. Но нет ничего плохого в автоматизации проверок, они экономят Вам время.
                0
                А пользователю они потребление ресурсов экономят? Простите, вы делаете проект для себя или для пользователя?
                  +2
                  А пользователю они потребление ресурсов экономят?

                  Конечно экономят. Если следовать советам от Lighthouse — ваше приложение станет легче, загружаться оно будет быстрее (экономя время пользователя и трафик). Браузеру будет нужно тратить намного меньше ресурсов для парсинга файлов.

                  Простите, вы делаете проект для себя или для пользователя?

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

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

              Вариантов «как закопать своим энхансментом проект» просто масса:

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

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

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

              — Вы наделали суперулучшений, прямо перед тем, как другой разработчик собирался заливать свою фичу над которой работал две недели. Теперь весь его ПР — это один большой гит-конфликт. Фича была очень нужна в проде через три недели и теперь никто никуда не успеет

              — Вы наделали суперулучшений, проект стал лучше и чище, все счастливы. Из-за выросшего перформанса, инфраструктура не выдержала и там, где раньше были чуть более высокие таймауты, прилег кластер. Никому не понравилось

              Проолжать можно долго

              Если бы у меня спросили «что вы будете делать в первый день на проекте», я бы предположил что буду ходить по людям и пытаться понять, кому этот проект нужен, зачем он существует и что сейчас важно команде. А трогать лапками код и оркестрировать ансиблами, далеко-далеко не сразу
                0
                Действительно, продолжать можно долго, если прочитать только первый абзац статьи, мне очень жаль что Вы не поняли ее смысла и нашли в ней призывы положить прод в первый день и остановить разработку на пол года.

                Статья про технический чек лист и чем себя занять кроме клепания фич, пять дней в неделю.
                  +1
                  Извините, не соглашусь. Авто пишет «вы первый день на новом для вас проекте, с чего будете начинать» и далее описывает, как положить прод в первый день и остановить разработку на полгода

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

                  Однажды я релизнул свое решение для отслеживание цен на ценные бумаги. И опубликовал об этом статью. Вечером того же дня (а это была пятница, ЧСХ), когда я опубликовал статью, релизнулась новая версия торговой платформы этого брокера, о чем сотрудник брокера сообщил в комментариях к моей статье. Причем так весело релизнулась, что обновление даже скачаться толком не могло.

                  Я сидел как на иголках, все думал, успею ли я за 60 часов форы стать миллионером, или нет. Не стал. Очень жаль, хотелось стать миллионером довольно сильно.

                  Серьёзно, кто-то еще верит, что фича, не доставленная в срок к конкретной дате, часу и минуте разорит кого-то?
                    +2

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

                      0
                      Фикс к торговой платформе, не доставленный в срок к конкретной дате, часу и минуте разорит кого-то. Например недавно были цены отрицательные на фьючерсы, многие торговые платформы не могли адекватно работать. Считать поддержку отрицательных цен фиксом или фичей еще вопрос.

                      Но и если сильно постараться можно и придумать про фичу. Например мы сейчас пилим торговую платформу, потому что та на которой работают наши трейдеры успешно загибается, а остальные не удовлетворяют условиям. У загибающеся платформы время от времени отваливаются фичи, и нам их нужно срочно добавить. Одно дело остановить торги по собственной воле когда на это есть время, а другое — если торги только у тебя остановились внезапно.
                        0
                        О возможных отрицательных ценах было известно сильно заранее. То, что кто-то принял решение проигнорировать этот риск, это его решение и его ответственность. Не кодеров платформы.
                        Самое главное даже не про торговые платформы, а то, что ряд бирж (в т.ч. российские) тупо закрыл торговлю этими «отрицательно» стоящими активами, чем отправили всех прочих участников в убытки. Независимо от готовности платформ торговать производными по отрицательным ценам.
                          0
                          О возможных отрицательных ценах было известно сильно заранее.
                          А как вы храните цену в торговой платформе? У нас uint32_t в 1/1000 доллара. Но мы не торгуем фьючерсами и отрицательных цен все равно быть не может. При этом переполнение не так уж иллюзорно, не считая того что мелкие части цены мы все равно отбрасываем. Все в угоду производительности. (Я уже точно не помню, в некоторых местах минимальная цена 1/10 цента, а в некоторых еще меньше, но бизнес сказал что такая точность не нужна)
                    +2
                    Но мой совет: если ваш проект не является npm-модулем, переведите сборку статики на webpack, так будет проще.

                    Все же мне кажется это довольно далеко от реальности. Т.е. это конечно подходит под ситуацию — «вы на новом проекте и вас там назначили главным», но в любой другой сутации вы просто наткнетесь на то, что народ уже работающий на проекте будет против.
                    Менять существующие процессы новому человеку никто в принципе не даст
                      +1
                      Вы абсолютно правы от части, все будет проще если вы приходите на проект в качестве условного тим-лида. Но не забывайте, что всегда можно поговорить с коллегами и предложить им тот или иной инструмент. Согласятся — замечательно, нет — вы по крайней мере пытались.
                        0
                        «Условный тимлид» не человек с палкой власти, имхо

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

                        Ну, кроме тех случаев, когда команда такая «ну, у нас есть начальство, будем работать как приказали». Имеет место быть, но это уже не про гибкость, плоскость и самоорганизацию, которые мне кажутся дефолтными вещами для здорового процесса разработки. Тут достаточно просто спустить сверху приказ использовать N и ничего не объянять

                        Люди разные, кому-то такая вертикаль власти как раз нравится
                          0
                          если вы приходите на проект в качестве условного тим-лида

                          Чисто личное наблюдение и личный опыт, но кажется прийдти в уже существующий и хоть сколько то здоровый проект сразу на позицию тимлида быть не должно. Тимлид — это про техническую экспертизу, понимание проекта, а также понимание команды — team в термине стоит не спроста. В первый день вы чисто физически не сможете понять, где баги, а где фичи. Что и почему сделано именно так, и как нужно это изменять. Да даже просто оценить, сколько времени нужно на эти изменения и насколько они приоритетны. Кроме того, вы ещё не знаете команду, не понимаете, как распределять задачи, кто в команде в чём силён, кому что стоит подтянуть. Поэтому в нормальной ситуации тимлиды растут из тех, кто пробыл в проекте какое-то время, а не нанимаются извне.

                        –1

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


                        Так что спасибо за отличный чеклист!

                          +1
                          Вам спасибо за внимание
                          +1
                          Что-то из-за неудачного вступления набросились на автора! Статья-то по содержанию явно полезная.
                            0
                            Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.


                            Ответ на вопрос: прочитаю документацию.

                            Ответ на ситуацию: встану и уйду, потому что копаться в очередном желания нет. А постановка вопроса намекает.
                              +1
                              Довольно хороший технический чек лист для стандартных проектов, которых конечно же большинство. Мне очень понравилось лирическое отступление, и я задумался как я бы ответил на такой вопрос, особенно после того как поработал над очень разными проектами. И пришел вот к чему, первым делом, я бы спросил насколько большой проект и сколько человек в нем учавствует, от этого бы строил дальнейшую схему. Например, в нашем проекте используется монорепо и в одну кодовую базу (около миллона строк кода) пушит одновременно 1000+ девелоперов из-за этого я в принципе не смог бы применить ваши рекоммендации, ибо пока я бы их только начинал продумывать все бы поменялось 10 раз в разных местах.

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

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