orm:
auto_generate_proxy_classes: true
naming_strategy: doctrine.orm.naming_strategy.underscore
auto_mapping: true
mappings:
App:
is_bundle: false
type: annotation
dir: '%kernel.project_dir%/src/Entity'
prefix: 'App\Entity'
alias: Apporm:
auto_generate_proxy_classes: true
naming_strategy: doctrine.orm.naming_strategy.underscore
auto_mapping: true
mappings:
App:
is_bundle: false
type: annotation
dir: '%kernel.project_dir%/src'
prefix: 'App'
alias: AppПро математику
https://youtu.be/KcvwWVZWnmw
в любой хорошей компании есть какой-либо выработанный подход к разработке, не обязательно agile, которого все придерживаются. В таком случае каждый занимается своим делом
Все же мы говорим про выгорание, а при такой системе, его получается избежать на сколько это возможно.
По мере роста своих знаний ты получаешь все более сложные задачи
видишь свой рост, а когда ты его видишь - откуда браться выгоранию?
Есть коллеги, с которыми ты на митинге обсуждаешь проблемные места. Коллеги могут помочь и подсказать как лучше сделать.
без лишних напрягов и стресса. Ты получаешь удовольствие от работы.
Agile почти рифмуется с «выгорай»
Но недели сменились месяцами, и мы начали ощущать на себе некоторое «выгорание». Дело в том, что какой бы идеальной ни была методология — всегда будут вылезать незапланированные баги, которые требуют больше времени, чем планируется. Чтоб латать все эти дыры и в понедельник выглядеть так, будто у тебя всё идеально, приходилось работать на выходных. Почти ежедневные овертаймы даже не обсуждались — каждый думал над тем, что ему нужно будет говорить на следующий день на SCRUM-митинге. И ситуация была такова, что никто не хотел выглядеть на собрании «слабаком». Поэтому каждый старался побольше сделать вечером и пораньше прийти на работу, чтобы успеть к 11 что-то закончить и сказать что-нибудь в духе — «Этот функционал готов, но его нужно потестить» или «Новый сервис работает, но у меня не было времени его полностью проверить». И звучит вроде бы хорошо — что-то работает, что-то готово, что-то функционирует, осталась лишь мелочь, ерунда — потестить.
Часто используется agile
Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.
я ведь не DBA