Словарь терминов

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

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

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

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

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

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

Код, который легко понять, просто модифицировать и который ясно выражает намерение программиста. Философия, популяризированная Robert C. Martin.

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

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

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

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

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

Static Application Security Testing — метод анализа исходного кода на уязвимости безопасности без выполнения программы.

Dynamic Application Security Testing — метод тестирования запущенных приложений на уязвимости безопасности путем симуляции атак.

Open Worldwide Application Security Project — некоммерческий фонд, работающий над улучшением безопасности ПО через проекты с открытым исходным кодом под руководством сообщества.

Регулярно обновляемый список 10 наиболее критических рисков безопасности веб-приложений, публикуемый OWASP как стандартный документ для информирования разработчиков.

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

Процесс проверки личности пользователя, устройства или системы. Отвечает на вопрос "Кто вы?" (в отличие от авторизации, которая отвечает "Что вы можете делать?").

Практика безопасного хранения, распространения и ротации конфиденциальных данных: API-ключей, паролей, учётных данных баз данных и сертификатов.

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

Автоматический анализ кода для обнаружения уязвимостей безопасности, багов и проблем качества кода, обычно интегрированный в CI/CD пайплайны.

Подход, интегрирующий практики безопасности в каждую фазу DevOps-пайплайна, делая безопасность общей ответственностью команд разработки, безопасности и операций.

Техника внедрения кода, которая эксплуатирует уязвимости безопасности в слое базы данных приложения путём вставки вредоносных SQL-выражений в поля ввода.

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

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

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

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

Continuous Integration и Continuous Delivery/Deployment — набор практик для автоматизации сборки, тестирования и деплоя изменений кода.

Набор практик, объединяющих разработку ПО (Dev) и IT-операции (Ops), направленных на сокращение цикла разработки и непрерывную доставку качественного ПО.

Встроенная CI/CD платформа GitHub, позволяющая автоматизировать рабочие процессы ПО прямо из репозитория с помощью YAML-файлов конфигурации.

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

Скрипты, автоматически запускающиеся перед созданием git-коммита для обеспечения стандартов качества кода, запуска линтеров и предотвращения коммита проблемного кода.

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

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

Методология тестирования, проверяющая весь рабочий процесс приложения от начала до конца, симулируя реальные сценарии пользователя включая UI, API, базы данных и внешние интеграции.

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

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

Минимальный процент кода, который должен быть покрыт тестами, обеспечиваемый в CI/CD пайплайнах для гарантии, что новый код не снижает общее покрытие тестами.

Техника оценки качества тестов путём внесения небольших изменений (мутаций) в код и проверки, обнаруживают ли их тесты. Необнаруженные мутации указывают на слабые тесты.

Метод отправки изменений кода на проверку перед слиянием в основную ветку. Также известен как merge request (MR) в GitLab.

Распределённая система контроля версий, отслеживающая изменения в исходном коде во время разработки ПО, позволяющая нескольким разработчикам работать вместе.

Термин GitLab для пул-реквеста — метод отправки изменений кода на проверку перед слиянием в другую ветку. Функционально идентичен пул-реквесту GitHub.

Снимок изменений в Git-репозитории, который записывает модификации файлов вместе с сообщением, описывающим что изменилось и почему.

Независимая линия разработки в Git, позволяющая разработчикам работать над фичами, исправлениями или экспериментами без влияния на основную кодовую базу.

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

Модель ветвления в системе контроля версий, где разработчики сотрудничают над кодом в единственной ветке "trunk" (или main), избегая долгоживущих фича-веток.

Метрика ПО, измеряющая количество независимых путей через исходный код программы, указывающая на сложность кода и тестируемость.

Четыре ключевые метрики, определённые командой DevOps Research and Assessment (DORA), измеряющие производительность доставки ПО: частота деплоев, время от коммита до продакшна, процент неудачных изменений, время восстановления сервиса.

Пять принципов проектирования для объектно-ориентированного программирования, способствующих поддерживаемому, гибкому и понятному коду: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.

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