День 2283. #УрокиРазработки
10 Уроков Качества Разработки ПО. Начало
1. Поймите разницу между внутренним и внешним качеством
Одна из самых сложных частей нашей работы как разработчиков и архитекторов — помочь менеджерам и нетехническим владельцам продукта понять, что мы подразумеваем под плохим качеством ПО. Ключ — различать внутреннее и внешнее качество.
Внешнее качество — это то, что волнует менеджеров и владельцев продукта. Они заметят, когда отзывчивость или удобство использования будут плохими, или когда ошибки, особенно повторяющиеся, будут накапливаться. Но внутреннее качество? Это наша область. Это та часть, которую они не видят, пока технический долг не снизит скорость доставки новых функций до минимума.
Вот некоторые внутренние признаки качества:
- Читаемость
Что делает код и как он работает?
- Тестируемость
Делает ли он то, что должен?
- Изоляция
Могу ли я изменить это, не сломав что-то еще?
- Обнаруживаемость
Где в системе определено нужное поведение?
- Прослеживаемость
Почему было принято это решение (в коде, архитектуре или дизайне)?
2. Делайте код автоматически тестируемым
Знакомо ли вам то чувство, когда вы изменяете код в кодовой базе, с которой вы не на 100% знакомы, но вы полностью уверены, что автоматизированные тесты вас поддержат? Классные ощущения, правда? Теперь представьте себе похожую кодовую базу, но без такого тестового покрытия. Звучит пугающе.
А что, если вы знаете кодовую базу вдоль и поперёк? Достаточно ли вы уверены, чтобы вносить изменения, не рискуя получить катастрофическую ошибку?
Для тех, кто не чувствует себя уверенно, пришло время инвестировать в автоматизированное тестирование. Начните с создания временной страховочной сетки, используя стратегию тестирования характеристик. Затем начните проектировать код для поддержки подхода «сначала тест». Относитесь к своим тестам как к первоклассному коду. Кодовая база, где 40–50% кода является тестами – это здорово.
3. Не терпите нестабильности в автоматизированном тестировании
Каждый разработчик, который пытался создать набор автоматизированных end-to-end тестов, сталкивался с кошмаром их нестабильности. Да, вы можете гордиться тем, что у вас есть солидное количество тестов. Но если вы не можете положиться на эти тесты из-за их нестабильности, это может стать серьёзной головной болью. Определить, провалился ли тест из-за реальной проблемы в коде базе или просто из-за нестабильности, сложно, особенно когда сбой не связан с конкретным изменением кода.
Чаще всего люди просто повторно запускают тест и надеются на лучшее. Назначить кого-то для расследования этих сбоев сложно, и неопределённость может подорвать производительность. Это может показаться очевидным, но не относитесь к нестабильности как к техническому долгу, который нужно устранить позже. Относитесь к ней как к производственному сбою, требующему немедленного внимания.
Если вам повезло использовать инструмент сборки, такой как TeamCity, вы можете отслеживать нестабильность тестов с течением времени, отмечать тесты как нестабильные и отключать их из конвейера сборки. А ещё лучше — назначить нестабильный тест кому-то для анализа и исправить его, позволяя сборке успешно завершиться. Это позволит нескольким разработчикам не тратить время, пытаясь выяснить, нужно ли им что-то делать с нестабильным тестом. Если у вас нет этих инструментов, договоритесь всей командой о том, чтобы отдать приоритет исправлению нестабильных тестов, чтобы снова сделать сборку зелёной.
Продолжение следует…
Источник: https://www.dennisdoomen.com/2025/03/10-quality-lessons.html
>>Click here to continue<<