SQM 14/24: Tech Debt

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

• Метрики позволяют объективно оценить качество кода и сравнить проекты.  

• Метрики помогают принимать решения о поощрении, увольнении и улучшении кода.  

• Программирование рассматривается как дискретный процесс, а не как художественное творчество.  

• Важно измерять и оценивать качество шагов в программировании.  

• Программирование на 99% состоит из рутинного производства элементов кода.  

• Программирование сравнивается с строительством дома, где каждый элемент важен.  

• Основная задача - правильно и ровно уложить кирпичи кода.  

• Творческий подход важен, но не должен мешать соблюдению стандартов и метрик.  

• Программирование требует дисциплины и знания стандартов.  

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

• Метрики помогают оценить качество работы программиста.  

• Технический долг - это долг перед будущими разработчиками за не исправленные ошибки.  

• Пример: отсутствие документации к функции.  

• Технический долг накапливается и приводит к появлению новых дефектов.  

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

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

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

• Технический долг включает недоработки и потенциальные улучшения, которые не были реализованы.  

• Примеры: отсутствие юнит-тестов для функций, что приводит к увеличению количества ошибок.  

• Программисты часто не пишут тесты из-за лени, нехватки времени или некомпетентности.  

• Каждый кусок кода должен иметь соответствующий тест.  

• Тестирование должно охватывать разные сценарии использования кода.  

• Многие программисты не пишут тесты, что увеличивает количество ошибок в будущем.  

• Измерение технического долга сложно и не очевидно.  

• Методика "пазл дривен девелопмент" помогает понять и минимизировать технический долг.  

• Пример: функция Фибоначчи с пропущенными тестами, что приводит к ошибкам в будущем.  

• Программисты оставляют комментарии с пометкой "туду" для будущих исправлений.  

• Пример: комментарий "не знаю, что делать при n больше 2" для функции Фибоначчи.  

• Будущие программисты могут решить проблему, удалив комментарий и реализовав правильный код.  

• Решение должно удовлетворять текущим потребностям.  

• Ответственность программиста - учитывать будущее.  

• Добавление новых тестов и исправление ошибок.  

• Добавление новых тестов для проверки корректности.  

• Удаление неработающих частей кода и тестов.  

• Инкрементальное управление техническим долгом.  

• Комментирование неработающих частей кода.  

• Создание тестов для временно нерабочих блоков.  

• Контроль технического долга через комментарии и тесты.  

• Неправильный код в репозитории недопустим.  

• Программисты берут в долг, как и люди.  

• Ожидание быстрой имплементации функционала.  

• Качество кода важнее его полноты.  

• Программисты должны быстро доставлять код.  

• Декомпозиция задач для улучшения качества и скорости.  

• Плохой программист задерживает проект.  

• Некачественный код и нарушение метрик.  

• Хороший программист быстро работает и документирует задачи.  

• Программист разбивает задачу на мелкие составляющие.  

• Выступает в роли менеджера и архитектора.  

• Декомпозиция помогает справиться с большими задачами.  

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

• Задача должна быть короткой и решаться в течение одного-двух дней.  

• Программисты должны делать половинчатые решения, оставляя технический долг.  

• Технический долг растет с каждым новым коммитом.  

• Программисты добавляют много мусора в код, что увеличивает количество технического долга.  

• Важно документировать и анализировать технический долг для его уменьшения.  

• Количество технического долга может колебаться, но в целом оно уменьшается.  

• Программисты могут создавать новые задачи при исправлении старых.  

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

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

• Если проект не меняет свою функциональную природу, можно предсказать финал.  

• Динамика изменения технического долга предсказуема и повторяется из проекта в проект.  

• Zero Puzzles — бесплатный и опенсорсный сервис для управления техническим долгом.  

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

• Сервис сканирует исходный код и находит места с пазлами, сохраняя их в базе данных.  

• Новый коммит в репозитории создает новый пазл.  

• Робот сканирует исходный код и создает тикет в GitHub.  

• Программист получает уведомление о новом пазле и задаче.  

• Робот может работать с приватными репозиториями.  

• Для создания тикетов роботу нужен доступ к исходному коду.  

• Тикет используется для отслеживания задач и бэклога.  

• Программист берет задачу и начинает работу.  

• Робот создает новые тикеты для недоделанных участков кода.  

• Программисты исправляют код и удаляют пазлы.  

• Робот закрывает тикеты, если пазл удален.  

• Тикеты, созданные роботом, не могут быть закрыты вручную.  

• Робот переоткрывает тикеты, если пазл не удален.  

• Пазлы формируют иерархию задач.  

• Робот создает новые задачи на основе недоделанных участков.  

• Программисты работают над задачами, удаляя пазлы.  

• За два года работы создано 264 пазла.  

• Пазлы фиксируются и закрываются.  

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

• Технический долг увеличивается по мере работы.  

• Разбиение задач на этапы помогает управлять долгом.  

• Иерархия пазлов помогает контролировать код и задачи.  

• Ожидание от программиста полного решения задачи деструктивно.  

• Программисты часто готовы решать задачи небольшими шагами.  

• Это мотивирует их на создание небольших пури-квестов.  

• Важно отслеживать динамику технического долга.  

• График может помочь понять, движется ли долг вниз или вверх.  

• Это помогает менеджерам проектов оценивать прогресс.  

• Данные для графиков можно легко получить из одного большого документа.  

• Можно написать анализатор для создания графиков.  

• Это полезно для всех репозиториев и помогает расслабить программистов.  

• Малые пури-квесты более выгодны для проекта.  

• Большие пури-квесты менее подвержены детальному анализу.  

• Малые пури-квесты легче анализировать и исправлять ошибки.  

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

• Другие утверждают, что малые пури-квесты лучше подходят для ревью.  

• Важно найти компромисс между качеством и объемом кода.  

• Пример тикета, созданного роботом.  

• Робот создает пазлы и прикрепляет их к тикетам.  

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

• Тикет с номером 27027 содержит описание задачи и инструкции по её выполнению.  

• Программист должен удалить блок кода и отправить пул-реквест на проверку.  

• Если ревьювер принимает пул-реквест, тикет закрывается, а программист получает вознаграждение.  

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

• Важно интегрировать код между программистами для создания единого проекта.  

• Процесс напоминает муравейник, где каждый муравей выполняет свою задачу, но в итоге получается сложная структура.  

• Пример с задачей Фибоначчи показывает, как небольшие изменения приводят к эффективному результату.  

• Ошибки и исправления помогают двигаться вперед, а не ждать идеального решения от одного программиста.  

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

• Программисты должны вносить небольшие изменения и быстро передавать их в репозиторий.  

• Важно измерять производительность количеством пул-реквестов, а не их качеством.  

• Контроль качества необходим для предотвращения некачественных изменений.  

• Большое количество тикетов может затруднить работу команды.  

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

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

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

• Робот может создавать слишком много задач, не понимая их семантики.  

• Необходимо, чтобы робот ставил только самые важные задачи, а остальные откладывал.  

• Вопрос: как робот будет принимать решение о приоритезации задач?  

• Решение: использование машин обучения и статистики.  

• Методика сортировки задач на основе истории их выполнения.  

• Использование истории выполнения задач для их приоритезации.  

• Сравнение с историческими данными для проверки эффективности.  

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

• Большой бэклог задач демотивирует программистов.  

• Нейросеть помогает сузить объем работы и повысить мотивацию.  

• Важно контролировать и понимать объем технического долга.  

• Оценка сложности задач по их положению в дереве.  

• Суммирование незакрытых задач для оценки общего объема технического долга.  

• Измерение технического долга в человеко-часах для оценки его влияния.  

• Инструмент для приоритезации задач стабилен и используется в open source проектах.  

• Возможность добавления новых функций и анализа данных.  

• Призыв к использованию и улучшению инструмента.