Улучшение действительно плохих систем
Как бы вы начали улучшать действительно плохую систему?
Позвольте мне объяснить, что я имею в виду, прежде чем вы порекомендуете создавать модульные тесты и проводить рефакторинг. Я мог бы использовать эти методы, но в данном случае это было бы бессмысленно.
На самом деле система настолько сломана, что не делает то, что ей нужно.
Например, система должна подсчитать, сколько сообщений она отправляет. В основном работает, но в некоторых случаях «забывает» увеличить значение счетчика сообщений. Проблема в том, что на этом счетчике построено так много других модулей со своими собственными обходными путями, что, если я исправлю счетчик, система в целом станет хуже, чем сейчас. Решением может быть изменение всех модулей и удаление их собственных исправлений, но с более чем 150 модулями, которые потребуют такой большой координации, что я не могу себе этого позволить.
Хуже того, есть некоторые проблемы, решения которых есть не в самой системе, а в головах людей. Например, система не может представлять более четырех связанных сообщений в одной группе сообщений. Для некоторых сервисов потребуется пять сообщений, сгруппированных вместе. Бухгалтерия знает об этом ограничении, и каждый раз, когда они подсчитывают сообщения для этих служб, они подсчитывают группы сообщений и умножают их на 5/4, чтобы получить правильное количество сообщений. Об этих отклонениях нет абсолютно никакой документации, и никто не знает, сколько таких вещей сейчас присутствует в системе.
Итак, как бы вы начали работать над улучшением этой системы? Какой стратегии вы бы придерживались?
Еще несколько вещей: я работаю над этим как единая армия, поэтому нанимать достаточное количество людей и переделывать / реорганизовывать систему - неприемлемый ответ. И через несколько недель или месяцев я действительно должен показать некоторый видимый прогресс, так что я тоже не вариант проводить рефакторинг самостоятельно через пару лет.
Некоторые технические детали: система написана на Java и PHP, но я не думаю, что это имеет значение. За ним стоят две базы данных, Oracle и PostgreSQL. Помимо упомянутых перед недостатками недостатков, сам код тоже плохо написан и документирован.
Дополнительная информация:
Встречная проблема не связана с синхронизацией. Операторы counter ++ добавляются к некоторым модулям и не добавляются к некоторым другим модулям. Быстрое и грязное решение - добавить их туда, где они отсутствуют. Долгое решение - сделать его своего рода аспектом для модулей, которые в нем нуждаются, чтобы потом его невозможно было забыть. У меня нет проблем с исправлением подобных вещей, но если я внесу это изменение, я сломаю более 10 других модулей.
Обновлять:
Я принял ответ Грега Д. Даже если мне больше нравится Адам Беллер, это не поможет мне узнать, что было бы идеально знать. Спасибо всем за ответы.
+1 - Это ужасно крутая ситуация! или это ужасно ужасно?
Ответы 9
Вы открываете каталог, содержащий эту систему, с помощью проводника Windows. Затем нажмите Ctrl-A, а затем Shift-Delete. В вашем случае это похоже на улучшение.
А если серьезно: похоже, что у этого счетчика есть проблемы с поточной безопасностью. Я бы заблокировал увеличивающиеся функции.
Что касается остальной части системы, вы не можете сделать невозможное, поэтому постарайтесь сделать возможное. Вам нужно атаковать свою систему с двух сторон. Сначала позаботьтесь о более очевидных проблемных вопросах, чтобы вы могли продемонстрировать прогресс. В то же время вам следует решить больше проблем с инфраструктурой, чтобы когда-нибудь у вас был шанс действительно исправить эту вещь.
Удачи и да пребудет с вами источник.
Выберите одну область средней сложности для рефакторинга. Создайте скелет исходного кода, используя только сигнатуры методов существующих; возможно даже использовать интерфейс. Тогда начните взламывать. Вы даже можете указывать «новые» методы на старые, пока не доберетесь до них.
Затем тестирование, тестирование, тестирование. Поскольку нет никаких модульных тестов, может быть, просто использовать старые добрые модульные тесты с голосовой активацией (люди)? Или напишите свои собственные тесты по ходу дела.
Документируйте свой прогресс по мере того, как вы заходите в какое-то хранилище, включая разочарования и вопросы, чтобы, когда следующий бедняга, получивший этот проект, не был там, где вы :).
Как только вы закончите первую часть, переходите к следующей. Ключ в том, чтобы опираться на постепенный прогресс, поэтому не следует начинать сначала с самого сложного; будет слишком легко деморализоваться.
У Джоэла есть пара статей о переписывании / рефакторинге:
http://www.joelonsoftware.com/articles/fog0000000069.html
http://www.joelonsoftware.com/articles/fog0000000348.html
Спасибо за ответ. Вы правы в процессе, я уже делал это раньше. Но в этой системе я просто не могу найти ручку, чтобы сначала потянуть.
Что ж, вам нужно с чего-то начать, и похоже, что есть ошибки, которые нужно исправить. Я бы работал над этими ошибками, проводя быстрые рефакторинги и написание любых возможных модульных тестов на этом пути. Я бы также использовал такой инструмент, как SourceMonitor, чтобы идентифицировать некоторые из наиболее «сложных» частей кода в системе и посмотреть, могу ли я каким-либо образом упростить их дизайн. В конце концов, вам просто нужно признать, что это будет медленный процесс, и сделать небольшие шаги в направлении улучшения системы.
Это целая книга, в которой в основном говорится о модульном тестировании и рефакторинге, но с более практическими советами о том, как это сделать.
http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg
http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
Хм, спасибо добавил это в мой список желаний Amazon. Получу при следующем заказе :-)
Что от вас сейчас спрашивают? Вас просят реализовать функциональность или исправить ошибки? Они вообще знают, чего хотят от вас?
Если у вас нет рабочей силы, времени или ресурсов, чтобы «починить» систему в целом, то все, что вы можете сделать, - это внести залог. Вы говорите, что сможете добиться некоторого «видимого прогресса» через несколько месяцев. Что ж, если система настолько плоха, как вы описали, вы действительно можете сделать систему еще хуже. Под давлением необходимости сделать что-то заметное вы просто добавите код и сделаете систему еще более запутанной.
В конце концов, вам нужно провести рефакторинг. Нет никакого способа обойти это. Если вы можете найти способ рефакторинга, который будет виден вашим конечным пользователям, это было бы идеально, даже если это займет 6-9 месяцев или год вместо «нескольких месяцев». Но если вы не можете, тогда вам нужно сделать выбор:
- Выполните рефакторинг, и вы рискуете, что вас посчитают "ничего не достигающим", несмотря на ваши усилия
- Не выполняйте рефакторинг, достигайте «видимых» целей и не делайте систему более запутанной и трудной для рефакторинга в один прекрасный день. (Может быть, после того, как вы найдете работу получше и надеетесь, что следующий разработчик никогда не узнает, где вы живете.)
Какой из них наиболее выгоден лично вам, зависит от культуры вашей компании. Решат ли они однажды нанять больше разработчиков или полностью заменить эту систему каким-либо другим продуктом?
И наоборот, если ваши усилия «исправить что-то» на самом деле сломают другие вещи, поймут ли они, с каким чудовищем вас просят бороться в одиночку?
Здесь нет простых ответов, извините. Вы должны оценивать, исходя из вашей уникальной, индивидуальной ситуации.
Я никогда не предполагаю, что заказчик знает, чего он хочет :-) Однако в данном случае я не реализую новые функции. Самая важная цель - сделать возможным быстрее и проще внедрять новые вещи.
Я бы попытался выбрать часть системы, которую можно было бы достаточно быстро извлечь и переписать изолированно. Даже если это не так много, вы можете довольно быстро показать прогресс, и у вас не будет проблем с непосредственным взаимодействием с унаследованным кодом.
Надеюсь, если вы сможете выполнить несколько таких задач, они увидят, что вы делаете видимый прогресс, и вы могли бы выдвинуть аргумент в пользу найма большего количества людей для переписывания более крупных модулей. Когда части системы полагаются на неправильное поведение, у вас нет другого выбора, кроме как отделиться, прежде чем что-то исправлять.
Надеюсь, вы сможете постепенно создать команду, способную все переписать.
Все это должно сопровождаться приличным обучением, иначе старые привычки людей сохранятся, и ваша работа будет виновата, если что-то пойдет не так, как ожидалось.
Удачи!
Откажитесь от всего, что в настоящее время существует, что вызывает проблемы, и напишите новые, которые работают правильно. Задокументируйте как можно больше о том, что изменится, и повсюду повесьте большие красные мигающие знаки, указывающие на эту документацию.
Поступая таким образом, вы можете сохранить свои существующие ошибки (те, которые компенсируются где-то еще) без замедления вашего продвижения к получению реально работающей системы.
- Потушить пожары. Если есть какие-либо проблемы критического приоритета, какими бы они ни были, вы должны решить их в первую очередь. Взломайте его, если нужно, с вонючей кодовой базой все в порядке. Вы знаете, что в будущем вы его улучшите. Это ваша техника продаж, ориентированная на тех, кому вы подчиняетесь.
- Выберите низко висящие фрукты. Я предполагаю, что вы относительно новичок в этом конкретном программном обеспечении, и вам было поручено разобраться с этим. Найдите несколько очевидных простых проблем в связанной подсистеме кода, решение каждой из которых не должно занимать больше дня или двух, и исправьте их. Это может включать рефакторинг, а может и нет. Цель состоит в том, чтобы познакомиться с системой и стилем оригинального автора. Вам может не повезти (один из двух некомпетентных сотрудников, которые работали с моей системой до меня, всегда фиксировал свои комментарии четырьмя знаками препинания вместо одного, что позволяло очень легко отличить, кто написал конкретный сегмент кода), но вы разовьете понимание слабых сторон автора, чтобы знать, на что обращать внимание. Например, сильная, тесная связь с глобальным состоянием или плохое понимание языковых инструментов.
- Ставьте перед собой большую цель. Если ваш опыт совпадает с моим, вы будете все чаще и чаще сталкиваться с определенным фрагментом спагетти-кода по мере выполнения предыдущего шага. Это первый узел, который вам нужно распутать. Обладая опытом, который вы приобрели, понимая компонент и знания о том, что, вероятно, исходный автор сделал неправильно (и, следовательно, что вам нужно остерегаться), вы можете начать представлять себе лучшую модель для этого подмножества системы. Не волнуйтесь, если вам все еще нужно поддерживать некоторые беспорядочные интерфейсы для поддержания функциональности, просто делайте это постепенно.
Вспенить, промыть, повторить! :)
Со временем подумайте о добавлении модульных тестов для вашей новой модели на один уровень ниже ваших интерфейсов с остальной системой. Не закрепляйте плохие интерфейсы в коде с помощью тестов, которые их используют, вы измените их в следующей итерации.
Решение конкретных проблем, о которых вы говорите:
Когда вы сталкиваетесь с ситуацией, с которой пользователи работают вручную, поговорить с пользователями об изменении ее. Убедитесь, что они примут изменение, если вы предоставите его, прежде чем потратить на это время. Если они не хотят изменений, ваша задача - поддерживать нарушенное поведение.
Когда вы сталкиваетесь с ошибочным компонентом, над которым работали несколько других компонентов, я поддерживаю технику параллельных компонентов. Создайте счетчик, который работает так же, как работает существующий должен. Предоставьте аналогичный (или, если возможно, идентичный) интерфейс и вставьте новый компонент в кодовую базу. Когда вы касаетесь внешних компонентов, которые работают вокруг сломанного, попробуйте заменить старый компонент новым. Подобные интерфейсы облегчают перенос кода, и старый компонент все еще работает, если новый выйдет из строя. Не удаляйте старый компонент, пока не сможете.
Спасибо за ответ. Мой план состоял в том, чтобы сначала заняться низко висящими фруктами, проблема в том, что я просто не мог их найти. Может, мне стоит постараться ...
Фрукты могут быть в глазах смотрящего. Мне повезло, потому что в моей системе была пара приложений winforms .Net, поэтому мой первоначальный низко висящий плод был исправлением организации пользовательского интерфейса и сотнями предупреждений о потенциальных нулевых ссылках.
Я работаю с устаревшей системой с такими же характеристиками уже почти три года, и я не знаю никаких сокращений.
Что меня больше всего беспокоит в нашей устаревшей системе, так это то, что мне не разрешено исправлять некоторые ошибки, поскольку многие другие функции могут выйти из строя, если я их исправлю. Это требует уродливых обходных путей или создания новых версий старых функций. Вызовы к старым функциям затем можно заменить новыми (во время тестирования).
Я не уверен, какова цель вашей задачи, но я настоятельно рекомендую вам как можно меньше трогать код. Делайте только то, что вам нужно.
Вы можете захотеть получить как можно больше документов, опросив людей. Это огромная задача, поскольку вы не знаете, какие вопросы задавать, и люди забудут многие детали.
Кроме этого: убедитесь, что вам платят и достаточно моральной поддержки. Будет плач и скрежет зубов ...
Один из моих коллег попытался узнать у первоначального разработчика о нашей системе, чтобы получить представление. Единственный ответ, который он получил, был: «Все, что вам нужно знать, находится в коде». Это было до того, как исходный разработчик отправил мне по электронной почте zip-файл своей директории сборки, так как исходный репозиторий не был собран.
Йепп, звучит знакомо. Однако я не думаю, что смогу просто принять ответ, коснуться как можно меньше кода и получить деньги бесплатно. Возможно, я слишком увлечен, но это просто не мой путь :-)
Удачи! Есть одна вещь, которая мне нравится в работе с неисправной системой - ничто из того, что я делаю с ней, не может сделать ее хуже, чем это было до того, как я начал. :)