Ситуация наверное стандартная — дали проект в который нужно добавить простую, на первый взгляд фичу.
Дел на неделю.
Ну начал копать.
Оказалось, что для того чтобы добавить эту фичу нужно довольно сильно изменить архитектуру.
На первый взгляд изменения архитектуры понятные и прозрачные и ничто нигде не сломается.
Щаззз.
После смены архитектуры полезли баги.
Начал фиксить.
Довел систему до первоначального состояния, но архитектура уже была готова принимать новую фичу.
Начал добавлять новую фичу — полезли баги в тех частях, где вроди бы и не должгы были вылезать.
С горем пополам таки фичу добавил.
Но теперь боюсь что малейшее изменение опять стрельнет где-то в дальней части системы.
Решил сделать то, что нужно было сделать с самого начала — начать с исследования.
Нашел и задокументировал все состояния системы, как она может переходить из одного в другое, что при этом нужно сделать и что поменяется и тд и тп.
Записал это все просто на бумаге.
Но хотелось бы как-то разложить такую информацию по полочкам в более удобном для анализа виде.
Кто чем пользуется для такого рода задач?

Здравствуйте, some.money.2010, Вы писали:


SM2>Кто чем пользуется для такого рода задач?

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

Здравствуйте, some.money.2010, Вы писали:

SM2>Оказалось, что для того чтобы добавить эту фичу нужно довольно сильно изменить архитектуру.
Вот так вот прямо изменить архитектуру? Что же это за фича и какая у вас архитектура?
Может не архитектуру менять а подправить системный дизайн?

Кто чем пользуется для такого рода задач?

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