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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Первоначальное время для создания повторно используемого кода дороже и дороже.
2. Когда в основной ветке есть обновление, вам необходимо синхронизировать его и развернуть снова.
3. Ошибки воспроизводятся - если вы повторно используете ошибочный код
4. Повторное использование плохо документированного кода может занять больше времени, чем ожидалось / предполагалось.