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

В эпоху стремительной цифровизации, когда виртуальный мир становится неотъемлемой частью нашей жизни, роль IT-специалистов возрастает многократно. Особенно это касается компаний, которые активно внедряют цифровые решения, делая жизнь своих клиентов комфортнее и доступнее. Но кто же стоит во главе этого процесса? Кто отвечает за бесперебойную работу платформы, внедрение новых технологий и развитие цифрового сервиса? В этой статье я расскажу о роли IT Area Lead в Домклик, о том, какими навыками должен обладать этот человек и с какими вызовами он сталкивается каждый день.

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

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

Привет, меня зовут Артём Говердовский, и я дизайн-директор в Сбер Домклик. В моëм подчинении 49 дизайнеров, среди которых 6 лидов. Хочу рассказать, как у нас получилось переформатировать дизайн-отдел, распределить зоны ответственности, настроить процессы, справиться с легаси и полностью синхронизироваться по всем проектам за 9 месяцев работы.

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

На ум сразу приходит самое очевидное решение: следить за версиями всех зависимостей в своих проектах и вовремя обновлять. К этому, естественно, необходимо стремиться всегда, но мы понимаем, на практике что это крайне сложно, а в legacy-проектах или в проектах, у которых нет постоянной поддержки и вовсе нереально. Следующим вариантом созрел Pnpm, тем более что в наших монорепах он себя уже продолжительное время отлично показывал. Я решил испытать его на действующих клиентских приложениях.

Всем привет. Меня зовут Евгений Чернышев, и я возглавляю фронтенд-разработку в одном из направлений деятельности Домклик. Хочу поделиться своими мыслями о том, как управлять сложными конфигурациями Webpack. Сразу «проведу черту», чтобы предотвратить возможные холивары: сравнение Webpack с другими бандлерами (Rollup, Vite и прочими) выходит за рамки статьи.

Де-факто, Webpack является основным сборщиком фронтенд-проектов. Это зрелый продукт, который до сих пор развивается и повсеместно используется. Но, как и любой инструмент, он имеет свои слабые стороны. Я считаю что основной недостаток Webpack — это сложность его конфигурации. На крупных долгоживущих проектах конфигурационные файлы становятся слишком большими и нечитаемыми, превращаясь в мешанину вложенных объектов и spread-операторов. Чтобы показать, что я имею в виду, рассмотрим стадии развития проекта.

Практики работы с запросами на сервере значительно отличаются от того, к чему привык фронтенд-разработчик. ежедневно разрабатывающий SPA-приложения с клиентским рендерингом. Если не учесть эту разницу при разработке приложения с серверным рендерингом, то можно собрать довольно много граблей. Хочу поделиться опытом и рассказать про три практики, которые использую повседневно, а также о проблемах, предшествующих их появлению. Я буду ссылаться на веб-производительность и рассчитываю что вы уже знакомы с такими метриками как TTFB, LCP и FCP.

Я постарался придумать самое простое объяснение дизайн-токенов на примере житейских ситуаций. Что это такое, как работают и зачем они нужны — в этой статье.

Про принципы наименований, экспорт токенов из фигмы и передачу токенов разработчикам.

Я хочу поделиться своим опытом использования Zabbix для анализа проблем с производительностью PostgreSQL, используя расширение pg_stat_statements.