Их просто надо понять.

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

Я смотрел на классы, функции, взаимодействия. Строил для себя образ проекта. И думал, что очередная написанная мною функция - это самое главное❗

Как-то работал в компании, которая занимается генерацией и квантовой передачей ключа. Появился партнёр из Южной Кореи и, соответственно, задача по созданию внешнего api для интеграции. Это была пилотная версия. До этого мы не могли интегрироваться по интернету. Были лишь локальные протоколы для сопряжения нашей железки и рядом стоящих шифраторов.

Прикинули типы и содержание http запросов. Этим, фактически, установили функциональные требования к системе. Нужно было выбрать библиотеку для реализации http интерфейса.
Составил excel табличку, заполнил по следующим критериям:
✅ Удобство пользования
✅ Поддержка от авторов/сообщества
✅ Функционал
✅ Скорость работы
Проанализировали командой результаты, выбрали.

Далее я стал реализовывать нужные классы с нужной обработкой, генерировать rpc(у нас был thrift) для связи с ядром системы. Всё было готово и протестировано. Партнёр мог забирать ключ по http запросу.

Моя работа была сделана. И я был ей доволен. Считал что сделал самое важное. 🥳

Сейчас же я понимаю, что работающая система > работающей функции. И важнее. Если ты смотришь на функционирование всей системы в целом.

Тогда был ещё специалист, который следил за всей сетевой инфраструктурой, фаерволом. Он обеспечивал связь внешний ip <-> внутренний ip железки. В случае отказа работы железки мы бы включили другую и специалист изменил бы маппинг. Пускай так. С зачатком автоматики процесса. Но это уже что-то.

Этим мы обеспечивали Availability/Доступность сервиса. Можно сказать, что специалист был Proxy/Load Balancer'ом. А наша вторая железка на подхвате - failover. Получается, что у системы мог быть определенный downtime из-за выхода из строя главной железки master. downtime мог также случится из-за отказа любой части сетевого оборудования на пути следования пакетов.

Протокол был https. Я генерировал, подписывал, отсылал сертификаты. То есть, мы ещё обеспечивали требование Security в плане прав доступа.
Могли бы ещё определять группы пользователей - сколько для пользователя данной группы доступно ключа в единицу времени. Определять стратегии, политики.

На этом примере я хотел показать, что изначально требования могут быть и не заданы явно. Что просто делаешь по наитию нужные вещи. И сам того не замечая реализуешь какие-то требования(их содержание).

А по мере погружения в System Design начинаешь подмечать больше. Размышляешь о том, как работает система целиком, насколько устойчива к падениям, обрывам, перегрузкам. Сознательно задумываешься о выделение каких-то основных требований(желательно до проектирования системы). И тогда уже можешь донести оформленные мысли коллегам, руководству и улучшить саму систему 💪

#Requirements