Как наработать навык декомпозиции задач?

По поводу декомпозиции. Обычно такой вопрос возникает когда кода много или когда задача большая.
Эта декомпозиция идет параллельно со знанием таких частей ООП как Single-Responsibility, и структурных
шаблонов проектирования. Начни это применять и декомпозиция сама собой пойдет.

Чаще заказывай code-review своего кода и слушай советы старших коллег. Даже если обидно и стыдно.
Слушай. Записывай и потом применяй.

По поводу Алгоритмов и Структур данных. Почитай Никлауса Вирта. Он как раз такую книгу и написал.

А что сейчас за должность, раз не разработчик?

Для получения навыка решения алгоритмических задач есть куча соответствующих сайтов — начинаешь с самых простых уровней.

Для развития логического мышления изучи формальную логику и так же решай задачи.

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

Хочу отметить, что абстрактная декомпозиция никому не нужна (даже вредна, поскольку тратит бесценное время). Нужно уметь видеть в постановке задач доступные для тебя «кирпичики» и работать только с ними, пока они функционируют с удовлетворительным качеством.

Для примера пусть тебе нужно дёрнуть REST-функция с некоторого интернет сервера. Если у тебя есть библиотека, которая позволяет тебе сделать все на уровне «указал сервер», «указал метод», «указал параметры» и «получил результат», то зачем декомпозировать дальше на уровень реализации протокола HTTP, на работу с сокетами, ломать голову над маршрутизацией пакетов данных или вообще уходить на уровень управления сетевой картой с помощью прерываний?

Вторая мысль, на которой хочу остановится — не нужно делать чужую работу. Часто задачи на разработку дают уже максимально декомпозированные (есть целый класс мемов противопоставления навороченного собеседования и реальной примитивной работы в ИТ). Обычно программисты не общаются с заказчиком — там целая прослойка менеджеров для ограничения «аппетитов» и аналитиков для составления максимально подробной задачи. Но и «подробная задача» не сразу попадает на выполнение — часто сначала она оказывается на столе у системного архитектора, который уточняет доступный стек и разрешенные фреймворки. Потом задача попадает к техлиду, который дополняет ее своими практическими советами и ссылками на релевантные проекты.

Не обязательно, что программиста «кормят с ложечки», но если вы не программист 1С, то один-на-один с задачей вас никогда не оставят!!!

И последняя мысль — нужно меньше думать, а больше делать! Если сесть читать Кнута и Вирта, то голова будет забита бесполезной чепухой, которой можно хвастаться перед друзьями, но которую невозможно использовать ни при создании репозиториев в Spring Data, ни при описании активити в твоем мобильном приложении — внезапно окажется, что нужно было читать не беллетристику, а курить мануалы по Spring и Android.

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

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

Определите сущности, которыми будете пользоваться. Например, нужно сделать чат. Какие сущности данных у вас могут быть? Наверное Пользователь, от имени которого будут отправляться Сообщения. Сообщения будут отправляться в Каналы. У каждой сущности есть какой-то свой набор данных.

Далее определите действия, что вы можете сделать с этими сущностями. Под эти действия заводите сервисы.

Понимание того, как лучше будет приходить с опытом, причем не только вашим личным, но и командным.