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