Задать вопрос
bullock
@bullock
программирование

Вопрос организации архитектуры. Производительность или поддерживаемость?

В процессе написания приложения меня всегда разрывает на то что бы написать красиво и поддерживаемо или эффективно и по уродски. Вопрос в том насколько медленнее становиться приложение если везде использовать абстракции что бы соблюдать SIP?
У меня в одном из приложений есть контроллер Save в котором я считываю поток из HTTP тела сообщения и передаю этот поток другому своему приложению(типо микро сервисы). Кода не много, но наверное его стоило бы разместить в отдельном объекте? Но тогда мне каждый раз при обращении клиентво к этому контроллеру, придется создавать этот объект а это ресурсы.
Что вы делаете в таких случаях?
  • Вопрос задан
  • 408 просмотров
Комментировать
Подписаться 1 Простой Комментировать
Решения вопроса 2
longclaps
@longclaps
мне каждый раз при обращении клиентво к этому контроллеру, придется создавать этот объект

Пул соединений - слышали о таком? Если это действительно надо - так делают.
Ответ написан
1 комментарий
1 комментарий
@rodion11
php dev
При выборе между читаемостью и эффективностью, лучше выбирать читаемость.
Преждевременная оптимизация зло:
- угадать где будет узкое место не всегда возможно
- оптимизация занимает время
- код усложняется

В случае работы с HTTP, расходы на соединения, загрузку данных обычно отъедают большее время работы и скорость кода практически не влияет. (конечно все индивидуально и зависит от задачи)
Ответ написан
Комментировать
Комментировать
Пригласить эксперта
Ответы на вопрос 5
Griboks
@Griboks
Вы слишком помешаны на принципах программирования. Это хорошо только в "тяжёлых" больших проектах, но сильно портит маленькие приложения. Любые конструкции нужно вводить по мере необходимости, а не потому что так красиво и правильно.
Ответ написан
Комментировать
Комментировать
@DoctorPro
Просчитайте, а есть ли плюсы от такой архитектуры, SIP, как и другие принципы разработки это, конечно, ориентир, но это не значит, что под условный helloworld надо создавать кучу абстракций в соответствии с принципами. Есть и другие принципы, например, KISS (Keep it simple). Если вы не видите явных плюсов, то может и не надо много абстракций
Ответ написан
Комментировать
Комментировать
mad_nazgul
@mad_nazgul
Инфомарция к размышлению
Ответ написан
Комментировать
Комментировать
qonand
@qonand
Software Engineer
Не стоит зацикливаться на принципах и слепо им следовать. Выбирать между производительностью и поддерживаемостью всегда стоит исходя из особенностей проекта. Стоит задуматься насколько вообще важна поддерживаемость в конкретном проекте и насколько ее могут ухудшить решения улучшающие производительность. Если проект мелкий или разрабатывается как какое-то временное решение, тогда маловероятно что производительный код сильно ухудшить поддерживаемость. Если же проект большой и в будущем в него будут активно вноситься изменения - стоит предпочесть поддерживаемость производительности
Ответ написан
Комментировать
Комментировать
@Xilian
Программист 1С, сетевые технологии, SQL
>>или эффективно и по уродски.

Что за бред?

>>(типо микро сервисы).

Вот это уже по уродски

>>Кода не много, но наверное его стоило бы разместить в отдельном объекте?

У тебя уже микросервис, который должен быть в своем АП и иметь свою иерархию объектов, или в нормальном случае - вообще ее не иметь.
Ответ написан
Комментировать
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Python developer
Bell Integrator
До 350 000 ₽
Разработчик программного обеспечения авионики
Котлин-Новатор • Санкт-Петербург
от 50 000 до 150 000 ₽
Ведущий разработчик программного обеспечения авионики
Котлин-Новатор
от 150 000 до 250 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Привязка к Маркетплейсам 1С Розница 2.3
20 апр. 2024, в 05:26
10000 руб./за проект
Дописать функцию на Flutter, работа с yandex map kit
20 апр. 2024, в 04:18
3000 руб./за проект
Английская версия для сайта на WordPress
20 апр. 2024, в 03:34
8000 руб./за проект
Ещё заказы