Правильно ли я понимаю Dependency Injection - инъекция зависимостей, в данном случае автор указал в вопросе данный метод: передача класса конфига в конструктор RedisCache
я разрабатываю и поддерживаю некоторые проекты один используя gitflow, и создание релизов так же по началу напрягало, когда нужна сразу доработка на рабочем. Но со временем удобство gitflow победило это неудобство. Вот преимущества которые мне помогли:
1. master и develop помогают демонстрировать функционал на продакшен(рабочий) и пред-продакшен (демка) версиях сайта. Изменения сразу на продакшене сервере как правило происходят при исправлениях критических ошибок (hotfix) и это логично исправил на рабочем сайте продублируй на демку. Как правило если доработка улетает сразу в мастер ветку в большинстве случаев, дорабатываются, по этому приходится делать разные hotfix' ы относительно одного и того же функционала, и есть риск что сайт во время этих фиксов может работать не корректно. Поэтому делайте все в feature ветке, выкладывайте на демку и исправляйте замечания клиента, при 100% готовности делайте релиз и соответсвенно слияние с master.
2. автодеплой на сервера при пушах в master и develop, ну действительно это удобно.
3. релизы и версионность сайта. при релизах приходится делать версию, ну это нормально. если доработка повышайте минорную версию, если глобальный рефакторинг то мажорную, со временем вижу цифру и понимаю что сайт многое пережил.
ситуация: я проектирую задачу выделяю сущности: Продавец, Товар, Клиент, база уже существует и данные продавца хранятся например в таблице тех же клиентов но с типом продавец. какая то часть данных продавца например хранится в другой таблице доп.данные.
Во-первых. Разработка функционала усложняется тем что мне нужно орудовать не сущностными а с объектами базы данных и весь код будет завязан именно на логике работы с бд, начиная от названия таблиц которые могут не соответствовать наименованию разрабатываемого функционала заканчивая названия полей таблиц.
во-вторых смена хранилища, если я захочу получать товары не из бд а с сервиса, где свой формат хранения данных.
абстрагирование от бд позволяет делать гибче систему при дальнейших манипуляциях с источниками хранения данных.
Никаких сеттеров. Entity всегда дожна быть валидной - так то свойства загоняемые через конструкторы является обязательными и считается что без них модель не может существовать, а свойства изменяемые через сеттеры - необязательные. Если в модели 10-20 свойств, вы будете все через конструктор загонять?
Был случай, нашел фрилансера для разгрузки, он сделал пару задач, хорошо сделал. Через какое то время срочно нужна была его помощь но он видимо был занят другим проектом. Поэтому здесь не просто нужно собрать команду а важно ее удержать. А фрилансеры они такие сегодня здесь завтра там. Я думаю что нужна какая то система позволяющая организовывать работу фриланс групп (удавленников), позволяющая накапливать, прокачивать скиллы программистов, мотивируя работать именно в вашей группе с вашими проектами.
подождите а как же качество кода? есть проект, поставили задачу, фрилансер оценил, вы подтвердили, но в итоге он реализует таким способом что последующая поддержка код будет на нуле. Или допустим реализованный функционал начнет падать при высоких нагрузках кто будет его фиксить?
исключение должно быть при непредвиденной ситуации в системе, а получение категории либо получили либо нет - предвиденная, можно легко обработать, например вывести категории или если их нет то слово, нет категорий. Если вы все логику начнете шпиговать экзепшеннами то только все усложните.
