Схемы качества кода


Узнайте больше о ресурсах и оптимизации затрат → Организация кода

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

Шаблоны

Где искатьКак хорошо выглядит
Производительность в масштабах✅ Тестирование проверяет соответствие декларативных решений требованиям производительности при прогнозируемых объемах данных. Загрузочное тестирование в безопасной среде Full Copy Sandbox с реалистичными данными подтверждает масштабируемость перед развертыванием в производственной среде.
Анализ ремонтопригодности✅ Анализ TCO сравнивает долгосрочное бремя обслуживания декларативных и настраиваемых подходов, включительно с усилиями по модернизации, требованиями тестирования и требованиями к навыкам для будущих рабочих групп.
Архитектура смешанных подходов✅ Решения сочетают декларативный и программный подходы, где это уместно. Поток оркеструет логику высокого уровня, в то время как Apex обрабатывает сложные вычисления. Поля формул вычисляют простые производные, пока Apex обрабатывает пакетные операции.
Оценка AppExchange✅ Прежде чем создавать настраиваемый код, оцените существующие пакеты AppExchange, предоставляющие аналогичные функции. Результаты оценки документа, включая просмотренные пакеты, пробелы в возможностях и сравнение TCO.

Шаблоны

Где искатьКак хорошо выглядит
Доступность накопившихся вопросов✅ Элементы технической задолженности, отслеживаемые в ожидании с четкими метками, контекст, объясняющий, почему код нуждается в совершенствовании, влияние на бизнес, связанное с его оставлением без внимания, и примерные усилия по исправлению положения. Невидимый долг не может быть приоритизирован или управляем.
Инкрементное улучшение✅ Правило бойскаута, применяемое во время разработки функции: оставить код лучше, чем найти. Рабочие группы инкрементно исправляют задолженность во время работы над связанными функциями, а не требуют больших специальных проектов рефакторинга. Проверка кода проверяет инкрементные улучшения.
Профилактика над восстановлением✅ Ворота качества в CI/CD внедряют стандарты до того, как код достигнет производства. Сканер кода, ApexGuru и показатели сложности, интегрированные в проверку запроса на извлечение. Проблемы блокировки предотвращают слияние до их решения.

Антишаблоны

Где искатьКак плохо выглядит
Управление накопившимися вопросами⚠️ Технический долг признается устно, но не отслеживается в накопившихся делах. Отсутствие доступа к накоплению долгов. Исправление задолженности всегда откладывалось в пользу работы с функциями. Скорость постепенно снижается, команды не могут объяснить причину.
Качественный обход ворот⚠️ Качественные ворота CI/CD часто пропускаются под давлением расписания с намерением исправить позже. “Потом” не бывает. Ошибки сканера кода, обозначенные известными проблемами и пропущенные. Пороги сложности повышены для учета плохих внедрений.
Без возможности восстановления⚠️ 100% нагрузки спринта, распределенной для работы с функциями с нулевой нагрузкой для исправления технического долга. Долг накапливается бесконечно. Основные проекты рефакторинга, требующиеся каждые 18-24 месяца и занимающие целые кварталы.
Долг конфигурации⚠️ Типы настраиваемых метаданных и настраиваемые параметры накапливаются без очистки. Неиспользуемая конфигурация сохраняется неопределенно долго. Производство содержит 50 записей метаданных, фактически используется только 12. Нет документации, объясняющей цель значений конфигурации.

Шаблоны

Где искатьКак хорошо выглядит
Запуск архитектуры✅ Схема средства обработки триггера применяется последовательно: тонкие триггеры делегируют классам средства обработки, классы средства обработки систематизируют логику по контексту триггера (до вставки, после обновления), четкие имена методов раскрывают цель. Нет бизнес-логики в самих файлах триггера.
Внедрение уровня обслуживания✅ Бизнес-логика, воплощенная в классах обслуживания отдельно от контроллеров, триггеров и точек пакетного входа. Классы обслуживания, используемые повторно в нескольких точках входа без дублирования. Правило четкого наименования (AccountService, OrderProcessor).
Схема селектора✅ Запросы SOQL, централизованные в классах селектора на объект (AccountSelector, OpportunitySelector). Методы селектора возвращают последовательные наборы полей. Изменения оптимизации LDV, примененные один раз, влияют на все запросы.
Схема хранилища✅ Доступ к данным, абстрагированный за интерфейсами, включающими тестирование с имитацией источников данных. Внедрения хранилища содержат стратегии создания запросов, кэширования и оптимизации. Бизнес-логика зависит от интерфейсов хранилища, а не от конкретных внедрений.
Стандарты проектирования компонентов✅ Веб-компоненты Lightning следуют принципу единой ответственности, открывают свойства для конфигурации, излучают события для родительской коммуникации, предназначены для компоновки и повторного использования. Библиотека компонентов, документированная с примерами использования.
Организация кода✅ Связанные классы групп логической структуры пакета. Четкое разделение между логикой домена, доступом к данным, конечными точками API и адаптерами интеграции. Зависимости пакета текут в одном направлении.

Антишаблоны

Где искатьКак плохо выглядит
Триггеры⚠️ Вся бизнес-логика, встроенная напрямую в файлы триггера с глубоко вложенными условными условиями, без разделения забот, без классов обработчика. Файлы триггера 300+ строк, смешивающие проверку, бизнес-логику и вызовы интеграции. Невозможно эффективно протестировать.
Запрос в цикле⚠️ Запросы SOQL, выполненные в циклах итерации. Работает с небольшими объемами данных, но нарушает ограничение 100 запросов SOQL при обработке пакетных операций. Обнаруживается только при запуске запуска пакетной загрузки данных в производстве.
DML в цикле⚠️ Обозначения DML (вставка, обновление, удаление), выполняемые в циклах итерации. Нарушает ограничение операторов 150 DML с пакетными операциями. Каждая запись обрабатывается отдельной транзакцией базы данных, а не эффективной пакетной обработкой.

Шаблоны

Где искатьКак хорошо выглядит
Записи решений по архитектуре✅ Важные архитектурные решения, документированные в ADR, хранящиеся в управлении версиями. ОРР охватывают контекст (факторы, влияющие на деятельность предприятий, технические ограничения), решение (выбранные варианты), рассмотренные альтернативы (причины их отклонения) и последствия (компромиссы, условия для пересмотра).