Когда мы что-то проектируем, лучше всего сразу определиться с ограничениями. Это сильно помогает отвечать на вопросы, которые будут возникать сейчас и во время имплементации.
Давайте представим, что мы работаем на аутсорсе, команде дали новый проект — пишем API для трекинга радуг 🌈. Новый проект - новые возможности. Решили попробовать
Go, накидали архитектуру, подобрали библиотеки. Потом пошли с этим к заказчику, а он говорит — Go нельзя, нужно чтобы Node.js стек был, у нас тут все на Node.js.В итоге мы зря потратили время, и, возможно, потеряли мотивацию. Если бы мы знали и записали, что у нас есть технологическое ограничение использовать
Node.js стек, тогда мы бы и не предлагали Go. Но, возможно, подумали бы про TypeScript.Большинство ограничений можно условно разделить на такие группы:
Cost
- Какой бюджет запланирован для нашего решения?
Quality
- Насколько точно решение должно соответствовать функциональным требованиям? Может какие-то не критичны?
Time
- Когда решение должно быть готово?
Scope
- Если мы найдем пробелы в требованиях, как будем их устранять?
Technology
- Какие технологии можно использовать? Какие точно нельзя использовать?
Risk
- Что может пойти не так и как мы будем с этим справляться?
Resource
- Какие ресурсы необходимы, чтобы реализовать наш план? Например, доступы к API.
Compliance
- Каким международным и локальным законам должно соответствовать наше решение?
Для каждого типа ограничений можно придумать несколько вопросов. Те что представлены выше это лишь примеры.
⬛️ Еще раз — ограничения это хорошо. Когда они обговорены и записаны, то нам легче проектировать и реализовывать решение. Чем раньше вы договоритесь про ограничения, тем лучше.
Какие еще ограничения, которые я не упомянул, приходят в голову? Пишите в комментариях.
#хадрскиллы