Как бы вы поддерживали устаревшие приложения [закрыто]

Question

Как бы вы поддерживали устаревшие приложения, которые:

1. Не имеет модульных тестов, имеет большие методы

2. с большим количеством дублированной логики есть

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

???

Answer 1

Тебе нужна эта книга Эффективная работа с устаревшим кодом Майкла К.Перья.

Answer 2

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

Answer 3

Две вещи.

1. Пишите модульные тесты, когда у вас есть такая возможность.
2. Как только у вас будет достаточно модульных тестов, чтобы быть уверенным, приступайте к рефакторингу.

Скорость, с которой вы выполняете это, может быть медленной....Как правило, вы должны "просто поддерживать это", а не исправлять.

Однако на этапе "обучения его обслуживанию" вы можете написать множество модульных тестов.

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

Это гибкий подход, применяемый к устаревшему.

Answer 4

Я видел, работал и продолжаю работать в кодовой базе, которая удовлетворяет всем условиям, упомянутым в вопросе :-)

Подход, применяемый при поддержании этой кодовой базы, заключается в следующем ЧТОБЫ НИЧЕГО НЕ СЛОМАТЬ.FWIW, код работает и конечные пользователи довольны.Никто не собирается слушать крики разработчика о дублировании кода, жестко закодированных строках и т.д.Мы просто крадем немного времени, чтобы исправить все, что возможно, и проявляем максимальную осторожность, чтобы не вводить новые ошибки..

Answer 5

Я думаю, что я бы создал небольшой набор актуальной информации:Какое действие вызывает, какие функции и т.д.

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

• Это может оказаться огромной задачей, когда вы осознаете, во скольких местах эта логика вызывается и
• Две функции, которые кажутся похожими, могут иметь крошечную разницу, т. е.a - вместо a +

Я думаю, что самое большое желание сопротивляться - это "Просто перестроить всю эту чертову штуку!" и сначала получить общее представление о системе, чтобы развенчать чудовище.

Answer 6

судо рм -рф /

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

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

Answer 7

Я в принципе согласен со всем, что сказал Пол Си.Я не сторонник TDD, но всякий раз, когда вы прикасаетесь к устаревшей кодовой базе - особенно к той, с которой вы не очень хорошо знакомы, - вам нужно иметь надежный способ повторного тестирования и убедиться, что вы следовали Гиппократу:Во-первых, не причиняй вреда.Тестирование, в частности, хорошие модульные и регрессионные тесты, - это, пожалуй, единственный способ добиться успеха.

Я настоятельно рекомендую приобрести копию Обращение вспять:Секреты обратного инжиниринга программного обеспечения если это кодовая база, с которой вы не знакомы.Хотя эта книга затрагивает большие глубины, которые выходят за рамки ваших текущих потребностей (и моих, если уж на то пошло), она многому научила меня тому, как безопасно и разумно работать с чужим кодом.