Исходный Код

В голове у тимлида: velocity, количество задач, coverage, дедлайны, баги.

ℹ️ Часть этих KPI со временем перестает помогать, они выглядят как контроль, а на деле не отвечают на главный вопрос: «Что команде делать дальше?».

🔥 Собрали KPI-путаницу в карточках: 4 KPI, 4 перепутанные линии и только 2 из них дают команде полезный сигнал.

🖥 Исходный код — перейти на сайт!

Интерфейс может быть красивым, логичным для команды и все равно неудобным для части людей.

🔥 В карточках - 2 рекомендации про доступность в UX/UI: как замечать риски прямо во время проектирования.

🖥 Исходный код — перейти на сайт!

Когда у тебя нет должности, но за советом все равно идут к тебе.

Кто берет на себя риск, помогает команде и ищет решение, - того и слушают.

Ставим ❤️, если к вам уже обращаются за профессиональным советом. Или 👍, если еще нет.

Мы взяли тезис из книги «Трудные диалоги» и проверили его как рабочую гипотезу вместе с командой.

🔍 Тезис:

Если сделать разговор безопасным, люди начинают говорить честно.

Спойлер: тезис не миф, но он работает не так автоматически, как хотелось бы.

🔥 Выжимка эксперимента в карточках!

🖥 Исходный код — перейти на сайт!

Не весь код, который ИИ пишет быстро, так же хорошо переживает реальную разработку.

ℹ️ В новой статье на Хабре наш коллега Ищенко Тимофей разбирает DatePicker как удобный пример большой инженерной развилки:

🔼 Развилка 1

Когда можно взять ИИ как быстрый черновик.

🔽 Развилка 2

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

ℹ️ Материал будет полезен frontend-разработчикам, тимлидам, тем, кто собирает UI-компоненты, работает с accessibility и пробует внедрять ИИ в продакшн-разработку.

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

🔗 Читать статью на Хабре!

Зачем нужна база данных в проекте? Напоминаем джунам, если вдруг забыли.

ℹ️ База данных - основа любого серьезного приложения. Она хранит, ищет и обновляет информацию. Без нее сервис просто потеряет данные после перезагрузки.

ℹ️ Даже для простого сайта с формой обратной связи база данных критична - она хранит имя пользователя, текст сообщения и дату отправки. Хранить это в файлах неудобно и небезопасно.

❓ Как работают базы данных?

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

❓ Что такое СУБД?

Система управления базами данных (СУБД) управляет хранением и доступом к данным. Она упрощает работу, забирая на себя задачи, которые иначе нужно было бы выполнять вручную, и защищает данные от потерь.

💡 Транзакции: как гарантировать целостность данных.

Транзакция - это группа запросов, выполняемых как единое целое. Она либо завершается, либо отменяется, что гарантирует, что данные не окажутся в неконсистентном состоянии.

💬 На вопросы: какие базы данных бывают и как выбрать подходящую - ответили в комментариях!

🖥 Исходный код — перейти на сайт!

Снова знакомим с командой в «Исходном коде».

Часть 4: Артем

ℹ️ Поговорили с человеком, который помогает делать «мозг» приложения - серверную часть и бизнес-логику.

Ответы на главные вопросы в карточках!