За долгие годы вокруг понятий «дизайн» и «архитектура» накопилось много путаницы. Что такое дизайн? Что такое архитектура? Чем они различаются?
<...> Прежде всего, я утверждаю, что между этими понятиями нет никакой разницы. Вообще никакой.
Слабо отражается наверное потому, что это не важно. Даже не задумывался никогда об этом.
Предполагаю, вы видите проблему не в количестве «букв» на экране и диске, а в усложнении кода для поминая. Так вот, мне не кажется, что размер кода вообще связан с простотой понимания, по крайней мере линейно. Например, когда Sensors/FuelTank/etc. представлены отдельными классами — код проще и быстрее прочесть/понять вне зависимости от количества доп. кода и даже доп. сущностей. Разделение и упорядочивание, насколько мне известно — замечательный трюк для представления мозгу человека сложных вещей простыми.
Я бы упрощенно выразил смысл SOLID в контексте размера кода так:
Сложность (чтения/понимая/правки) спагетти-кода увеличивается экспоненциально, тогда как количество «букв» растет линейно. Сложность SOLID-based кода увеличивается линейно, хотя количество «букв» растет экспоненциально.
И выбор как бы очевиден. Когда не предвидится раздутия функциональности компонента — нам пофиг на экспоненциальный рост сложности. Можно не плодить дополнительных сущность.
Сроки и бюджет — это не самоцель, а инструмент управления для управленцев. Цель — как-раз таки прибыльный продукт (если прибыльный, значит рабочий и любые оверхеды окупились). Соответственно, привязывать мотивационные премии к этим метрикам можно только при равных условиях на разных проектах, и то — условно.
Давать ли? А почему нет, если есть за что? Это ж не соревнование было, где победитель должен был быть один и первой команде могло быть обидно. А чтоб точно не было обидно, надо всем объяснить ситуацию о разнице в проектах и пообещать усовершенствовать критерии премирования.
А Django это лишний сахар над wsgi?
JS то тут причем? Насколько я пониманию, если взглянуть на стиль вьюсетов внимательнее, то можно найти много общего с принципом SOLID. Тоесть, не нужно придумывать свою соответствующую структуру.
> Во-первых, бросается в глаза обилие кода. Его гораздо больше, чем в варианте с одним эндпоинтом и тремя методами.
Ага, а сколько кода (причем дублируемого) будет в вашем __list_view и __detail_view? А в примере с UserViewSet — это полный код. Осталось только указать queryset и другие атрибуты. Никаких "# Actions here..." там больше нет, всё в миксинах.
> Как видите, особой надобности во ViewSet нету. Трэйс запроса происходит ровно одной строчкой, но нам доступны функции get, post, put и иже с ними.
Что значит надобности? Зависит от решаемой задачи. ViewSet и дженерики хороши в двух случаях: когда всё просто и когда всё сложно.
Когда всё просто — это наследовался от ModelViewSet, указал queryset, serializer_class и endpoint готов.
Когда всё сложно — это ViewSet с различными (в том числе кастомными) миксинами, которые можно применять во всех ViewSet проекта и расширять/изменять их по мере необходимости через методы (типа perform_update у UpdateModelMixin). В итоге имеем правильную и красивую архитектуру приложения без своих костылей.
На счёт Swagger — да, я все эти проблемы побороть не смог. Да что там, даже ApiRoot (тот, который для рендеринга карты урлов на главной) ломается. Но если исследовать проблему чуть глубже — становится понятно, что оно и не может работать. Нужно использовать другой путь, а это обычное дело в разработке.
Значит вы хороший программист :)
Make it Work, Make it Right, Make it Fast.
> По поводу сути…
Теперь яснее. А то интерфейсы и логотип как бы намекают, что это для широкой аудитории (тоесть, посетителей библиотеки) и картинка в голове не складывалась.
В Киеве норм, приезжайте.
Р. Мартин, «Чистая архитектура»
Предполагаю, вы видите проблему не в количестве «букв» на экране и диске, а в усложнении кода для поминая. Так вот, мне не кажется, что размер кода вообще связан с простотой понимания, по крайней мере линейно. Например, когда Sensors/FuelTank/etc. представлены отдельными классами — код проще и быстрее прочесть/понять вне зависимости от количества доп. кода и даже доп. сущностей. Разделение и упорядочивание, насколько мне известно — замечательный трюк для представления мозгу человека сложных вещей простыми.
Я бы упрощенно выразил смысл SOLID в контексте размера кода так:
Сложность (чтения/понимая/правки) спагетти-кода увеличивается экспоненциально, тогда как количество «букв» растет линейно. Сложность SOLID-based кода увеличивается линейно, хотя количество «букв» растет экспоненциально.
И выбор как бы очевиден. Когда не предвидится раздутия функциональности компонента — нам пофиг на экспоненциальный рост сложности. Можно не плодить дополнительных сущность.
Давать ли? А почему нет, если есть за что? Это ж не соревнование было, где победитель должен был быть один и первой команде могло быть обидно. А чтоб точно не было обидно, надо всем объяснить ситуацию о разнице в проектах и пообещать усовершенствовать критерии премирования.
Дальше не читал.
JS то тут причем? Насколько я пониманию, если взглянуть на стиль вьюсетов внимательнее, то можно найти много общего с принципом SOLID. Тоесть, не нужно придумывать свою соответствующую структуру.
Ага, а сколько кода (причем дублируемого) будет в вашем __list_view и __detail_view? А в примере с UserViewSet — это полный код. Осталось только указать queryset и другие атрибуты. Никаких "# Actions here..." там больше нет, всё в миксинах.
> Как видите, особой надобности во ViewSet нету. Трэйс запроса происходит ровно одной строчкой, но нам доступны функции get, post, put и иже с ними.
Что значит надобности? Зависит от решаемой задачи. ViewSet и дженерики хороши в двух случаях: когда всё просто и когда всё сложно.
Когда всё просто — это наследовался от ModelViewSet, указал queryset, serializer_class и endpoint готов.
Когда всё сложно — это ViewSet с различными (в том числе кастомными) миксинами, которые можно применять во всех ViewSet проекта и расширять/изменять их по мере необходимости через методы (типа perform_update у UpdateModelMixin). В итоге имеем правильную и красивую архитектуру приложения без своих костылей.
На счёт Swagger — да, я все эти проблемы побороть не смог. Да что там, даже ApiRoot (тот, который для рендеринга карты урлов на главной) ломается. Но если исследовать проблему чуть глубже — становится понятно, что оно и не может работать. Нужно использовать другой путь, а это обычное дело в разработке.
Значит вы хороший программист :)
Make it Work, Make it Right, Make it Fast.
> По поводу сути…
Теперь яснее. А то интерфейсы и логотип как бы намекают, что это для широкой аудитории (тоесть, посетителей библиотеки) и картинка в голове не складывалась.