Comments 9
Почему-то я открывал эту статью, заранее настроившись скептически. Видимо, на фоне других недавних публикаций. Но тем приятнее было увидеть живой интересный рассказ, красивый чистый код, даже какую-никакую интригу!
Большое спасибо и побольше бы таких статей!
Интересная статья. почаще бы так делились опытом, еще и с примерами чистого кода
Согласен. Быть капитаном команды в хакатонах - это отдельный вид искусства.
По моему опыту офлайн хакатонов - если постоянно не взаимодействовать с командой и уточнять что нужно делать каждому, то получается как в басне "Лебедь, рак и щука". Либо делают не то, что нужно, либо замалчивают и не делают с совсем ничего.
как сделать так чтобы Shemas генерировались с Entity
Я пару лет уже не писал, но помню брали тег @Model, и с ним работало.
Не минусил, но если интересуют замечания, то могу немного набросать из того, что сразу бросилось в глаза:
private ApiFrontendService $apiFrontendService;
Вы используете новую версию PHP, там можно свойство в конструктор внести, чтобы было меньше бойлерплейта. И apiFrontendService можно сразу на вход конструктора запросить, резолв зависимостей — задача фреймворка, симфони эту работу хорошо делает.
Request $request
Возможно для описанных примеров был бы удобнее doctrine-конвертер, он позволяет подать на вход контроллера сразу сущность.
Запросы к бд прямо в сервисе или контроллере, логика изменений в контроллере (editDepartament) вместо сервиса — эти моменты могут вызвать расстройство у опытных читателей, но тут можно оговориться, что у нас логики мало, сущности единообразные, плюс у нас хакатон, поэтому мы не выносим запросы в классы-репозитории и где-то ленимся еще сильнее и не выносим обработку в сервис. Такая оговорка также подскажет новичкам, что не стоит код копировать как есть в свои тестовые.
А вот возврат JsonResponse из сервиса, на мой взгляд, более грубое действие. Формат отдачи, как и код возврата — это работа контроллера. Сервис лучше держать удобным для обращения из других внешних точек: вызовов из консольной команды или из консюмера, а не только из контроллера. К тому же это довольно быстрая правка даже в контексте хакатона.
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда, но для статьи код желательно причесать под PSR-12: добавить strict_types, поправить отступы (первые строчки разные даже у приложенных двух файлов), скобки ")]" у OAT где-то на одной строке, где-то отдельно на разных. Это мелочи, но с ними код читается приятнее и выглядит более привычно.
За статью спасибо, легко читается. Взять новый для себя язык и фреймворк для хакатона — смело, справиться — вообще круто, видно опыт в IT. Отдельно хочется отметить swagger-аннотации: приятно видеть, что сделана не только апишка, но и дока к ней для удобства участников команды.
Спасибо вам за замечания! по сути ради таких комментов и пишу статьи, т.к. в живую фидбека по своему коду получаю очень мало и начал стараться обмениваться опытом в формате статей
Единственное, в чем вы не правы это
И последнее: на хакатоне можно писать как угодно, т.к. мы спешим, и инструменты настраивать некогда
Популярное заблуждение. Быстрокодить можно на хакатонах, где важен результат выполнения функций, а не сама функция. Здесь же недельный хакатон результатом которого должна быть функциональная система - иначе я бы наделал CRUD на fastify + nodejs и вообще бы не парился со слоями - контроллер, репозиторий, сервисы, орм и тп, есть варианты сделать это куда проще без поднятия Symfony)
Согласен, тут некорректно выразился: под "как угодно" подразумевалось только менее строгое следование стилю оформления кода/форматированию. Т.е. часть, которая относится к переносам/отступам, и на которые обычно прикручивают чекеры/автоформатеры. Благодаря автоформатерам эту часть можно откладывать на попозже и поддерживаемость системы не сильно пострадает, если мы во время хакатона сэкономим время на этом этапе, т.к. настроенный позже инструмент легко приведет все файлы к нужному стилю
Любопытно, что у вас на фронте hi-end технологии: третий Vue на тайпскрипте, да ещё и с pinia, при этом на бэке мамонт PHP, а не какой-нибудь более современный Go или Kotlin.
По опыту многочисленных хакатонов сразу вижу две серьёзнейшие ошибки, но вы их и сами увидели.
Во-первых, разумеется, ни о каком хакатоне параллельно с работой не может идти речи. Хакатон это спринт, работа наизнос, нужно выкладываться полностью в короткие сроки. Если отгул не дают, лучше вообще не идти. А с работой это как бежать спринт и посередине остановиться завязывать шнурок.
Во-вторых, команда из незнакомых людей. К сожалению, довольно часто бывает, что люди или просто кидают, или оказываются некомпетентными, или ещё что-то подобное. У вас тут две таких ситуации: сначала питонист сказал, что не сделает (хотя в задаче ничего сложного нет), а потом сразу двое сказали, что не собираются ничего делать. Лучше стараться идти с друзьями, коллегами, знакомыми.
А так прикольно, и удачи в дальнейшем )
Делюсь опытом участия в хакатоне от Совкомбанка