Компрометация дизайна и качества кода для интеграции с существующими модулями

Question

Приветствую!

Я унаследовал C # .NET-приложение, которое уже некоторое время расширяю и улучшаю.В общем, это была спешная работа (или тот, кто написал это, был менее компетентен, чем я).Приложение извлекает некоторые данные из встроенного устройства, отображает и манипулирует ими.В основе лежит коммуникационный поток в основной форме приложения, который выполняет более 600 строк кода, который вызывает функции повсеместно, реализуя конечный автомат - множество кода типа if-state-then-do.Взаимодействие с устройством осуществляется путем глобальной установки состояния / режима и предоставления возможности потоку делать свое дело.(Это всего лишь один пример плохого кода - в целом он не очень похож на OO, он напоминает стиль встроенного кода C, в котором написано встроенное ПО устройства).

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

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

Я слышал о «Если это не сломано, не делайте»t исправить это! ", поэтому мне интересно, должно ли это применяться, когда" оно "влияет на дизайн будущего кода!Любой совет будет оценен!

Спасибо!

Answer 1

Кроме того, чем дольше вы ждете, тем хуже будет пахнуть кодовая база.Мое предложение было бы сначала создать набор тестов, по которому вы можете оценить свой рефакторинг.Это значительно упрощает проверку того, что вы делаете рефакторинг или просто ломаете вещи:).

Answer 2

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

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

Но как только вы произведете рефакторинг кода, вы точно сможете его контролировать. И не забудьте документировать это! Завтра кто-то вполне может прийти и сказать о вас все, что вы рассказали об этом парне, который написал этот основной код.

Answer 3

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

Но вы должны учитывать бизнес-требования. Часто реальность мешает!

Можно ли было бы обернуть этот код в другой класс, интерфейс которого лучше подходит для того, как вы хотите продвинуть систему вперед? ( См. Схему адаптера )

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

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

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

EDIT

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

Answer 4

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

1. Время: у вас должно быть достаточно времени, чтобы изучить его, реализовать его и протестировать, не слишком много других задач, мешающих вам
2. Босс #1: если вы работаете на кого-то, ему нужно знать и утверждать время и усилия, которые вы потратите немедленно, необходимые для перестройки вашего решения
3. Босс # 2: ваш босс также должен знать, что преимущество наличияновое и чистое программное обеспечение будет стоить по цене возможных регрессий, и поэтому в начале развертывания могут быть неожиданные ошибки

Если у вас есть эти три, тогда продолжайте и реорганизуйте их.Это, безусловно, будет того стоить!

Answer 5

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

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

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

ПРИМЕЧАНИЕ: Обычно о переписывании кода не может быть и речи, но в зависимости от ситуации и количества кода, необходимого для переписывания, решение может отличаться.

Answer 6

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

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