Кроме get/set - ничего )) В этом его прелесть: это абсолютно самодостаточная, атомарная единица проекта. Вся движуха с выборкой/сохранением в БД, валидацией и т.д. начинается на следующем уровене (моделей, репозиториев, сервисов, контроллеров и т.д.)
В такой ситуации вы можете таскать сущности по проектам, не заморачиваясь. Например, запилить backend на Yii2, а API - на Slim-е. Пример синтетический, но, надеюсь, понятный)
Сразу отмечу: такой уровень абстракции лучше применять на проектах, сложность которых уже выше среднего. На небольших это будет скорее избыточно, чем необходимо. Ну и уровень разработчиков, конечно, нужно брать в расчет - не все до конца и с пониманием относятся к DDD.
Речь ведь про единый репозиторий, верно?
На самом деле, конфликты иногда встречаются - на уровне шаблонов. То есть пока фронтэндщики gulp-ят css/js/спрайты - все норм. Но когда доходит до внесения изменений в шаблоны, то бывает, что оба разработчика должны править один и тот же файл. И да, пока они ресолвятся волевым решением тимлида )
Антон, В том-то и дело, что Laravel почему-то стал достаточно популярен в российских компаниях) Полтора года назад искал работу - пальму большинства уверенно держал Yii2, сейчас занялся поиском работы - они примерно вровень идут. И да - у Laravel-я оклад чуть выше)
AstonMartin, да, верно. В идеале "живой" тестировщик должен проверять только ту логику проекта, которая а) слишком трудозатратна, чтобы ее формализовать в виде теста(-ов) и б) по объективным причинам должна быть протестирована вручную
Все остальное - обкладывайте тестами. Конечно, важно найти золотую середину (чтобы время на написание тестов не превышало 30% от времени написания кода ) - как правило, в тесты уходит все фичи, указанные в ТЗ + найденные в ходе разработки баги. Насчет 30% времени - это примерно) Если изначально проект стартует в рамках TDD, то там все 70% будут )
Попробуйте завести ветку stage, куда будет выполняться периодический мердж (например, 2 раза в день) из dev-ветки. Можно на тимсити завести отдельно подпроект для этого, с шагами:
- найти последнюю успешную сбоку dev-ветки
- влить ее в stage
- уведомить тестировщика
Тестировщик получает уведомление, выполняет ручное тестирование. Все круто - вливаем в master
AstonMartin, подозреваю, что TravisCI удобнее для проектов, которые лежат на гитхабе. Я делал проекты на yii, которые тестились на тимсити - полет нормальный) Но у нас исходники были в приватном гитлабе
Попробуйте с простого
Включаете секундомер (на телефоне, например) и в течение 30сек просто смотрите за временем. Отвлеклись - заново. Раза 3-4 в день. Если с этим проблем нет - потихоньку увеличиваем время. Если есть - думаю, стоит проконсультироваться у специалистов - возможно, это уже не просто "не могу сосредоточиться"
Станислав: Может, тогда есть смысл смотреть в сторону sub-repository? Отдельно репозиторий с кодом, отдельно - с тестами. На продакш идет только "ядро", на тестовых/локальных - дополнительно выкачиваются тесты
Станислав: Это уже неправильная архитектура, которая жестко привязывается к конкретной среде ) Выделяйте такие блоки кода куда-то наружу, завязывайте их на конфиг-файлы.
Если проект ведет себя по-разному в различных environment-ах (что, в общем-то, нормально для более-менее серьезных проектов), то "смежный" код нужно выносить в отдельные модули, библиотеки и т.п.
Сергей: Совершенно верно. И есть некая переменная (из общего конфига), которая идентифицирует текущее окружение (dev, prod, local и т.д.). В зависимости от этой переменной вы подключаете разные конфиги (уже без суффикса EXAMPLE)
atamanenko: Поддерживаю вариант с фреймворками. Потратьте пару дней, пощупайте наиболее популярные :) "Подпиливать" фичи однозначно лучше на хорошем фундаменте, а не самописном велосипеде
оффтоп
А не слишком из пушки по воробьям - лендинг на Yii2? :) Имхо, если клиент захочет из лендинга сделать полноценный сайт - это уже отдельная задача со всеми вытекающими.
Юрий Кучеренко: не понял, что перезапишется? в каком основном файле? Вроде последовательность проста: отладка в не-min.js -> устранение ошибки -> минификация -> в продакшн
еще раз повторюсь: я не настаиваю на том, что нельзя сразу заниматься минификацией. Просто полезная привычка: сначала добиться основной функциональности, а потом уже доставать напильник. Автор просит привести аргументы - это и есть мой аргумент "против" минификации с самого начала.