Чек-лист с критериями готовности функциональности приложения

Когда разработана новая функциональность, исправлен баг или завершена разработка приложения, можно обратиться к следующему чек-листу, чтобы проверить результат:

• Код был проверен и одобрен разработчиками, ответственными за функциональность.
• Все изменения, с которыми сталкивается пользователь, проверены и одобрены дизайнерами.
• Код соответствует дизайну с точностью до пикселя.
  • Точность до пикселя легко достигается средствами QML, так что к ней можно и нужно стремиться.
  • Значки, фоны, поля, цвета, шрифты соответствуют стилю ОС Аврора.
  • Реализация соответствует дизайну и общему стилю ОС Аврора.
• Реализованный пользовательский интерфейс работает плавно на устройстве.
  • Нет резких скачков, заминок или других заметных падений частоты кадров во время работы.
  • Внесённые изменения не влияют на время загрузки приложения или страницы.
  • Все переходы между состояниями пользовательского интерфейса плавные и анимированные.
  • Потребление памяти приложением остаётся разумным.
    • Рекомендуется использовать доступные инструменты для измерения и анализа производительности.
  • UI хорошо масштабируется до больших размеров.
• Функциональность завершённая.
  • Нет состояний, которые выглядят незавершёнными или выделяются в плохом смысле.
  • Нет пустых представлений, фиктивных или других временных данных, созданных только для разработки.
  • Пользователю предлагаются действия по восстановлению после возможных ошибок, таких как отсутствие сети или повреждение данных.
• Текст, отображающийся перед пользователем, переведён.
• Шрифты, цвета, поля и другие параметры макета взяты из Silica или Aurora Controls, чтобы гарантировать масштабируемость и единообразный внешний вид приложений.
• У функциональности есть модульные тесты, которые проверяют внутренние состояния и работу функций.
• Существующие тесты пройдены.
• Изменения не вызывают регрессии в других местах, тестируются участником и проверяются рецензентом.
• Код помещён в систему контроля версий.
• CI/CD успешна.

Дополнительные рекомендации:

• Разрабатывать и тестировать функции следует не только на эмуляторе, но и на реальном устройстве.
• Если разработчик не уверен, как должна вести себя функциональность, хорошей идеей будет проверить, как аналогичные функции были реализованы в демо-приложениях.
• Следует тщательно изучить практически всю документацию Qt Quick.
• Следует тщательно изучить документацию о производительности пользовательского интерфейса в Qt.
• Стоит измерять на практике, а не в теории, производительность интерфейса. Можно запускать профилировщик QML и собирать трассировки API в консоли, чтобы увидеть, что ничего лишнего не происходит за кулисами. Например, могут обнаружиться ненужные конструкции или компиляции компонентов QML, избыточные привязки, длинные вложенные вызовы функций JavaScript или блокирующие вызовы функций C++. Любая операция, которая останавливает основной поток на десятки или сотни миллисекунд, должна быть оптимизирована или выполнена вместо этого в отдельном потоке.