Зависит от многих параметров, банально - на сколько закрыт весь тех.долг, и на сколько есть свободное время.
Если техдолга нет (тесты написаты, документация написана, костылей нет, CI/CD настроен) и есть время - можно заморочиться с отдельным хранилищем для логов. Если же есть техдолг - я бы занялся лучше им, а логи можно вынести и потом, когда, например, база будет не справляться от нагрузки. Но тут от самой нагрузки зависит, если у вас 5 пользователей в сутки - это через 10 лет может случиться, или не случиться вовсе.
Классическая ситуация, когда компании нужен милд, но она не хочет платить соответствующую зарплату, а находит джуна, на которого сваливает задачи милда.
Первое, что нужно - не винить себя. Работайте спокойно, делайте что в ваших силах и все. По поводу сроков - есть компании, у которых всегда срочно, и всегда сроки горят - не принимайте близко к сердцу, это просто такой стиль у руководства.
Если на текущем месте работы есть пространство для развития - развивайтесь. Рекомендовать бросать компанию я бы не стал, так как не факт, что вы с текущими знаниями и опытом найдете что-то лучше. Давят со сроками практически везде - нужно просто выработать иммунитет к такому психологическому давлению.
Tokenchik, в теории да, юнит тест не должен вообще завязываться на другие классы. С другой стороны, с точки зрения практики, когда тестом покрывается ~50% кода - то хорошо бы, для начала, просто доводить этот показатель до 80-90%, плюс не лениться думать над плохими кейсами, которые сломают код.
Вообще нужно понимать несколько уровней идеализма в тестах (по моей практике):
1. Тестов нет вообще
2. Есть немного тестов на самый важный функционал
<= Где-то здесь команды начинают внедрять CI/CD =>
3. Тестов больше, но из-за того, что кто-то в команде пишет больше тестов, кто-то меньше - покрыто примерно половина кода
4. Добавляется второй слой тестов, например, помимо юнит тестов, пишут еще приемочные тесты
5. Команда, пусть и не пишет 100% покрытия кода тестами, но старается покрывать тестами все бизнес-кейсы
6. Аналогичного покрытия тестами добиваются и на другом слое тестов (например, на приемочных)
<= Где-то здесь некоторые команды начинают писать отдельные тесты на фронт =>
7. Стремление к 100% покрытию кода юнит-тестами
8. Добавление мутационного тестирования
9. Совсем-совсем идеальные юнит-тесты, где тестируемый класс не завязан на другие классы
При этом нигде в рабочих проектах, я пунктов 7-8-9 не встречал вообще.
Подводя итог: если на проекте нет тестов вообще, а потом вы решаете их писать по какому-то идеальному варианту из пункта 9 - расслабьтесь, и не пытайтесь прыгать выше головы. Промежуточных пунктов по улучшению тестов - вагон.
Локально на сервере сайт открывается? Если нет - я бы копал в сторону настройки nginx конфига (кстати, неплохо было бы его привести) + просмотр логов nginx по адресу /var/log/nginx/
Догадался сам, написал ответ, но раз вы тоже написали - удалил свой ответ и выбрал ваш решением.
Из удаленного сообщения:
Хотя, конечно, странно. Почему в SQL-запросе всегда пишется ON, а в QueryBuilder нужно писать WITH. Из-за синтаксиса DQL? Если кто-то разбирается - напишите.
Но вообще по логике, эти сущности должны быть связаны. Во-первых, инфа дублируется зазря, во-вторых, нарушить консистентность базы проще простого.
Это все верно, но конкретно эти сущности (не из примера в вопросе - это для теста, разумеется, а в рабочем проекте, где такая задача возникла) проектировал не я, в планы зарефакторить поставил пункт, но банальный запрос хочется написать без такого рефакторинга, тем более, нужно будет брать дапм с базы и проверять, "ляжет" ли на существующие данные внешний ключ - данные там могут быть уже "битые"
На компьютер установлен трекер, отслеживающий твою работа над проектом. Желательно закрывать 8 часов. Каждые 5 минут скриншот твоего рабочего стола отправляется работодателю.
Зачем работать в таких компаниях? Других предложений нет?
Фриланс для новичка - это путь мелких правок на вордпрессе и прочем мусоре, без git-а и прочих нормальных инструментов разработки.
Лет за 5, конечно, можно кое-какой опыт получить, но лучше начать делать свой проект и делать его на современных подходах: docker + современный фреймворк + git + свой GitLab сделать через gitlab.com (бесплатного периода хватит) + все это на github и уже с таким проектом ходить по собеседованиям.
Проблема решается (уже решилась) одной строчкой, заменой EntityManager->clear() на Doctrine->resetManager(), но интересно, в чем там разница внутри.