Обновили сначала версию PHP до 7.1 и только потом стали внедрять компоненты Symfony. В старом коде и композера и неймспейсов не было. Все это внедряли на подготовительном этапе. В статье об этом написано немного.
Согласен. Можем взять прекрасное русское слово "устаревший", чтобы было меньше непонимания. Устаревший код может быть устаревшим совершенно по-разным причинам. По времени, по технологиям, по подходам и т.д. При этом наверное главный вопрос, на который надо ответить, это - создает ли устаревший код проблемы для бизнеса. Если не создает, то фиг с ним, что он устаревший, пусть такой и будет. Ну а если создает, тогда можно попробовать действовать, как описано в статье.
Конечно, все зависит от конкретной ситуации, вы правы. Охватить все возможные варианты развития событий в рамках статьи просто невозможно. Я попытался описать самые общие, типичные случаи.
Эмпирические данные. Понятно, что это не 100% правило, но обычно так и выходит плюс-минус. Понятно, что с одной стороны уже есть опыт команды на написание первой версии, но не факт, что именно эта команда будет писать новую версию. И бизнес почти всегда накидывает новые требования.
В общем, конечно, оценка очень приблизительная и в первую очередь дана для ориентира менеджерам, а не разработчикам.
Интересная у вас мысль. Думаю, описанная ситуация не редкость, но точно и не единственно возможная. Я больше за то, чтобы рассматривать каждую ситуацию индивидуально, чем делать общие выводы, что менеджер/бизнесмен плохой или недальновидный, а технарь молодец. К своему сожалению, я видел немало проектов, где именно низкая техническая экспертиза команды приводила продукт к коллапсу.
Спасибо за совет, но кажется, что он мне не поможет. Я посмотрел на конфигурацию докера, которая у меня медленно работает на Windows. В docker-compose.yml используется именно второй вариант из вашего примера
Ну в общем то да.
А как работать то без shared volumes? Docker-sync или еще что-то? Возможно, но к моменту, когда я до него дошел, у меня накопилась определенная усталость от разных костылей и проблем на Windows, которых у коллег с Linux не было.
Друзья, я думаю, у всех разные проекты, разные задачи. Кому-то подходит одно, другому другое. Я тоже очень долго сидел на Windows, о чем написано в статье. Потом это стало крайне неудобно, в связи с ростом проектов и ростом стеков технологий, а также работой всей остальной команды под Linux. Пришлось искать решение, на что я потратил очень немало времени. Возможно, кто-то другой сбережет свое время благодаря этой статьей.
Я поделился своим опытом, может он кому-то окажется полезным. Может кто-то найдет для себя приемлемое решение из комментариев. Это тоже хорошо. Поэтому всем, кто поделился своим рецептом, большое спасибо!
Второй — это dual boot? По моему это очень неудобно. По крайней мере для меня, т.к. мне часто приходится переключаться между задачами.
С другой стороны, если вам нужно чтобы ничего не отвлекало от работы, такой подход может даже оказаться предпочтительнее.
Все верно, у нормального программиста на рабочем месте должен быть линукс. Об этом я написал в самом начале статьи. Но я не совсем программист, у меня кроме разработки еще куча побочных задач, которые занимают даже больше рабочего времени и требуют Windows приложений.
Ну и dual boot в таких условиях это дико неудобно.
А вы статью то прочитали, или сразу комментировать пошли? Докер на винде работает медленно. Обходные пути вроде как есть, но выглядит это как раз, как костыли.
Да, и так тоже очень часто бывает.
Обновили сначала версию PHP до 7.1 и только потом стали внедрять компоненты Symfony. В старом коде и композера и неймспейсов не было. Все это внедряли на подготовительном этапе. В статье об этом написано немного.
Согласен. Можем взять прекрасное русское слово "устаревший", чтобы было меньше непонимания.
Устаревший код может быть устаревшим совершенно по-разным причинам. По времени, по технологиям, по подходам и т.д. При этом наверное главный вопрос, на который надо ответить, это - создает ли устаревший код проблемы для бизнеса. Если не создает, то фиг с ним, что он устаревший, пусть такой и будет. Ну а если создает, тогда можно попробовать действовать, как описано в статье.
Отлично, что наши подходы совпали. А вы с какого фреймворка съезжали и почему?
Конечно, все зависит от конкретной ситуации, вы правы. Охватить все возможные варианты развития событий в рамках статьи просто невозможно. Я попытался описать самые общие, типичные случаи.
Эмпирические данные. Понятно, что это не 100% правило, но обычно так и выходит плюс-минус. Понятно, что с одной стороны уже есть опыт команды на написание первой версии, но не факт, что именно эта команда будет писать новую версию. И бизнес почти всегда накидывает новые требования.
В общем, конечно, оценка очень приблизительная и в первую очередь дана для ориентира менеджерам, а не разработчикам.
Интересная у вас мысль. Думаю, описанная ситуация не редкость, но точно и не единственно возможная. Я больше за то, чтобы рассматривать каждую ситуацию индивидуально, чем делать общие выводы, что менеджер/бизнесмен плохой или недальновидный, а технарь молодец. К своему сожалению, я видел немало проектов, где именно низкая техническая экспертиза команды приводила продукт к коллапсу.
И тем не менее, все очень медленно.
А как работать то без shared volumes? Docker-sync или еще что-то? Возможно, но к моменту, когда я до него дошел, у меня накопилась определенная усталость от разных костылей и проблем на Windows, которых у коллег с Linux не было.
Я поделился своим опытом, может он кому-то окажется полезным. Может кто-то найдет для себя приемлемое решение из комментариев. Это тоже хорошо. Поэтому всем, кто поделился своим рецептом, большое спасибо!
С другой стороны, если вам нужно чтобы ничего не отвлекало от работы, такой подход может даже оказаться предпочтительнее.
Ну и dual boot в таких условиях это дико неудобно.