Стачка.Frontend

В Интернетах принято ругать CSS, если не понимаешь, как с ним работать. Тем не менее, CSS в связке с HTML — Тьюринг-полный язык программирования, а если к ним добавить Houdini API и CSS Custom Properties — можно творить настоящую магию.

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

Сodemode - это скрипт, работающий с абстрактным синтаксическим деревом (ast) JavaScript. Цель codemode - автоматизировать рефакторинг кода.

В своем докладе я расскажу про jscodeshift - тулкит для написания codemodes. Покажу и разберу несколько примеров codemodes, начиная с простых и заканчивая теми, которые могут быть использованы в вашем проекте. Вы увидите, что работа с ast на самом деле не такая уж и сложная задача, как может показаться на первый взгляд, и что овладение этим инструментом может дать очень сильный прирост вашей эффективности.

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

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

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

В докладе я расскажу об архитектуре, к которой пришел за четыре года разработки SPA и React Native приложений через свои пробы и ошибки и анализ и рефакторинг чужого кода.

Большинство фронтенд-специалистов самоучки. Умеют хорошо верстать и даже делают сайты на реакте. Но страдают архитектурные решения.

Я хочу рассказать о том как стоит строить spa, расскажу как нужно делить на слои ответственности. Как это позволит делать отказоустойчивые приложения. Улучшит расширяемость/заменяемость. Упростит тестирование. Расскажу как в качестве сервисного слоя использовать библиотеку MST.

Как часто вы в тестах подключаете библиотеку для хитрой подмены модулей? А во сколько if вы оборачиваете куски вашего кода для разных платформ? Или может ваша система A/B тестирования построена на switch/case? Хватит это терпеть, нужно чинить!

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

Я расскажу об инструментах (а их очень много) которые позволяют делать наши приложения более выразительными.

О том, что полезно сделать до того как мы начали писать код.

О том как устроены разные форматы изображений и как выбрать самый подходящий.

Я покажу вам нечто прекрасное, как маленький npm-пакет может погрузить ваше приложение в хаос.

А если серьезно, каждый день мы используем множество npm-пакетов в наших приложениях, но что мы о них знаем?

Я расскажу вам: как правильно собирать npm-пакеты, что выбрать webpack или rollup, какой негативный импакт можно занести в приложение используя плохо собранный пакет.

Рассмотрим что такое BDD тестирование и как оно помогает писать e2e тесты дешевле и быстрее.

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

Определим место acceptance тестов в ci/cd пайплайне. Обсудим кто должен и может писать такие тесты и когда

Когда и что стоит оптимизировать, а что лучше не трогать

Как опередить способы оптимизации и выбрать правильны подход

Что стоит оптимизировать а что переписать совсем.