Legacy code?
18/10/10 16:54У меня к вам несколько вопросов. Я тут хочу приготовить тренинг, и нагло воспользоваться вашими идеями.
1. Какие приёмы и инструменты вы используете при работе с оным?
Отдельно - приёмы исследования того, что же, собственно, оно делает. Если можно, более-менее конкретно.
2. Как вы определяете оный код? По дублированию, непонятным именам, другим фаулеровским запахам, интуитивно?
3. Кто может поделиться хорошими, хорошо замудрёнными примерами легаси-кода? С зависимостями, багами, непонятными названиями и те пе.
Или из опенсорсных продуктов, или, если можно, проприетарных. Умеренно обфусцированный подойдёт.
Интересуют, наверное, куски размером от одного до пары десятков классов - чтобы можно было разобраться за несколько часов. Публиковать никуда не буду, нарисую аналогичные свои :D
И сам поделюсь книжкой: "Working Effectively with Legacy Code", Michael C. Feathers.
Книжка старая, вышла в 2004, до распространения TDD и рефакторингов. Слово mock там уже есть, и паттерн expect {} есть, а play {} ещё нет %) Ну и никаких библиотек типа Rhino ещё не упоминается.
В основном состоит из рецептов - какие рефакторинги применять в каком случае, c особым акцентом на том, как разбивать зависимости. И жёсткого требования на всё, что меняете, писать тесты.
Формализована не очень чётко, но почитать ради вдохновления и ради примеров стоит.
Лично я ожидал от книги ещё и инструментов исследования и отладки. Для меня легаси - в первую очередь то, что надо исследовать: понять, что и как оно делает, а у же потом чего-то менять.
Мои любимые инстументы - полнотекстовый поиск, дерево вызовов (там, где оно доступно), и "интрузивное исследование" (термин мой) - особым образом поломать существующий код и посмотреть, как он себя поведёт. Тут я ещё только собираюсь классифицировать свои собственные паттерны :D
Ну и юнит тесты как инструмент не/интрузивного исследования - тоже рулят, потому что очень сильно сокращают цикл "написал-запустил-проверил" - но это вы и сами знаете.