Как правильно организовать структуру постоянно изменяющегося проекта?
Есть у нас веб-приложение которым пользуется пару сотен пользователей одной закрытой организации. Приложение громоздкое, с обширнейшим количеством функционала, часть которого мы сами уже не помним.
Схема работа приложения сильно завязана на законодательство, которое из года в год меняется.
Выходит вот что: написали какой-то фундаментальный класс, который использует другой класс и т.п. и всё это объединено в модуль. А через несколько месяцев говорят: логика работы поменялась, срочно переделать!
И приходится ломать всю структуру, зачастую костылями.
Вопрос: есть ли какие-то методологии разработки часто изменяющегося кода? Чтобы и нам просто было, и заказчику "срочно", как это всегда у него бывает
Забавно. Перечитал этот свой давнишний вопрос. Странно, что никто не упомянул из отвечающих про agile-разработку, SOLID, и книги и статьи по разработке от Robert Cecil Martin.
Вообще для этого все эти хозяева продукта и архитекторы и существуют, не?
Надо, блин, документацию держать в порядке, разрабатывать системно, а не "с кандачка". Подход менять надо, в принципе
Для энтерпрайза с обширной бизнес-логикой подойдет DDD. Перевести за раз уже существующий проект с огромным функционалом и костылями будет нереально. Можно попробовать небольшими итерациями. Уровень команды тоже должен соответствовать, поскольку при строительстве такой архитектуры точно будет использоваться добрая половина паттернов описанная в книге PoEAA.
Средний
