Программный фреймворк предоставляет рекомендации по написанию кода для конкретной цели. Например, если цель - создание веб-приложений, а язык - JavaScript, эффективными могут быть такие фреймворки, как React или Angular. Если цель - создание микросервисов, которые имеют малый вес и хорошее оповещение об ошибках, то хорошими вариантами могут быть Python или TypeScript. Аналогично, существуют программные фреймворки, такие как Kedro, для написания конвейеров данных и моделей машинного обучения.
Программные фреймворки представляют собой способ организации кода и облегчают повторное использование функциональных возможностей кода, что позволяет ускорить разработку.
Обеспечьте последовательность в написании кода
Линтер кода - это инструмент статического анализа кода, используемый для выявления ошибок программирования, багов, стилистических ошибок и подозрительных конструкций. Различные языки кода часто имеют свои собственные инструменты (Super Linter на GitHub поддерживает несколько языков). Например, для языка программирования Python есть такие инструменты, как Pylint, а для языка программирования JavaScript - JSLint. Эти инструменты могут запускаться agile-подразделениями для проверки соответствия создаваемого ими кода единым стандартам качества.
Определитесь с фреймворком тестирования для проверки кода
Agile-подразделения используют тестовый фреймворк для написания модульных тестов для кода, который они пишут. Различные языки программирования поддерживают свои собственные тестовые фреймворки: в языке Python есть pytest или unittest, а в языке программирования JavaScript - Jest. Независимо от выбранного тестового фреймворка (их существует множество), ключевым моментом является стандартизация фреймворка и обеспечение того, чтобы все подгруппы использовали его.
Существуют различные типы тестирования, которые пишут инженеры в agile pods (см. Рисунок 19.3).
Для решений, где надежность и производительность особенно важны (например, сайт электронной коммерции, соответствие нормативным требованиям), рассмотрите возможность выделения отдельной функции инженера по надежности сайта (SRE) для работы над сценариями производительности и надежности. В то время как инженеры DevOps сосредоточены на решении проблем конвейера разработки, инженеры по надежности сайта решают проблемы эксплуатации, масштабирования и надежности. Команды SRE - это высококвалифицированные инженеры, которые сосредоточены на решении проблем в течение определенного периода времени, а затем переходят к другому решению.
Минимизация сложности кода
Очень важно, чтобы сложность кода была минимальной. Система метрик кода анализирует код с помощью различных математических методов, в основном для того, чтобы определить, насколько он сложен. Различные сторонние продукты, такие как SonarQube, изучают код, хранящийся в системе контроля версий, чтобы понять его сложность и сообщить о его состоянии. Эти инструменты (некоторые с открытым исходным кодом, некоторые платные) также ищут уязвимости в коде или уязвимости в зависимостях, используемых кодом.
Стратегии тестирования - определения
Тестирование на проникновение
Регрессионное тестирование
Проверка устойчивости приложения к кибернетическим атакам
Обеспечивает отсутствие негативных последствий для существующих программных приложений при добавлении новой функциональности
Увеличение стоимости и времени тестирования
Тестирование производительности/нагрузки
Приемочное тестирование
Сплошное тестирование (системы)
Обеспечивает работоспособность приложения в различных условиях, имитируя одновременный доступ к приложению нескольких пользователей
Обеспечивает корректную работу приложения с точки зрения пользователя
Убедитесь, что все приложение в целом ведет себя так, как ожидается
Интеграционное тестирование
Проверка путей связи и взаимодействия между компонентами для выявления дефектов интерфейса
Модульное тестирование
Тестирует отдельные блоки (модули, функции, классы) в изоляции от остальной части приложения
ПРИЛОЖЕНИЕ 19.3
Автоматизируйте создание документов для обеспечения соответствия нормативным требованиям
В некоторых отраслях необходимо документировать код и API до того, как код будет запущен в производство. Многие языки предоставляют механизм для встраивания документации в сам код (в виде комментариев). Затем инструменты могут сканировать код и автоматически генерировать документацию в удобочитаемую форму. Эта документация может храниться в системе контроля исходных текстов вместе с кодом и использоваться в качестве аудита кода в данный момент времени.
Генерировать документацию из кода предпочтительнее, чем заставлять разработчиков писать ее вручную, поскольку это более эффективно по времени и более точно (хотя разработчику все равно придется подтверждать, что документация точна на 100 %). В некоторых отраслях такая документация может помочь соблюдению нормативных требований и регуляторам "подписать" то, что выпускается в производство.
Обеспечьте сквозную автоматизацию с помощью непрерывной интеграции и непрерывного развертывания (CI/CD)
