Каковы ключевые моменты эффективной работы с устаревшим кодом? [закрыто]

Я видел книгу « Эффективная работа с устаревшим кодом», рекомендованную несколько раз. Каковы ключевые моменты этой книги?

Есть ли что-то большее в работе с унаследованным кодом, чем добавление модульных / интеграционных тестов, а затем рефакторинг?

Основная проблема с унаследованным кодом состоит в том, что у него нет тестов. Так что вам нужно добавить немного (а потом еще ...).

Это само по себе потребует много работы, как отметил @mattnz. Но особая проблема унаследованного кода заключается в том, что он никогда не был разработан для тестирования . Поэтому, как правило, это огромный запутанный беспорядок в коде спагетти, в котором очень трудно или даже невозможно выделить мелкие детали для тестирования модулем. Поэтому перед модульным тестированием вам необходимо провести рефакторинг кода, чтобы сделать его более тестируемым.

Однако, чтобы безопасно выполнить рефакторинг, вы должны пройти модульные тесты, чтобы убедиться, что вы ничего не сломали со своими изменениями ... Это уловка 22 унаследованного кода.

Книга научит вас, как вырваться из этого улова, сделав абсолютно минимальные, самые безопасные изменения в коде, чтобы включить первые модульные тесты. Они не предназначены для того, чтобы сделать дизайн лучше, только для того, чтобы включить модульные тесты. На самом деле, иногда они делают дизайн более уродливым или более сложным. Тем не менее, они позволяют вам писать тесты - и как только у вас появятся модульные тесты, вы сможете улучшить дизайн.

Есть много хитростей, чтобы сделать код тестируемым - некоторые очевидны, а некоторые нет. Есть методы, о которых я бы никогда не подумал, не читая книгу. Но что еще более важно, это то, что Feathers объясняет, что именно делает код тестируемым. Вам необходимо сократить зависимости и ввести барьеры в ваш код, но по двум причинам:

• восприятие - для проверки и проверки результатов выполнения фрагмента кода, и
• разделение - для того, чтобы в первую очередь поместить конкретный кусок кода в тестовый комплект.

Безопасное сокращение зависимостей может быть сложным. Знакомство с интерфейсами, макетами и Dependency Injection - это чистая и приятная цель, просто не обязательно безопасная на данном этапе. Поэтому иногда нам приходится прибегать к подклассу тестируемого класса, чтобы переопределить некоторый метод, который обычно, например, запускает прямой запрос к БД. В других случаях нам может даже понадобиться заменить класс зависимости / jar на поддельный в тестовой среде ...

Для меня самая важная концепция, предложенная Feathers, это швы . Шов - это место в коде, где вы можете изменить поведение вашей программы без изменения самого кода . Встраивание швов в ваш код позволяет отделить тестируемый фрагмент кода, но также позволяет вам почувствовать поведение тестируемого кода, даже если это трудно или невозможно сделать напрямую (например, потому что вызов вносит изменения в другой объект или подсистему). , чье состояние невозможно запросить непосредственно из метода теста).

Это знание позволяет вам увидеть семена тестируемости в самой отвратительной куче кода и найти минимальные, наименее разрушительные, самые безопасные изменения, чтобы туда попасть. Другими словами, чтобы избежать «очевидных» рефакторингов, которые могут привести к поломке кода без вашего ведома, потому что у вас еще нет модульных тестов, чтобы обнаружить это.

Быстрые способы получить ключевые моменты эффективной работы с устаревшим кодом

• Прочитайте 12-страничный PDF-файл Майкла Фезерса , написанный за 2 года до книги.
• Посмотрите на презентацию Майкла Фезерса: 68 слайдов
• Послушайте интервью подкаста с Майклом Фезерсом. Например, этот 30-минутный эпизод Hanselminutes .

Я работаю над кодовой базой, состоящей из миллионов строк кода, некоторые из которых относятся к 1980-м годам. Это просто программное обеспечение, так что это всего лишь вопрос написания нескольких модульных тестов, так что вы можете пойти и просто реорганизовать его, и сделать его намного лучше.

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

Как вы думаете, сколько времени потребуется, чтобы написать модульное тестирование, чтобы потратить один час усилий на разработку? Для обсуждения, скажем, еще час.

Сколько времени потрачено на эту 20-летнюю унаследованную систему с миллионными линиями? Допустим, 20 разработчиков по 20 лет умножили на 2000 часов в год (они работали довольно усердно). Давайте теперь выберем число - у вас есть новые компьютеры и новые инструменты, и вы намного умнее, чем парни, которые изначально написали этот кусок $% ^^ - допустим, вы стоите 10 из них. У тебя есть 40 человеко-лет, ну, у тебя ...?

Таким образом, ответ на ваш вопрос есть гораздо больше. Например, эта процедура, которая состоит из 1000 строк (у меня есть несколько из которых более 5000), она слишком сложна и является частью спагетти. Потребуется всего лишь (еще одно четырехбуквенное слово) несколько дней, чтобы переформулировать его в несколько подпрограмм по 100 строк и еще несколько помощников по 20 строк, верно? НЕПРАВИЛЬНО. В этих 1000 строках скрыто 100 исправлений ошибок, каждая из которых является недокументированным требованием пользователя или неясным крайним случаем. Это 1000 строк, потому что оригинальная процедура из 100 строк не справилась с этой задачей.

Вы должны работать с настроением « если оно не сломано, не исправляйте его ». Когда он сломан, вам нужно быть очень осторожным, когда вы исправляете его - так как вы делаете это лучше, чтобы случайно не изменить что-то другое. Обратите внимание, что «сломался» может включать в себя код, который не поддерживается, но работает правильно, это зависит от системы и ее использования. Спросите «что произойдет, если я все испорчу и усугублю», потому что однажды вы это сделаете, и вам придется рассказать боссу, почему вы решили это сделать.

Эти системы всегда можно сделать лучше. У вас будет бюджет для работы, сроки, что угодно. Если нет - иди и сделай один. Прекратите делать это лучше, когда закончатся деньги / время. Добавьте функцию, дайте себе время сделать ее немного лучше. Исправьте ошибку - снова потратьте немного дополнительного времени и сделайте его лучше. Никогда не доставляйте это хуже, чем было, когда вы начинали.

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

1. Устаревший код - это любой код, который не имеет тестового покрытия.
2. Всякий раз, когда вам нужно изменить устаревший код, вы должны убедиться, что он имеет покрытие.

Как отмечали другие респонденты, попытка упреждающего обновления существующего унаследованного кода - это дурацкое дело . Вместо этого, всякий раз, когда вам нужно внести изменения в устаревший код (для новой функции или исправления ошибки), найдите время, чтобы удалить его устаревший статус.

В скорлупе ореха это правда - добавление тестов и рефакторинг - вот что все это значит.

Но книга дает вам много разных техник для работы с кодом, который очень сложно протестировать и безопасно выполнить рефакторинг.