Планирование, отслеживание и контроль
Всем привет!
Недавно мне нужно было нанять людей в команду по созданию системы на Python, Java, Go. Для меня крайне важны соблюдения принципов SOLID, Чистой архитектуры, Чистого кода.
Я придумал задачу, которую спрашиваю на собеседованиях в свою команду. И мне хочется поделится ею с вами.
Надеюсь, она будет вам полезна!
В каждом ИТ‑проекте есть момент, когда опытный разработчик или архитектор получает в подчинение джуниора или новую команду. Естественно, тимлид хочет добиться эффективной работы своих новых подчиненных искренне веря, что он ментор, наставник, «старший товарищ». Но через некоторое время для команды он превращается в надзирателя, который заглядывает через плечо, проверяет каждый коммит и требует отчета по каждому чиху.
В этой статье мы разберем, где проходит грань между здоровым контролем и токсичным микроуправлением, почему умные руководители попадают в эту ловушку и как из нее выбраться.
Собрали гайд по работе с Git для новичков.
Разберём, как Git хранит изменения, какие команды нужны для базовой работы с репозиторием и ветками и какие ошибки чаще всего допускают новички. Все команды показываем на примерах в терминале, чтобы их можно было сразу попробовать.
Сохраняйте и пользуйтесь.
В статье показан практический подход, который помогает сократить время на вёрстку, убрать лишние вопросы и сделать дизайн понятным без дополнительных объяснений. Если вы сталкивались с ситуациями, когда разработчик «не так понял макет», сроки вёрстки дизайна часто переносятся, коммуникация отделов дизайна и разработки хромает — этот материал для вас.
Привет! Я Александра Невзорова, QA в команде оформлений. Моя команда занимается процессингом оформления кандидатов во всю группу компаний. Поделюсь докладом моей коллеги — Марии Палагиной из команды разработки веб-платформ об автоматических релизах.
Автоматические релизы — не просто модное словосочетание. Это мощный инструмент, который может кардинально изменить подход команды к выпуску новых версий продукта.
В статье разберемся, что такое автоматические релизы, какие подходы к ним существуют и как правильно внедрить их в процесс, чтобы получить максимум пользы и минимум стресса.
Устаревшая документация хуже, чем её отсутствие — она отравляет контекст LLM. Агент доверяет тому, что видит. Garbage in — garbage out, только garbage выглядит как аккуратный markdown.
Это вторая часть серии. Первая часть — «Слепое пятно LLM-разработки: контекст за пределами кода».
Привет, Хабр!
Примерно год назад наша команда загорелась идеей создать продукт, который позволил бы «поговорить с кодом». Мы, как и многие, находились под впечатлением от возможностей LLM. Казалось, что ещё немного – и нейросеть возьмёт на себя всю рутину по анализу легаси, аудиту систем и онбордингу новых разработчиков.
Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.
В начале пути всё это выглядело довольно прямолинейно. LLM же обучены на массе источников в интернете, умеют читать код, у нас есть фреймворки для аудита. Казалось, напишем крутой промпт, загрузим его в модель и будем пожинать плоды.
Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.
Ошибка 1: Один запрос обо всём
Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее.
Привет, Хабр! На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев.
В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Но обо всём по порядку.
Как бесконтрольное использование ИИ для генерации кода превращает сеньоров в уборщиков чужого кода: разбираем метрики, которые выявляют проблему, и три практики, позволяющие встроить управление ИИ-долгом в процесс разработки.
Представьте: команда взялась за инициативу, расписала задачи по спринтам, завела тикеты в Jira — и ушла пилить. Через квартал выясняется, что не успели. Или успели, но никому не нужно. Или руководство неожиданно "не поддержало".
Большинство провалов проектов и инициатив — предсказуемы. Их можно увидеть заранее, если знать, куда смотреть.
Для этого существует DICE-фреймворк от Boston Consulting Group. Это методика оценки вероятности успеха (или провала) проекта до старта.
Если вы хоть раз гуглили «как настроить Obsidian для задач» - вы знаете, чем это заканчивается. Три часа в YouTube, пять вкладок с гайдами, десяток установленных плагинов и... система не работает. Потому что это чужая система.
Я строил свою два года. В этой статье не будет универсального гайда - будет разбор конкретного стека с объяснением, почему каждый плагин попал в него, а не просто список с описаниями из документации.
Если тема управления знаниями и задачами в Obsidian вам близка - заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.
За последние пару лет рынок разработки заметно изменился. Сегодня многие сильные инженеры ищут работу месяцами — конкуренция выросла в разы. Но у нанимающих менеджеров есть свой парадокс: несмотря на огромное количество кандидатов, найти людей, которые действительно решают задачи, по-прежнему сложно.
Код становится всё проще генерировать. AI уже может предложить архитектуру, написать функцию и подсветить ошибки. Но ни один инструмент не отвечает за главное — чтобы система действительно заработала в продакшене и продолжала работать после релиза.
Поэтому ценность разработчика сегодня не просто в умении писать код или знать правильные паттерны. Она в способности доводить задачи до рабочего результата.
Как нанимающий менеджер, я стараюсь находить и продвигать именно таких людей.
В начале я тратил много времени на технические интервью: гонял кандидатов по теории, обсуждал SOLID, паттерны проектирования, тонкости версий языка. Но всё равно через пару месяцев часто выяснялось, что человек не тянет.
Когда я начал задавать два простых вопроса, многое стало понятнее гораздо раньше. Иногда буквально за несколько минут разговора становится ясно, сможет ли разработчик пройти испытательный срок.
Это, конечно, не стопроцентная гарантия. Но корреляция оказалась удивительно высокой.
Эти вопросы не про синтаксис и не про правильные формулировки. Их нельзя выучить за вечер перед интервью.
Привет, Хабровчане! Меня зовут Виктор Чижеков, я техлид команды разработки внутренних продуктов CDEK. В этой статье хочу поделиться своим опытом, как я стал техлидом, но продолжал быть разработчиком. Как переосмыслил свою роль и обязанности, как изменилось видение команды и как я начал на неё влиять.
Статья будет полезна всем, кто работает с командами — тимлидам, техлидам и тем, кто хочет ими стать. В ней описан личный опыт, не претендующий на публикацию в учебниках и пособиях.
ИИ‑фреймворки давно въехали в прод, но к ним часто относятся как к «научной приблуде», а не к ещё одному входу в ваши данные и инфраструктуру. Spring AI и ONNX крутятся где‑то между ML‑командами, продуктами вендоров и внутренними ассистентами, и на определённом этапе за ними перестают успевать архитектура и безопасность.
В марте в обзорах уязвимостей рядом всплыли несколько критичных багов именно в этих штуках. Там есть и SQL‑инъекции, и JSONPath‑инъекции, и обход проверки доверия при загрузке моделей. В статье разбираю, что это значит для тех, кто уже тащит ИИ в прод, и даю чек‑лист, который можно прямо отнести своей команде.
Разбираем все горячие клавиши Claude Code — что делает каждая, когда нажимать и где подвох. Этот AI-ассистент работает прямо в командной строке и напичкан сочетаниями, о которых большинство пользователей даже не подозревает. Двойной Escape откатывает изменения в коде, Ctrl+B отправляет задачу в фон, а Shift+Tab переключает режим работы на лету. Мы разобрали каждую клавишу до винтика: в каком сценарии пригодится, где конфликтует с tmux или браузером и как переназначить под себя.
Сейчас в IT забавная ситуация. Одни компании отчитываются о кратном ускорении с ИИ и экономии миллионов рублей. Другие потратили бюджет на лицензии, обучение и евангелизм — и получили команду, которая тихо ненавидит Copilot и пишет код руками, как в 2019-м. Разница между первыми и вторыми не в технологии. Технология одна и та же. Разница — в людях и в том, как с их сопротивлением работают. Или не работают.
Привет, Хабр. Мы — Сергей Калинов и Андрей Макар-Уваров, руководители бизнес-анализа и фронтенд-разработки в Surf. Несколько лет внедряем ИИ на реальных проектах и видим, что сопротивление ему проходит по вполне узнаваемым стадиям Кюблер–Росса. Разберём, почему разработчики так реагируют.
Стремительное развитие корпоративных информационных систем, представленных набором информационных систем, автоматизирующих заданную предметную область, диктуют обязательные требования к построению сбалансированной ИТ-архитектуры. Архитектура разрабатываемого и имплементируемого программного решения должна быть построена таким образом, чтобы заложить гибкие, масштабируемые и технологичные механизмы работы, обеспечивая тем самым возможность оперативного реагирования на любые изменения внешней среды.
Доступен ряд научно-популярных работ, описывающих различные подходы к построению ИТ-архитектуры, которые обобщены в терминах корпоративная архитектура и архитектура предприятия. Методологии построения корпоративной архитектуры представлены такими подходами как: FEAF, DoDAF [1], а также широко известная и наиболее популярная TOGAF [2]. Несмотря на кажущееся обилие стратегий к формированию ИТ-архитектуры, по большому счету, они апеллируют едиными сущностями, изначально предложенными в модели Захмана.
Не взирая на то, что модель Захмана предоставляет широкий теоретический аппарат, который лежит в основе понимания любой архитектуры предприятия, ее использование как в контексте разработки, так и непосредственно в ходе имплементации корпоративного ПО, часто остается незамеченным [3]. Однако применение именно данной модели делает методологии внедрения ИС такими, какие они есть сейчас: структурированными и гибкими, генерализованными и специализированными, а также прозрачными и эффективными.
Цель текущей работы состоит в анализе модели Захмана и ее применимости в проектах реализации корпоративных информационных систем. Достижение сформулированной цели потребует решения следующих задач:
Спойлер: это статья не про плохую архитектуру. Я расскажу о том, как хорошие решения, принятые в разное время, начинают конфликтовать друг с другом, когда команда растет быстрее системы.
Я Алексей Соболеков, лид архитектуры F&R в Magnit Tech. Это мой личный взгляд на события, и в команде существуют разные их интерпретации.
В 2024 году команда F&R (подробности тут: Архитектура высоконагруженной платформы Magnit F&R) в MAGNIT TECH столкнулась с нетривиальным вызовом: всего за один год необходимо было вырасти с 20 до 220 человек для формирования состава команд. Формально все выглядело благополучно - проект запущен, бюджет подтвержден, приоритет высокий. Но именно с этого момента в ИТ-команде разработки F&R начали накапливаться системные проблемы.
«AI отнимет мою работу» – эту фразу я слышу на каждой второй встрече с командами разработки. Тревога понятна: нейросеть за минуту генерирует код, на который раньше уходил день. Но вот парадокс. По данным ict.moscow, 76% российских разработчиков уже попробовали вайбкодинг. При этом спрос на senior-инженеров в 2025 году вырос на 20%.
Мне как маркетологу стало легче. Раньше я приходил к инвестору с идеей на салфетке. Теперь прихожу с рабочим MVP, собранным за неделю. Продать работающий прототип в разы проще, чем питч-дек с обещаниями. На этом этапе мне не нужна архитектура, безопасность и масштабируемость. Мне нужна скорость.
Но потом наступает «потом».
Привет, Хабр! Меня зовут Андрей, и я фулл-стек-разработчик. Недавно я выпустил свой pet-проект Roomify — веб-приложение, которое превращает обычный план помещения в фотореалистичный 3D-рендер за несколько секунд. В этой статье я хочу рассказать, как всё устроено под капотом: от выбора технологий до интеграции с AI и облачной платформой Puter.