Анализ источника багов как начало улучшения процессов работы в команде

У нас есть один достаточно сложный и душный проект. На нём трудятся специалисты самых разных направлений, в том числе бизнес-аналитики, системные аналитики, разработчики, тестировщики. Сложный проект и такая команда требуют качественной координации и слаженной работы – что-то сломаться может где угодно.

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

В результате этого процесса получилось классифицировать баги:
– кейс не проработан бизнес-анализом
– кейс не проработан системным анализом
– в требованиях нечёткие формулировки: аналитик написал как-то расплывчато, разработчик не пошёл уточнять
– ошибка разработчика
– ёпрст, никто об этом не думал, бизнес сам не представлял, что такое бывает

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

Меня, конечно, в первую очередь интересует системный анализ и разработка, на этом и сосредоточились.

✅ По части разработки выявили проблему тестирования миграций, команда бекенда пошла думать, как улучшить тесты в эту сторону, а также продумать алертинг.

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

Вот такие жирные проблемы удалось выявить в результате анализа природы багов и решения, к которым удалось прийти.
#devfm #systemdesign

Багскрам

Недавно поднимали вопрос классификации багов и во что это может вылиться.

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

Для таких случаев существует такая замечательная процедура, как багскрам.

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

Обычно на встрече присутствуют тестировщики, команда разработки и руководитель проекта. Если система сложная, то привлекаются аналитики. Встреча получается очень дорогая, поэтому проводить её нужно, понимая цель, чётко и быстро.

Проводить багскрам следует по следующему сценарию:

Подготовка
Заранее выбрать скоуп багов, которые хотите разобрать.

Встреча
1. Тот кто проводит встречу, планомерно открывает каждый из багов.
2. Тестировщик, который завёл баг, тезисно описывает проблему.
3. Команда обсуждает баг, появляется и фиксируется какая-то дополнительная информация. Далее определяется приоритет бага, назначается ответственный. Очень важно, чтобы во время обсуждения руководитель проекта или любой другой фасилитатор следил за тем, чтобы встреча не уходила не в то русло и шла чётко по плану.
4. По результату обработки бага оставляется комментарий о том, что баг рассмотрен на багскраме. Это нужно, чтобы по нескольку раз не смотреть одно и тоже. Если на следующем багскраме окажется снова этот баг, то возникнут закономерные вопросики.

Периодический багскрам в целом не даёт багам накапливаться и превращаться в неуправляемую массу.

А на тех проектах, где такое мероприятие у нас проводится, конечно, зафиксирован процесс: участники, периодичность, правила, примеры фильтрации багов в системе контроля задач. Чтобы любой человек мог ознакомиться с процессом.
#devfm #teamwork

Некоторое время назад прочитал у Николая Хитрова пост о том, как он затащил к себе на проект gitlint — инструмент для валидации commit messages.

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

Ребята внедрили себе gitlint и уже несколько месяцев полноценно им пользуются. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)

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

За вдохновением по правилам написания коммитов загляните сюда.

Чтобы всем этим добром легче пользоваться, существуют всевозможные плагины для вашей IDE.

Вдогонку посмотрите еще на comimitizen.

Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.
#devfm #tools

Стрим: разбираем Fastapi + Docker

Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.

В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке — код на гитлабе, проект в докере, в процессе используем Postman и смотрим web console браузера.

Предыдущий стрим про разработку небольшого проекта python-students.

#devfm #youtube #python
#СоерКлуб

Автоматизируй автоматизируемое

Это пост для исключительно для маководов.

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

Начну с банального: слёзы текут, когда вижу как кто-то неуклюже ищет нужное ему окно. Ой, это браузер, ой, это почта, блин, это IDE, фух, вот же он — телеграмчик!

Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.

Штука рекомендуема к использованию абсолютно всем. Периодически буду делать посты, рассказывая, что ещё интересного с помощью неё делаю.

Также стоит обратить внимание на плагины для Raycast — они предоставляют какое-то нереальное количество возможностей. Переводчик, управление зумом, очистка текста в clipboard от спец символов, конвертер времени из юникс формата — всё через плагины.
#devfm #tools

Как я использую папки в Телеграм для удобства

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

#devfm #edu #tools

Docker в каждый дом

Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.

Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.

#skills #sudo #devfm

Задача на собеседовании — проектируем динамическую фильтрацию

Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области для понятности. Задача такая:

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

Если вам на собеседовании поставили задачу в такой размытой формулировке, не пытайтесь сразу приступать к её решению. В первую очередь уточните требования и ограничения.

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров

— количество записей в результате поиска может доходить до 1кк

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

— у разных категорий товаров разный набор фильтров

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

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

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 15:00 понедельника.
#devfm #systemdesign #резюме

DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)

В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.

Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork

Наш бесплатный курс "Командная строка для разработчиков"

Мы много лет готовим python-разработчиков. Подготовку начинаем с базовых знаний Linux, где прививаем желание и умение работать в терминале. Вдохновляясь курсом "Поколения Python" на степике, сделали бесплатный курс Командная строка для разработчиков, посвящённый терминалу в Linux. Начинающим разработчикам поможем преодолеть неловкость перед текстовым терминалом, опытным разработчикам покажем неочевидные и полезные в работе фишки для увеличения продуктивности.

Уроки курса:
— Команды и работа с файловой системой из терминала
— Модифицируем файловую систему
— Управляем сотнями файлов и пишем первый скрипт
— Знакомимся с текстовыми редакторами nano, mcedit, gedit, vim
— Разбираемся с процессами, jobs, fg, bg, ps, grep и конвейером
— Настраиваем терминал "под себя"
— Разграничение прав доступа и работа с учётными записями

#devfm