как обращаться с кодом, который считается опасным для изменения, но стабильным?[закрыто]

Question

Каков наилучший способ справиться с большой командой, у которой есть доступ к стабильному, но не очень красивому коду, в который легко внести ошибки?

Я ищу что-то вроде SVN, блокирующего файл (ы).

Answer 1

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

Answer 2

Скажи им, чтобы оставили это в покое.

Это работает, в чем выгода от его изменения, кроме приукрашивания (а потенциальная стоимость высока), поэтому вам просто нужно объяснить анализ затрат и выгод.

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

Answer 3

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

Answer 4

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

2. Возьмите экземпляр классической книги Мартина Фаулера Рефакторинг и прочти это.Обратите особое внимание на концепцию запахов кода.Это укажет вам на конкретные рефакторинги, которые помогут в вашей ситуации.

3. Приобретите хорошую IDE, в которую встроена поддержка рефакторинга.IDE не будут поддерживать все рефакторинги, описанные в книге, но многие из них будут иметь определенное их количество. Затмение и NetBeans - сетевые приложения в мире Java они бесплатны и хорошо поддерживают рефакторинг.

4. Рассмотрим сервер непрерывной интеграции, например Хадсон чтобы отследить, не проваливаются ли ваши тесты.

Answer 5

Да, заблокируйте его до тех пор, пока не сможете написать для него более удобную замену.

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Смотрите на Управление версиями с помощью Subversion книга о Реализация перехватов репозитория.Дистрибутив Subversion должен включать несколько хороших примеров того, как сделать именно это.

Answer 9

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

Answer 10

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

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

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

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