tgoop.com/smelukov_dev/22
Last Update:
Неиспользуемые зависимости
Какие-то зависимости из package.json могут вовсе не использоваться, но при этом они будут установлены на npm install. Например, после рефакторинга забыли удалить из package.json зависимость, которая больше не нужна. В таких случаях помогут штуки вроде https://www.npmjs.com/package/depcheck
Этот инструмент проанализирует импорты внешних зависимостей и сравнит их со списком зависимостей из package.json
Недостижимые use-cases
Это отдельный класс проблем по поиску мертвого кода. Например, при нажатии на кнопку нужно выполнить какой-то код, но кнопка по какой-то причине не нажимается (съехала из вьюпорта, в принципе скрыта или в обработчике события ошибка, которая не дает выполниться части кода).
Здесь не поможет ни минификатор, ни типизация. Для таких кейсов нужно писать e2e тесты, эмулировать в них действия пользователя и делать проверки. Логика здесь следующая: выполнили тесты, составили отчет по code coverage и весь код, который помечен в отчете красным - недостижим. Но это очень скользкий способ т.к. нужно иметь ввиду, что код может быть недостижим просто потому, что мы не написали под него тест-кейс. Соответственно этот способ требует от разработчика/QA максимальной концентрации и пребывания в контексте бизнес-логики. Тут же встает вопрос о том, где эти тест-кейсы хранить и как их синхронизировать.
Более честным вариантом здесь будет отслеживать действия реальных пользователей и собирать по ним code coverage. Если в течение какого-то времени код так и не "покрасился" в зеленый, значит пользователи не попадают на этот кейс и код для них не достижим.
Вопрос который сразу здесь возникает - как снимать отчет по code coverage.
Если речь о e2e-тестах, то там мы используем реальный браузер (например, при помощи `puppeteer`) и можем снять отчет по code coverage через DevTools Coverage API. Он, к слову, снимает отчет еще и по использованию CSS. Проблема в том, что тестировать надо в разных браузерах и на разных разрешениях (например, чтобы получить coverage по CSS Media Query), а еще надо учитывать динамику изменения размера экрана и подобных кейсов (для кейсов типа `window.onresize`). А как только мы говорим про "тестировать в разных браузерах", то вся стройная концепция с DevTools Coverage API сыпется, т.к. не во всех браузерах это есть и не для всех браузеров есть "безголовый" режим.
Когда мы говорим о снятии отчета с браузера реальных пользователей, то здесь вообще нет способов получить доступ к DevTools Coverage API.
Что тут можно придумать? Например, можно инструментировать реальный продуктовый код. Это значит, что каждый вызов функции, строка или условие будут обернуты в специальные функции-обертки или будут "дописаны" специальными конструкциями (счетчиками). Как только интерпретатор будет доходить до этих конструкций, он будет помечать их как используемые. Для инструментирования кода есть специальные штуки, например https://github.com/istanbuljs/istanbuljs/tree/master/packages/istanbul-lib-instrument
Таким образом, можно собирать code coverage на реальных пользователях.
Здесь есть три проблемы:
- инструментированный код становится объемным и выполняется дольше, появляется оверхед
- в случае большой кодовой базы, отчет может быть довольно большим
- мы инструментируем минифицированный код
- не решает проблему сбора coverage по CSS
В качестве решения первой и второй проблем можно подумать над тем, чтобы раскатить инструментированный код лишь на какой-то процент пользователей (1-2%) и да, они будут страдать от объема получаемого кода и скорости его исполнения.
Для решения третьей проблемы, получаемые отчеты нужно будет маппить на source-map, чтобы понимать о каких конструкциях в исходнике идет речь о отчете.
Подводя итог: как видите, серебряной пули для поиска и устранения мертвого кода - нет. Задача нетривиальная и решается в несколько заходов, с разных углов и разными инструментами.
А как вы решаете эту задачу? Какие инструменты используете? Пишите в комментариях @wdxlabchat
#webdx #dce
BY Сергей Мелюков
Share with your friend now:
tgoop.com/smelukov_dev/22