Legacy code?

[singalen]

Коллеги,

У меня к вам несколько вопросов. Я тут хочу приготовить тренинг, и нагло воспользоваться вашими идеями.

1. Какие приёмы и инструменты вы используете при работе с оным?
Отдельно - приёмы исследования того, что же, собственно, оно делает. Если можно, более-менее конкретно.
2. Как вы определяете оный код? По дублированию, непонятным именам, другим фаулеровским запахам, интуитивно?
3. Кто может поделиться хорошими, хорошо замудрёнными примерами легаси-кода? С зависимостями, багами, непонятными названиями и те пе.
Или из опенсорсных продуктов, или, если можно, проприетарных. Умеренно обфусцированный подойдёт.
Интересуют, наверное, куски размером от одного до пары десятков классов - чтобы можно было разобраться за несколько часов. Публиковать никуда не буду, нарисую аналогичные свои :D

И сам поделюсь книжкой: "Working Effectively with Legacy Code", Michael C. Feathers.
Книжка старая, вышла в 2004, до распространения TDD и рефакторингов. Слово mock там уже есть, и паттерн expect {} есть, а play {} ещё нет %) Ну и никаких библиотек типа Rhino ещё не упоминается.

В основном состоит из рецептов - какие рефакторинги применять в каком случае, c особым акцентом на том, как разбивать зависимости. И жёсткого требования на всё, что меняете, писать тесты.
Формализована не очень чётко, но почитать ради вдохновления и ради примеров стоит.

Лично я ожидал от книги ещё и инструментов исследования и отладки. Для меня легаси - в первую очередь то, что надо исследовать: понять, что и как оно делает, а у же потом чего-то менять.

Мои любимые инстументы - полнотекстовый поиск, дерево вызовов (там, где оно доступно), и "интрузивное исследование" (термин мой) - особым образом поломать существующий код и посмотреть, как он себя поведёт. Тут я ещё только собираюсь классифицировать свои собственные паттерны :D
Ну и юнит тесты как инструмент не/интрузивного исследования - тоже рулят, потому что очень сильно сокращают цикл "написал-запустил-проверил" - но это вы и сами знаете.

Comments

[singalen]

+1 к п.2. Сначала чистый рефакторинг, изменения отдельно.
Их потом, оказывается, по отдельности и ревьюить намного легче.
На что пишешь тесты? Только ли на новый/изменённый функционал, или и на объемлющий метод?

[singalen]

Всё организуем :)
Книжку и так дочитаю, в пень перводы. Она короткая.

[klizardin.livejournal.com]

ух ты, какой юзерпик)

[klizardin.livejournal.com]

стараюсь прописывать тесты. из-за полного отсутствия оных, тесты пишутся не только на текущие изменения, но и на ближайший функционал.

большей частью тесты помогают понять код и его особенности.