Повторное использование кода: повторное использование сложного метода против деталей для сбора вишни

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

Фон

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

Как повторно использовать?

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

Теперь я вижу две альтернативы:

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

Моя проблема

Мне трудно судить, какой подход лучше всего. С одной стороны, я считают, что повторное использование важно, и 1) кажется, позволяет мне снова использовать его. На с другой стороны, просматривая код, я чувствую, что, по крайней мере, 30% -50% кода больше не применяются, поэтому я боюсь 1) может быть много рефакторинг, и в конце концов я бы использовал только немного больше, чем с подходом 2).

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

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

5 голосов | спросил sleske 27 Maypm11 2011, 15:11:56

3 ответа


6

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

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

Повторное использование кода - отличная идея, но повторное использование плохих решений не так много.

ответил Jaap 27 Maypm11 2011, 15:50:37
3

Мой совет - это не перебор с повторным использованием кода. Иногда (чаще, чем вы думаете) вы считаете, что вам нужно повторно использовать код в новом месте, но на самом деле только здесь и сейчас код, который вам нужен, такой же, как и код, который у вас есть в старой части система. Если два компонента логически связаны и будут развиваться вместе (скажем, разные варианты одной и той же бизнес-задачи), обычно хорошо приложить некоторые усилия для повторного использования кода. Если они случайно выглядят одинаково, они относятся к двум различным проблемным областям и могут развиваться по разным путям в будущем, связывая их с помощью повторного использования кода, это принесет больше проблем, чем преимуществ. В этой ситуации не стесняйтесь Ctrl + C, Ctrl + V.

ответил quant_dev 27 Maypm11 2011, 15:46:07
1

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

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

  2. Рефакторинг для разделения синтаксического анализа и потребления данных. Другими словами, иметь внутреннее представление данных, которые не будут меняться, если у вас нет новых требований. Это может содержать в себе многоразовые биты, поэтому вы можете иметь дело с более сложной логикой, которая полагается на данные в разных частях иерархии объектов. Два входа просто потребляют необработанный формат и преобразуют его во внутреннее представление. Для поддержки новых форматов требуется только добавление нового парсинга front end.

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

ответил Berin Loritsch 27 Maypm11 2011, 19:14:45

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132