Максима Дорофеева, вопрос относительно декомпозиции задач:
Допустим архитектура приложения предполагает 3 слоя: рест, сервис, репозиторий (Java Spring)
Мне поступила задача, которая потенциально должна взаимодействовать со всеми этими слоями.
Нужно ли прописывать мини задачи в формате:
Класс1 - добавить такой-то метод
Класс2 - добавить другой метод
Т.е. декомпозиция подразумевает ознакомление с кодом перед задачей
Правильно ли это?
Правильно не использовать спринг
Пример абстрактный.
возможно тут проблема в том, что никто не знает Максима Дорофеева
у него есть своя немаленькая аудитория =) 50-100к точно
Сам на чем пишешь? JavaFx?
на ms basic 2.0
на Scala 3 пишет наш коллега
Ага, увидел. Но это был больше наброс :)
По классам не нужно. Это бред. Максимум бизнес постановка и нефункциональные(технические) требования если они есть. Даже API лучше не описывать в постановке, так как разработчик это может сделать самостоятельно в нужной нотации лучше почти любого системного аналитика.
А если мы рассматриваем вариант со стороны разработчика? Условно, есть уже общая постановка задачи. И разработчик приступает к работе. С его стороны нормально декомпозировать от общего к частному (по классам)?
он может это сделать в коде, постановка уровня “добавить такой то метод в такой то класс” как и отрисовка схем такого уровня вручную примерно равно написанию этого метода, т е тот кто будет писать такую постановку фактически решит задачу и просто даст кодеру закодить остатки
Обсуждают сегодня