Улучшение действительно плохих систем

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

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

На самом деле система настолько разбита, что не делает того, что ей нужно делать.

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

Хуже того, есть некоторые проблемы, которые обходятся не в самой системе, а в голове людей. Например, система не может представлять более четырех связанных сообщений в одной группе сообщений. Для некоторых служб потребуется пять сообщений, сгруппированных вместе. Учетный отдел знает об этом ограничении, и каждый раз, когда они подсчитывают сообщения для этих служб, они подсчитывают группы сообщений и умножают их на 5/4, чтобы получить правильное количество сообщений. Существует абсолютно никакой документации об этих отклонениях, и никто не знает, сколько таких вещей присутствует в системе сейчас.

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

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

Некоторые технические детали: система написана на Java и PHP, но я не думаю, что это действительно важно. За ним стоят две базы данных: Oracle и PostgreSQL. Помимо недостатков, упомянутых выше, сам код также пахнет, он действительно плохо написан и задокументирован.

Дополнительная информация:

Проблема счетчика не является проблемой синхронизации. Операторы counter ++ добавляются в некоторые модули и не добавляются в некоторые другие модули. Быстрое и грязное исправление заключается в том, чтобы добавить их там, где они отсутствуют. Долгое решение - сделать его своего рода аспектом для модулей, которые в нем нуждаются, что делает невозможным его забыть позже. У меня нет проблем с исправлением таких вещей, но если я сделаю это изменение, я сломаю более 10 других модулей.

Update:

Я принял ответ Грега D. Даже если мне больше понравится Адам Беллаир, это не поможет мне узнать, что было бы идеально знать. Спасибо всем за ответы.

Ответы

Ответ 1

  • Выключите огонь. Если есть какие-либо проблемы с критическим приоритетом, независимо от того, что они есть, вы должны сначала обработать их. Взломайте его, если нужно, с вонючей кодовой базой. Вы знаете, что вы улучшите его. Это ваш метод продаж, предназначенный для тех, кому вы сообщаете.
  • Выберите некоторые низко висящие фрукты. Я предполагаю, что вы относительно новичок в этом конкретном программном обеспечении и что вам было поручено справиться с этим. Найдите некоторые, по-видимому, легкие проблемы в связанной подсистеме кода, которые не должны занимать больше одного-двух дней, чтобы решить их, и исправить их. Это может включать рефакторинг, или это может быть не так. Целью является ознакомление с системой и стилем оригинального автора. Возможно, вам не повезет (один из двух некомпетентных людей, которые работали над моей системой, всегда оставлял свои комментарии с четырьмя знаками препинания вместо одного, что позволяло отличить, кто написал конкретный сегмент кода.), но вы будете развивать понимание недостатков автора, чтобы вы знали, на что обратить внимание. Обширная, плотная связь с глобальным состоянием и плохое понимание языковых инструментов, например.
  • Задайте большую цель. Если ваш опыт параллелен моей, вы все чаще обнаружите себя в определенном фрагменте кода спагетти, когда выполняете предыдущий шаг. Это первый узел, который вам нужно распутать. Благодаря опыту, вы поняли компонент и знания о том, что первоначальный автор, вероятно, сделал не так (и, следовательно, что вам нужно соблюдать), вы можете начать представление о лучшей модели для этого подмножества системы. Не беспокойтесь, если вам все еще нужно поддерживать некоторые грязные интерфейсы для поддержания функциональности, просто сделайте это шаг за шагом.

Скорее, промойте, повторите!:)

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

Решение конкретных вопросов, которые вы упомянули:

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

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

Ответ 2

Что вас спрашивают прямо сейчас? Вас попросят реализовать функциональность или исправить ошибки? Знают ли они, что они хотят от вас?

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

Вам нужно реорганизовать, в конце концов. Об этом нет. Если вы можете найти способ рефакторинга, который будет виден вашим конечным пользователям, , который был бы идеальным, даже если он занимает 6-9 месяцев или год вместо "несколько месяцев". Но если вы не можете, то у вас есть выбор:

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

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

И наоборот, если ваши усилия по "исправлению вещей" на самом деле нарушают другие вещи, будут ли они понимать, какое чудовище вам нужно решать в одиночку?

Здесь нет легких ответов, извините. Вы должны оценивать свою уникальную индивидуальную ситуацию.

Ответ 4

Вы открываете каталог, содержащий эту систему, с проводником Windows. Затем нажмите Ctrl-A, а затем Shift-Delete. Это звучит как улучшение вашего дела.

Серьезно, хотя: этот счетчик звучит так, будто у него проблемы с точки зрения безопасности. Я бы поставил блокировку вокруг растущих функций.

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

Удачи, и пусть источник будет с вами.

Ответ 5

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

Затем тестирование, тестирование, тестирование. Поскольку нет каких-либо модульных тестов, возможно, просто используйте старые старомодные голосовые модули (люди)? Или напишите свои собственные тесты, когда идете.

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

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

У Джоэля есть несколько статей по перезаписи/рефакторингу:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://www.joelonsoftware.com/articles/fog0000000348.html

Ответ 6

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

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

Я не уверен, какова цель вашей задачи, но я настоятельно рекомендую вам как можно меньше коснуться кода. Делайте только то, что вам нужно.

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Удачи!

Ответ 9

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

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