Учимся декомпозировать задачи

Всем привет! Декомпозиция - это один из главных и важнейших навыков, которыми должны обладать разработчики. Как минимум, среднего уровня.

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

На старте своего пути, из-за нехватки опыта я не разбирался как правильно декомпозировать и брался делать огромные фичи разом, либо же как-то очень плохо разбил. В связи с этим получал огромную порцию выгорания, непонимания и проблемы со сроками. Рассказываю свой опыт, как это делаю я, а потом рассмотрим примеры.

Пропустим все моменты с ознакомлением документации, технических требований и т.п. К нам пришла фича, сделать новый экран, например уведомления. Для себя я её разобью так:

1. Начну с сетевого слоя. Напишу Endpoint, пропишу сервис, менеджер и тд.

2. Перед тем, как начну верстать UI, нужно убедиться нет ли таких элементов, которых у вас нет в проекте. Я думаю что у многих есть ДС или кастомные UI-элементы. Сверстаю экран.
3. Подключу сервис к экрану, проверка выполнение запросов.
4. Написание бизнес логики, архитектурных моментов. 
5. Проверка функционала.

Или давайте еще разберем пример на основе данного экрана.

Я начну с ендпоинта для данного экрана. Так как в документации мне говорят, что ячейки у нас будут тапаться и открываться детальная страница, то будет и post запрос.

Окей, мы написали ендпоинт для модуля. Далее нам нужно будет использовать наш ендпоинт в менеджере, чтобы в последующем реализовать сетевой запрос на сервер. Так же нам нужно создать модель данных, куда будет сохраняться ответ. 

2. Приступлю к верстке, изучив экран я понимаю, что тут одна переиспользуемая ячейка. Начну с неё. 

3. Хорошо, ячейка готова. Теперь нам необходимо сверстать экран со списком этих ячеек.
4. После предварительной вертски, нам нужно написать некую бизнес логику. Работу с данными, необходимо реализовать запрос получения данного API и его сохранения, чтобы в последующем в нашем UI, мы смогли взять реальные данные и проверить экран.

5. Результат:

Давайте для большего понимания, разберем еще пример.

Представим, что мы разрабатываем приложение для заказа еды. 

    *  Авторизация через социальные сети

    *  Ввод email и пароля

    *  Восстановление пароля

    *  Фильтры по типу кухни, району, рейтингу

    *  Список ресторанов с меню

    *  Карта с метками ресторанов

    *  Выбор блюд и добавление в корзину

    *  Ввод адреса доставки

    *  Выбор способа оплаты

    *  Отслеживание статуса заказа

    *  История заказов

    *  Изменение личных данных

    *  Настройки приложения

Модуль "Авторизация":  

    * Отвечает за все действия, связанные с входом и регистрацией пользователей.

    *  Отображает список ресторанов, реализует поиск и фильтрацию, работу с картой.

    *  Отображает выбранные пользователем блюда, позволяет изменять количество и удалять блюда.

    *  Обрабатывает платежные операции, интегрируется с платежными системами.

    *  Сохраняет и отображает информацию о пользователе, обрабатывает изменения настроек.

    *  Отображает список ресторанов с кратким описанием.

    *  Позволяет пользователю фильтровать список ресторанов по выбранным критериям.

    *  Отображает рестораны на карте, позволяет переходить к подробной информации о ресторане.

    *  Получает данные о ресторанах из API.

    *  Отображает информацию о ресторане в виде карточки.

    *  Обновляет список ресторанов после изменения фильтра или других действий пользователя.
И уже собственно экраны мы тоже можем декомпозировать, так как все зависит от cложности UI. Возможно нужно будет создать кастомный элемент или что-то подобное.

Декомпозиция задач —  это фундаментальная вещь для разработчика, которая позволяет облегчить и структурировать ваш подход к разработке.