О понимании потребностей и о формулировке задач
— Не получается сформулировать цель, которую будет решать новая фича? А может проблема в том, что сама задача не сформулирована? Смысл ещё и в том, чтобы методология помогла вытащить наружу проблемное определение задач и целей
— Проект не живет в статике - требования и функциональность постоянно меняются. Со временем, код превращается в кашу, т.к. на старте проект был спроектирован только под изначальный слепок пожеланий. И задача хорошей архитектуры в том числе - чтобы быть заточенной под изменяющиеся условия разработки.
Зачем?
Чтобы подобрать четкое имя сущности и понять ее составляющие, нужно отчетливо понимать - какая задача будет решена с помощью всего этого кода.
@sergeysova: Во время разработки, мы пытаемся каждой сущности или функции дать имя, которое четко отражает намерения и смысл выполняемого кода.
Ве дь, без понимания задачи, нельзя написать правильные тесты, покрывающие самые важные кейсы, проставить ошибки помогающие пользователю в нужных местах, даже банально не прерывать флоу пользователя из-за исправимых не критичных ошибок.
О каких задачах речь?
Frontend занимается разработкой приложений и интерфейсов для конечных пользователей, значит мы решаем задачи этих потребителей.
Когда к нам приходит человек, он хочет решить какую-то свою боль или закрыть потребность.
Задача менеджеров и аналитиков - сформулировать эту потребность, а разработчиков реализовать с учетом особенностей веб-разработки (потеря связи, ошибка бэкенда, опечатка, промазал курсором или пальцем).
Эта самая цель, с которой пришёл пользователь и есть задача разработчиков.
Одна маленькая решенная задача и есть feature в методологии Feature-Sliced Design — нужно нарезать весь скоуп задач проекта на маленькие цели.
Как это влияет на разработку?
Декомпозиция задачи
Когда разработчик принимается реализовывать задачу, для упрощения понимания и поддержки кода, он мысленно нарезает ее на этапы:
- сначала разбить на верхнеуровневые сущности и реализовать их,
- затем эти сущности разбить на более мелкие
- и так далее
В процессе разбиения на сущности, разработчик вынужден дать им название, которое четко отражало бы его замысел и при чтении листинга помогало понять какую задачу решает код
При этом не забываем, что пытаемся помочь пользователю уменьшить боль или реализовать потребности