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

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

Существует много курсов программирования и повышения IT-квалификации, но ни на одном из них не учат системно искать и исправлять ошибки. В реальных крупных проектах до 30% времени может уходить не на написание нового кода и фич, а на поиск первопричин неисправностей и их устранения. Именно недочёты и ошибки будут мешать вашему клиенту составить положительное впечатление о продукте, а в некоторых случаях они полностью блокируют процесс. Кроме того, инженер, который только пишет новый код и не решает ошибки, не получает архитектурный опыт и не расширяет кругозор, что приводит к появлению новых недочётов в проектах. Я опишу наш инструментарий для исправления ошибок в веб-приложениях и поделюсь опытом.

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

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

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

2022 год научил нас быстро менять приоритеты для оперативного реагирования на внешние факторы. В наших целях была зафиксирована ключевая задача по отказу от софта вендора в пользу собственных решений, разработанных на основе микросервисной архитектуры. Стоял вполне комфортный срок: полностью завершить переход до конца года, и команды планомерно шли к этой цели, наряду с разработкой менее масштабных, но тоже важных фич. Но в связи со вполне реальными рисками преждевременного ухода вендора из РФ сроки доработок сократились с полугода до одного месяца (почти как в известной шутке про невозможность родить ребёнка ранее, чем через 9 месяцев, сколько людей для этого процесса не привлекай). Ниже я опишу наш опыт мобилизации и решения поставленных задач в нереалистичные сроки.

Существует много руководств и инструкций по созданию базовых бекенд-приложений. Также в сети можно найти пошаговые tutorial по сборке приложения и развёртыванию на сервер, либо подробные инструкции для популярных CI/CD-инструментов. Описанных в них шагов достаточно для запуска pet-проектов, но для полноценных приложений, которые должны будут выдержать пиковые нагрузки от большого количества пользователей и при этом бесперебойно работать, нужна более детальная и качественная подготовка. Ниже я опишу шаги, которые обязательны для инженеров из моих команд при первом развёртывании веб-приложения в production и при дальнейшей выкатке крупных фич.

Всем привет! Меня зовут Иван Сёмин, я руковожу несколькими командами разработки в компании Домклик. На данный момент в моём подчинении 28 человек, часть из которых приходила на junior-позицию. Хочу поделиться своим видением погружения новых сотрудников в процессы компании и коллектив, и рассказать о способах развития разработчиков до middle-уровня в крупных командах.

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

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

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

Для асинхронного Python существует мало полноценных ORM, и им далеко до таких монстров-комбайнов, как DjangoOrm и SQLAlchemy.ORM. Бедность ORM-инструментария для асинхронного программирования заставила многих программистов отказаться от зачастую непонятной им работы с ORM и перейти к более прозрачному взаимодействию с БД. Решение в лоб — написание raw SQL, но в этом случае запросы не будут защищены от инъекций, а запросы, составляемые по бизнес логике с опциональными параметрами, превратятся в конкатенацию строк. Важно найти баланс между прозрачностью выполнения кода, скоростью его написания и читаемостью.

Ниже я предлагаю реализацию такого баланса c использованием SQLAlchemy Core.