Конкретно в этом случае используется странное решение(на мой взгляд), и не совсем понятно зачем так делать, т.к. задавать это все через параметры проще. Но т.к. rest это просто стиль архитектуры, то вам никто не запретит так делать, но если кому-то достанется такой код, то он будет не в восторге.
У нас color - это не единая сущность в приложении (пример). TextColor, TagColor, BoxColor (все они имеют разные структуры данных), если вынести на получение через /colors то совершенно не ясно какой именно из типов тут получается
Алексей Ярков, Ну у меня вопросы касается именно реста и его бест практикс, поэтому возникли доп вопросы. Ваш вариант имеет место быть, но моя задача сейчас - рест, спасибо
У вас появляется новый тип - Комментарии к профилю. Комментарии к новостям имеют только текст, к профилю могу содержать еще и картинки. Что вы будете делать?
ThunderCat, и это все еще не решаешь проблему параллельности. 2 разработчика не могут взять ее одновременно потому что одна зависит от другой, в таком случае и нет смысла в этом случае в разбиении ее на подзадачи. Основная проблема в том что из одной большой задачи у меня случается так, что подавляющее большинство задач завязаны друг на друге. Я могу сделать из них более мелкие, но не могу их запараллелить
Adamos, речь скорее не про фронт и бэк, а элемент взаимодействия. По сути, домэин логика которую разделить не получится. Ну не могу я никак сделать сортировку по полю, которое должно быть добавлено в другой задачи. А главная тут проблема - во время разработки могут появиться дополнительные условия которые были не учтены. Вы ведь не считаете, что человек (самый лучший в мире проектировщик) может помнить наизусть монолит который пилят около 10 лет?
Дробление на еще более мелкие все еще несет за собой проблему зависимости задач друг от друга. Вот пилю прямо сейчас огромную фичу, представляю как ее подробить на задачи и понимаю, что никаким распаралеливанием тут не пахнет. Каждую новую задачу нужно начать делать после того как была завершена прошлая
Сергей Горностаев, сеньеров не много берут, но тех кого берут, все на долго не остаются. Говорить смысла особого нет - объяснения всегда будут не теми что есть на самом деле
Диалоги с ними были, у всех по разному. Но часто именно руководство не достаточно довольно их работой. Как я и сказал, разработчики сильные, но какие-то аспекты в них не нравятся техническому руководству.
DevMan, вы ведь понимаете что такое паттерны?
вы понимаете как они применяются?
вы понимаете для чего они вообще нужны?
если так, то ответьте мне на вопрос - можно ли, например, паттерн object pool использовать для создания запросов из воркеров?
tommy-vercetti, я думал об этом, но мне показалось, что это будет слишком дорого для нас сейчас. По мимо, у меня есть вопрос. Сейчас у нас один проект занимается наполнением базы (принимает хуки от сервисов, пишет данные). Другой сервис выводит эти данные и дает возможно работы с ними. Как тут можно использовать 2 независимые базы, если не прибегать к дополнительным сервисам переноса данных?
У нас color - это не единая сущность в приложении (пример). TextColor, TagColor, BoxColor (все они имеют разные структуры данных), если вынести на получение через /colors то совершенно не ясно какой именно из типов тут получается