Ответ
Нет. В реальной разработке существует баланс между строгими регламентами и зонами гибкости, необходимой для эффективной работы и адаптации к контексту.
Что обычно строго регламентировано (стандарты команды/компании):
- Стиль кода: Code Style Guide (например, Google Java Style), регулирующий отступы, именование, структуру файлов.
- Процессы: Работа с Git (ветвление, коммиты), ревью кода, CI/CD пайплайны.
- Архитектурные принципы: Следование SOLID, Clean Architecture, использование утверждённых паттернов.
- Безопасность: Правила обработки данных, аутентификации, валидации входных данных.
Где часто есть гибкость (прагматичные решения):
- Выбор библиотек/фреймворков для решения конкретных задач (например, выбор между MapStruct и ModelMapper для маппинга).
- Детали реализации некритичных или экспериментальных функций.
- Оптимизация под специфические нефункциональные требования (производительность, масштабируемость).
Пример:
// Регламент: имена констант в UPPER_SNAKE_CASE
public static final int MAX_LOGIN_ATTEMPTS = 3;
// Регламент: аннотация @Override обязательна при переопределении
@Override
public String toString() { ... }
// Гибкость: выбор стратегии кэширования (Guava, Caffeine, Spring Cache)
// может зависеть от требований проекта, а не от жёсткого правила.
@Cacheable(cacheNames = "users", cacheManager = "caffeineCacheManager")
public User findUserById(Long id) { ... }Цель регламентов — обеспечить согласованность, поддерживаемость и качество, а не ограничить творческий подход к решению проблем.