Какие недостатки повторного использования кода?

Question

Несколько лет назад нам была нужна библиотека C ++ IPC для вызова функций через TCP. Мы выбрали один и использовали его в нашем приложении. Через некоторое время стало ясно, что он не обеспечивает всех необходимых нам функций. В следующей версии нашего программного обеспечения мы выбросили стороннюю библиотеку IPC и заменили ее на ту, которую написали сами . С тех пор я иногда сомневаюсь, было ли это хорошим решением, потому что оказалось, что это было довольно много работы, и это, очевидно, было похоже на изобретать колесо . Поэтому мой вопрос: есть ли недостатки в повторном использовании кода, которые оправдывают это переизобретение?

Answer 1

Я могу предложить несколько

1. Ошибки повторяются - если вы повторно используете код ошибки:)

2. Иногда это может добавить дополнительные издержки. Например, если вам просто нужно сделать простую вещь, не рекомендуется использовать сложную БОЛЬШУЮ библиотеку, которая реализует требуемую функцию.

3. Вы можете столкнуться с некоторыми проблемами лицензирования.

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

5. Повторное использование плохо документированной библиотеки может занять больше времени, чем ожидалось / оценивается

Answer 2

Проблема номер один: вы можете успешно повторно использовать код, только если этот код ХОРОШИЙ код. Если он был спроектирован плохо, имеет ошибки или очень хрупок, то вы столкнетесь с теми же проблемами, с которыми уже сталкивались - вам все равно придется делать это самостоятельно, потому что так сложно изменить существующий код.

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

Answer 3

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

Answer 4

P.S. Причины написания нашей собственной библиотеки были:

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

Answer 5

Недостатки повторного использования кода:

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

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

Так или иначе, вот некоторые из аргументов, которые я бы использовал для пропаганды «изобретения колеса».

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

Answer 6

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

Answer 7

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

Answer 8

Золотая Мудрость :: Она должна быть пригодна для использования, прежде чем ее можно будет повторно использовать.

Answer 9

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

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

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

Всегда есть компромисс.

Answer 10

Хотите знать, что вы используете, чтобы сохранить эту библиотеку, которую вы заново изобрели?