Многие люди, работающие над микросервисами и сервисными архитектурами, слишком много внимания уделяют повторному использованию. Больше так не делай
С тех пор, как я был скромным программистом на COBOL в 1980-х годах, повторное использование было объединяющим лозунгом для программистов. Эра структурного программирования началась, когда мы определили функции, которые можно было вызывать несколько раз. Впоследствии мы перешли к другим языкам, таким как C и объектно-ориентированный C++, как к лучшим способам расширения концепции повторного использования. В конце концов мы перешли к распределенным объектам и сервисам SOA (сервисно-ориентированная архитектура), где повторное использование выросло из отдельных приложений, а затем к слабо связанным межплатформенным повторно используемым сервисам. Теперь у нас есть облачные сервисы или API, а также интригующая концепция микросервисов, которые обеспечивают новый уровень общей детализации!!!.
Как для облачных, так и для необлачных разработчиков повторное использование и/или совместное использование приобрели новый смысл. В 2022 году многие люди используют термин DRY, что означает «не повторяйся», в качестве своего нового слогана для разработки и развертывания приложений и систем. Однако все не так просто. За эти годы я сделал две основные ошибки при разработке приложений на основе сервисов: чрезмерное повторное использование и недостаточное количество.
Возможно ли повторное использование слишком большого количества сервисов? Это происходит, когда продуктивность, полученная от использования одних и тех же услуг на регулярной основе, снижается или даже становится отрицательной. Примером может служить использование сервисов, которые должны быть абстрагированы, а некоторые из их функций изменены в соответствии с потребностями приложения. Например, служба, которая получает данные потребительского кредита с полной информацией о клиенте, но возвращает большую часть общих данных в наборе ответов или потоке данных, поскольку они не нужны для этой конкретной функции в приложении.
Такого рода хаки, которые заставляют повторно использовать, становятся все более распространенными. Независимо от того, должны они это делать или нет, разработка приложений становится набором сервисов, которые используются повторно. Кроме того, эта неэффективность часто упускается из виду при проверке кода и сканерах кода, которые еще не осознали, что некоторое повторное использование может быть неэффективным. Я уверен, что некоторые из вас, кто использует код больше, чем я, обеспокоены тем, что детище повторного использования будет выброшено вместе с непродуктивной водой, но я не предлагаю вам вернуться к созданию одноразовых сервисов и микросервисов. .
Все сводится к пониманию преимуществ и недостатков использования повторно используемых сервисов, а также того, как их следует создавать и реализовывать. Основные опасения заключаются в следующем: улучшит ли повторное использование этих сервисов мое приложение? Нужно ли перепроектировать и развернуть службу, которую я использую? Или мне следует создать новый, специально созданный сервис?
Вы обнаружите, что выбор нескольких путей и непредубежденность в отношении того, какие сервисы следует использовать повторно, часто более эффективны. Научитесь замечать, когда вы пытаетесь внедрить популярную концепцию в свою жизнь. Я предпочитаю быть продуктивным, чем каждый день ходить за толпой.
Пожалуйста, подпишитесь и поставьте лайк этой странице, чтобы получать больше интересных и познавательных новостей о технологиях.
Будьте первыми, кто узнает, что происходит в мире технологий, нажмите «подписаться». Спасибо!!!
