Сколько времени в работе занимает проектирование?

Вопрос о доле проектирования в разработке

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

Ключевые факторы, влияющие на время проектирования

• Масштаб и сложность проекта:

    *   **Новый проект (Greenfield):** Здесь проектирование может занимать **от 15% до 30%** времени на начальном этапе (спринта или фазы). Необходимо выбрать технологический стек, определить **доменную модель**, спроектировать **архитектуру (монолит, микросервисы, модульный монолит)**, продумать ключевые **интеграционные паттерны** и **схемы баз данных**.
    *   **Доработка существующей системы (Brownfield):** Доля проектирования меньше — **5% - 15%**. Фокус смещается на анализ текущей архитектуры, поиск наиболее безопасного и эффективного пути интеграции новой функциональности без нарушения существующих контрактов и принципов (например, **Open/Closed Principle** из **SOLID**).
    *   **Критичный функционал (ядро системы, платежи):** Может потребовать **20% - 40%** времени на глубокий анализ, создание **Proof of Concept (PoC)**, проработку сценариев отказов (**failure scenarios**) и отката (**rollback strategies**).

• Методология разработки:

    *   **Гибкие методологии (Agile/Scrum):** Проектирование не является отдельной длительной фазой, а распределено по итерациям. В начале каждого спринта на **планировании (Sprint Planning)** и **проектировании (Backlog Refinement)** может уходить **10% - 20%** времени спринта. Это итеративное, "just-in-time" проектирование.
    *   **Более формальные подходы (Waterfall, RUP):** Предполагают выделенную, длительную фазу проектирования, которая может составлять **30% - 50%** от всего жизненного цикла проекта до начала реализации.

• Опыт команды и зрелость домена:

    *   Работа в знакомой предметной области (**Domain**) или с хорошо известными шаблонами (**Patterns**) сокращает время на проектирование. Необходимость осваивать новую сложную область (**например, machine learning pipeline**) увеличивает его.

Пример из практики: реализация нового API эндпоинта

Давайте рассмотрим условный пример в контексте C# Backend в Agile-команде.

// 1. Анализ требования (часть проектирования): "Добавить endpoint для поиска заказов с фильтрацией".
// 2. Проектные вопросы, которые нужно решить ДО кодирования:
//    - Какая структура DTO для запроса и ответа?
//    - Как интегрироваться с репозиторием? Нужен ли новый метод или хватит существующего?
//    - Какая стратегия пагинации? (PageNumber/PageSize vs Cursor)
//    - Как кэшировать результаты? (Redis, IMemoryCache)
//    - Как обеспечить безопасность? (Требуется ли роль "Manager"?)
//    - Какие интеграционные тесты написать?

// 3. Результат проектирования — контракт и план:

// DTO для запроса (проектирование интерфейса)
public class OrderSearchRequest
{
    public int? CustomerId { get; set; }
    public DateTime? FromDate { get; set; }
    public OrderStatus? Status { get; set; }
    public int PageNumber { get; set; } = 1;
    public int PageSize { get; set; } = 50;
}

// DTO для ответа
public class PagedResponse<T>
{
    public List<T> Items { get; set; }
    public int TotalCount { get; set; }
    public int PageNumber { get; set; }
}

// Интерфейс сервиса (определение контракта)
public interface IOrderSearchService
{
    Task<PagedResponse<OrderDto>> SearchOrdersAsync(OrderSearchRequest request, CancellationToken ct);
}

На такую проработку для среднесложного эндпоинта у опытного разработчика может уйти от получаса до 2-3 часов (что при двухнедельном спринте составляет небольшую долю). Для сложной фичи, например, внедрения шаблона CQRS с использованием MediatR и отдельной читаемой модели, проектирование займет день или больше.

Принципиальная позиция

Как Senior-разработчик, я считаю, что качественное проектирование — это инвестиция, которая многократно окупается. Пропуск этой фазы ведет к:

• Техническому долгу из-за непродуманной структуры.
• Сложностям в тестировании и поддержке.
• Необходимости постоянных рефакторингов.

Мое правило: время на проектирование должно быть адекватно сложности изменения. Для мелкого баг-фикса — это 5-10 минут обдумывания и просмотра кода. Для крупной фичи — это обязательно:

• Схематичное изображение (на доске или в диаграммах Sequence/Component).
• Обсуждение с командой (архитектором, тимлидом, коллегами).
• Проработка контрактов (API, сообщений).
• Оценка рисков и граничных условий.

Итог: В среднем, в современной Agile-разработке на C# Backend, если говорить о нормальных, среднесложных задачах, доля активного, осознанного проектирования (включая обсуждения, рисование диаграмм, написание контрактов) обычно составляет от 10% до 25% общего времени работы над задачей. Ключ не в проценте, а в понимании, что проектирование — это непрерывный процесс, который происходит и в голове при написании каждой новой строки кода, следуя принципам чистой архитектуры и DDD (Domain-Driven Design).