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

Проблем много. Одна из самых частых — неумение анализировать требования и сопоставлять их с реальными ограничениями.

Простой пример. Человек разрабатывает систему с требованием «Задержки обработки платежа не более 5 сек в 99,9%», а решение собирает на облачных лямбдах, у которых фаза холодного старта легко сожрёт весь бюджет времени. Человек буквально не видит связь между требованием, ограничением и реализацией.

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

Базово нужно научиться выделять хотя бы основные эвристики по типу «лямбды медленно стартуют на холодную». Это поможет видеть совсем дырявые решения.

Если есть требование, оно всегда порождает ограничения и существует в определённых границах. Проектирование — это и есть процесс поиска решения, которое соответствует ограничениям и требованиям. Значит, процесс проектирования всегда включает анализ и сопоставление требований с решением. Для этого нужно знать методы сопоставления — экспертные оценки, бюджетирование, прототипирование и т.д. Если требования есть, а оценки нет — это не проектирование.

Говорить красивые фразы по типу «Вследствие CAP-теоремы у нас есть требование консистентности» — это здорово. Жаль только, что это просто набор красивых слов, за которыми ноль смысла. Лучше вообще отказаться от требований, которые не можете проверить, чем пытаться закрыть их бессмысленными фразами.

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