Как обновить странные Приложения, не совершая те же ошибки?

Question

Мой новый проект - обновить программное обеспечение, которое клиент использовал годами. Как мы все знаем ... вещи росли за эти годы.

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

Это другая ошибка, которую я сделал, но очень раздражает.

Как вы, ребята, предотвращаете такие ошибки? Вы отказываетесь смотреть на старое приложение?

Answer 1

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

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

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

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

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

Несколько хороших ресурсов:

http://martinfowler.com/bliki/StranglerApplication.html

Эффективная работа с устаревшим кодом

Я также нашел его в StackOverflow:

Стратегия масштабного рефакторинга

Answer 2

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

Answer 3

Этот вопрос звучит так, как будто вы модифицируете существующий код, «убирая его», а не переписывая его. Этот процесс иногда называют «Рефакторинг». Существует замечательная книга Мартина Фаулера по рефакторингу под названием «Рефакторинг». Он начинает с конкретных примеров рефакторинга реального кода и связывает будущие главы о конкретных методах, которые он использует, прямо рядом с кодом.

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

Answer 4

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

Answer 5

Модульное тестирование. Но если у вас не было модульных тестов, они вам не помогут.