There are many unknowns unknowns
Контакты
Местоположение
Россия, Москва и Московская обл., Москва

Достижения

Все достижения (17)

Наибольший вклад в теги

Все теги (127)

Лучшие ответы пользователя

Все ответы (126)
  • Как получить теоретические знания, чтобы иметь возможность описывать то, что я реализую на практике?

    @EvgeniiR
    https://github.com/EvgeniiR
    Итак,
    какие конкретно стоит почитать

    1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
    2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
    3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
    4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка очень годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место и советовать всем новичкам читать первой.
    Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

    подсознательно я продолжаю выбирать именно "правильные" подходы,

    Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
    Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

    наследование — это реализовывается само собой.

    Вот эта фраза явно даёт понять что у вас есть проблемы в дизайне. Наследование это весьма опасная штука, и делать его просто потому что показалось удобным, не задумываясь об LSP, контрактах и инвариантах.. Кхм.. Плохо.

    Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.
    Ответ написан
  • Как избежать дублирования кода в микросервисной архитектуре?

    @EvgeniiR
    https://github.com/EvgeniiR
    Как избежать дублирования кода в микросервисной архитектуре?

    Не помещать одну и ту же логику в разные микросервисы, правильно разделять их границы

    Простой пример 2 сервиса используют одну базу и одну таблицу

    Границы проведены явно не правильно.

    модель орм на 1 экран кода, и как мне поступить без копипасты чтобы она была и так и там

    Это даже не SOA, это монолит общающийся по АПИ, выходит

    Закономерный вопрос - для чего вам разделение на микросервисы?
    Ответ написан
  • Насколько часто используется Spring HATEOAS в реальных проектах?

    @EvgeniiR
    https://github.com/EvgeniiR
    Вот вы на Тостер заходите, вопросы создаёте, просматриваете, сайт обновляется, появляются новые фичи, а приходилось ли вам обновлять ваш клиент (браузер) чтобы новыми фичами пользоваться?
    Мне не приходилось, нужно лишь страничку обновить, и получить обновленный гипертекст с новыми возможностями для переходов состояния.
    Вот вам и HATEOAS, используется часто. Профит - расширяемость, масштабируемость без необходимости обновления клиента.

    Благодаря HATEOAS, в частности, мы видим Веб таким, каким он существует сейчас, и с его текущими масштабами.

    А если к этому добавить уникальные url'ы, self-descriptive messages, кэширование, не хранить состояние клиента на сервере, использовать известные клиенту и серверу медиа типы можно и REST API получить(есть ещё нюансы)
    Ответ написан
  • Почему бы не сделать PHP полностью асинхронным?

    @EvgeniiR
    https://github.com/EvgeniiR
    1. PHP умирает на каждый запрос. Это его главное преимущество и особенность. Это допускает очень много вещей, т.е можно не париться закрытием файлов, завершением подключения к БД и т.п. Как только вы захотите писать асинхронно вам про всё это нужно будет помнить.

    2. Итак, плавно переходим к тому что помнить, вобщем то, нужно будет не только вам. 99% всех библиотек/фреймворков etc. для PHP не пригодны к работе асинхронно.

    3. "полностью асинхронным" = отсутствие блокировок? Первое на чем вы споткнетесь - банальные запросы к базе. С дефолтным драйвером они идут синхронно. Точно так же как синхронно работает куча других подключений, и всякие Swoole etc. вынуждены писать над всем этим свои обертки и свои драйвера к БД.

    Вобщем, асинк в PHP это огромное усложнение на пустом месте, и при наличии блокирующих операций не имеет никакого смысла. Сильно проще сменить язык программирования, если вам нужна асинхронщина.
    По описанию вашего вопроса - гляньте RoadRunner, интересная штука. Как раз чтобы сократить оверхед на инициализацию.
    Есть ещё всякие штуки аля https://github.com/php-service-bus/service-bus , но повторюсь, проще подходящий ЯП взять.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (55)