Улучшение действительно плохих систем
https://stackoverflow.com/questions/192464
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Как бы вы начали улучшать действительно плохую систему?
Позвольте мне объяснить, что я имею в виду, прежде чем вы порекомендуете создавать модульные тесты и рефакторинг.Я мог бы использовать эти методы, но в данном случае это было бы бессмысленно.
На самом деле система настолько сломана, что не делает того, что должна.
Например, система должна подсчитать, сколько сообщений она отправляет.В основном это работает, но в некоторых случаях «забывает» увеличить значение счетчика сообщений.Проблема в том, что на этом счетчике основано так много других модулей со своими собственными обходными путями, что, если я исправлю счетчик, система в целом станет хуже, чем сейчас.Решением могло бы быть модификация всех модулей и удаление собственных исправлений, но при наличии 150+ модулей это потребовало бы такой тщательной координации, что я не могу себе этого позволить.
Хуже того, есть некоторые проблемы, обходные пути которых есть не в самой системе, а в головах людей.Например, система не может представлять более четырех связанных сообщений в одной группе сообщений.Некоторым службам потребуется сгруппировать пять сообщений.Бухгалтерия знает об этом ограничении и каждый раз, когда они подсчитывают сообщения для этих служб, они подсчитывают группы сообщений и умножают их на 5/4, чтобы получить правильное количество сообщений.Об этих отклонениях совершенно нет документации и никто не знает, сколько таких вещей сейчас присутствует в системе.
Итак, как бы вы начали работать над улучшением этой системы?Какой стратегии вы бы следовали?
Несколько дополнительных вещей:Я работаю над этим как армия из одного человека, поэтому нанимать достаточное количество людей и перепроектировать/реорганизовать систему — неприемлемый ответ.И через несколько недель или месяцев я действительно должен продемонстрировать некоторый видимый прогресс, так что проводить рефакторинг самому через пару лет тоже не вариант.
Некоторые технические подробности:система написана на Java и PHP, но я не думаю, что это имеет большое значение.За ним стоят две базы данных: Oracle и PostgreSQL.Помимо упомянутых выше недостатков, сам код тоже пахнет, он действительно плохо написан и документирован.
Дополнительная информация:
Проблема счетчика не является проблемой синхронизации.Операторы counter++ добавляются в некоторые модули и не добавляются в некоторые другие модули.Быстрое и грязное решение — добавить их туда, где они отсутствуют.Долгосрочное решение состоит в том, чтобы сделать это своего рода аспектом для модулей, которые в нем нуждаются, чтобы невозможно было забыть об этом позже.У меня нет проблем с исправлением подобных вещей, но если бы я внес это изменение, я бы сломал еще 10 модулей.
Обновлять:
Я принял ответ Грега Д.Даже если мне больше нравится творчество Адама Беллера, мне не поможет знание того, что было бы идеально знать.Спасибо всем за ответы.
Решение
- Потушить пожары.Если есть какие-либо вопросы критического приоритета, какими бы они ни были, вам придется их решить в первую очередь.Взломайте его, если нужно, с вонючей кодовой базой это нормально.Вы знаете, что улучшите его в будущем.Это ваша техника продаж, ориентированная на тех, кому вы подчиняетесь.
- Возьмите немного низко висящих фруктов. Я предполагаю, что вы относительно новичок в этом конкретном программном обеспечении и что вам поручили разобраться с ним.Найдите в соответствующей подсистеме кода несколько, казалось бы, простых проблем, на решение каждой из которых не должно уйти более одного-двух дней, и исправьте их.Это может включать в себя рефакторинг, а может и нет.Цель — ознакомиться с системой и стилем оригинального автора.Возможно, вам не сильно повезет (один из двух некомпетентных людей, работавших над моей системой до меня, всегда добавлял в свои комментарии четыре знака препинания вместо одного, что позволяло очень легко отличить того, кто написал тот или иной фрагмент кода). но вы поймете слабые стороны автора и будете знать, на что обращать внимание.Например, обширная и тесная связь с глобальным состоянием или плохое понимание языковых инструментов.
- Поставьте большую цель. Если ваш опыт аналогичен моему, то по мере выполнения предыдущего шага вы будете все чаще и чаще обнаруживать себя в определенном фрагменте спагетти-кода.Это первый узел, который вам нужно распутать.Благодаря приобретенному вами опыту понимания компонента и знаниям о том, что первоначальный автор, вероятно, сделал неправильно (и, следовательно, на что вам следует обратить внимание), вы можете начать придумывать лучшую модель для этого подмножества системы.Не волнуйтесь, если вам все еще придется поддерживать некоторые запутанные интерфейсы для поддержания функциональности, просто делайте это шаг за шагом.
Вспеньте, промойте, повторите!:)
Со временем рассмотрите возможность добавления модульных тестов для вашей новой модели на один уровень ниже интерфейсов с остальной частью системы.Не вписывайте плохие интерфейсы в код с помощью тестов, которые их используют, вы будете менять их в будущей итерации.
Решение конкретных проблем, которые вы упомянули:
Когда вы сталкиваетесь с ситуацией, которую пользователи решают вручную, поговорить с пользователями о его изменении.Прежде чем тратить на это время, убедитесь, что они примут изменение, если вы его предоставите.Если они не хотят перемен, ваша задача — поддерживать испорченное поведение.
Когда вы сталкиваетесь с компонентом с ошибкой, который исправили несколько других компонентов, я поддерживаю технику параллельных компонентов.Создайте счетчик, который будет работать так же, как существующий должен работа.Обеспечьте аналогичный (или, если возможно, идентичный) интерфейс и вставьте новый компонент в базу кода.Когда вы прикасаетесь к внешним компонентам, которые работают рядом со сломанным, попробуйте заменить старый компонент новым.Подобные интерфейсы облегчают портирование кода, и старый компонент все еще доступен, если новый выйдет из строя.Не удаляйте старый компонент, пока не сможете.
Другие советы
Что от вас сейчас спрашивают?Вас просят реализовать функциональность или исправить ошибки?Они вообще знают, чего от вас хотят?
Если у вас нет рабочей силы, времени или ресурсов, чтобы «починить» систему в целом, то все, что вы можете сделать, это слить воду.Вы говорите, что сможете добиться некоторого «видимого прогресса» через несколько месяцев.Что ж, поскольку система настолько плоха, как вы описали, вы можете сделать ее еще хуже.Под давлением необходимости сделать что-то заметное вы просто добавите код и сделаете систему еще более запутанной.
В конце концов вам придется провести рефакторинг.Обойти это невозможно.Если вы можете найти способ рефакторинга, который будет виден вашим конечным пользователям, это было бы идеально, даже если это займет 6-9 месяцев или год вместо «нескольких месяцев». Но если вы не можете, то у вас есть выбор:
- Выполните рефакторинг и рискуете, что вас сочтут «ничего не достигшим», несмотря на ваши усилия.
- Не проводите рефакторинг, достигайте «видимых» целей и делайте систему более запутанной и трудной для рефакторинга в один прекрасный день.(Может быть, после того, как вы найдете лучшую работу и будете надеяться, что следующий разработчик никогда не узнает, где вы живете.)
Какой из них наиболее выгоден лично для вас, зависит от культуры вашей компании.Решат ли они однажды нанять больше разработчиков или полностью заменить эту систему каким-то другим продуктом?
И наоборот, если ваши усилия «исправить что-то» на самом деле ломают другие вещи, поймут ли они, с каким чудовищем вас просят справиться в одиночку?
Здесь нет простых ответов, извините.Вы должны оценивать, исходя из вашей уникальной, индивидуальной ситуации.
Это целая книга, в которой в основном рассказывается о модульном тестировании и рефакторинге, но с более практическими советами о том, как это сделать.
http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg
http://www.amazon.com/Working-Effectivity-Legacy-Robert-Martin/dp/0131177052
Вы открываете каталог, содержащий эту систему, с помощью проводника Windows.Затем нажмите Ctrl-A, а затем Shift-Delete.В вашем случае это звучит как улучшение.
Если серьезно:этот счетчик звучит так, будто у него проблемы с потокобезопасностью.Я бы заблокировал возрастающие функции.
Что касается остальной части системы, вы не можете сделать невозможное, поэтому постарайтесь сделать возможное.Вам нужно атаковать вашу систему с двух фронтов.Сначала позаботьтесь о наиболее очевидных проблемах, чтобы вы могли продемонстрировать прогресс.В то же время вам следует разобраться с более инфраструктурными проблемами, чтобы у вас был шанс когда-нибудь действительно исправить эту проблему.
Удачи, и да пребудет с вами источник.
Выберите одну область, рефакторинг которой будет средней сложности.Создайте скелет исходного кода, используя только сигнатуры существующих методов;возможно, даже использовать интерфейс.Затем начните взламывать.Вы даже можете указывать «новые» методы на старые, пока не доберетесь до них.
Потом тестирование, тестирование, тестирование.Поскольку модульных тестов нет, может быть, просто использовать старые добрые модульные тесты, активируемые голосом (люди)?Или пишите свои собственные тесты по ходу дела.
Документируйте свой прогресс в каком-нибудь хранилище, включая разочарования и вопросы, чтобы следующий бедняга, который получит этот проект, не оказался там, где вы находитесь :).
Выполнив первую часть, переходите к следующей.Ключевым моментом является постепенное развитие, поэтому не следует начинать сначала с самого сложного;будет слишком легко деморализоваться.
У Джоэла есть пара статей о переписывании/рефакторинге:
Я работаю с устаревшей системой с теми же характеристиками уже почти три года, и мне не известны какие-либо ярлыки.
Что меня больше всего беспокоит в нашей устаревшей системе, так это то, что мне не разрешено исправлять некоторые ошибки, поскольку многие другие функции могут выйти из строя, если я их исправлю.Это требует уродливых обходных путей или создания новых версий старых функций.Вызовы старых функций затем можно заменять новыми по одному (во время тестирования).
Я не уверен, какова цель вашей задачи, но настоятельно советую вам как можно меньше трогать код.Делайте только то, что вам нужно.
Возможно, вы захотите получить как можно больше информации, опрашивая людей.Это огромная задача, так как не знаешь, какие вопросы задавать, и люди забудут множество деталей.
Кроме этого:убедитесь, что вам платят и получают достаточную моральную поддержку.Там будет плач и скрежет зубов...
Что ж, вам нужно с чего-то начинать, и похоже, что есть ошибки, которые нужно исправить.Я работал над этими ошибками, проводя быстрый рефакторинг и попутно писал любые модульные тесты.Я бы также использовал такой инструмент, как ИсточникМонитор чтобы определить некоторые из наиболее «сложных» частей кода в системе и посмотреть, смогу ли я каким-либо образом упростить их дизайн.В конечном счете, вам просто нужно признать, что это будет медленный процесс, и сделать небольшие шаги к улучшению системы.
Я бы постарался выбрать часть системы, которую можно было бы достаточно быстро извлечь и переписать изолированно.Даже если это не так уж и много, вы можете довольно быстро продемонстрировать прогресс, и у вас не возникнет проблем с прямым взаимодействием с устаревшим кодом.
Будем надеяться, что если вы сможете выбрать несколько таких задач, они увидят ваш видимый прогресс, и вы сможете выдвинуть аргумент в пользу найма большего количества людей для переписывания более крупных модулей.Когда части системы зависят от неправильного поведения, у вас нет другого выбора, кроме как отделиться, прежде чем что-либо исправлять.
Будем надеяться, что вы сможете постепенно создать команду, способную все переписать.
Все это должно идти рука об руку с достойным обучением, иначе старые привычки людей сохранятся, и ваша работа будет обвинена, когда что-то пойдет не так, как ожидалось.
Удачи!
Устарейте все, что существует на данный момент и имеет проблемы, и напишите новые, которые работают правильно.Задокументируйте как можно больше о том, что изменится, и разместите повсюду большие красные мигающие знаки, указывающие на эту документацию.
Поступая таким образом, вы можете сохранить существующие ошибки (те, которые компенсируются где-то еще), не замедляя свой прогресс на пути к созданию действительно работающей системы.
