Что случилось с использованием платформы, которая имеет много зависимостей? [закрытый]
Обычно из-за «плохого программирования» и возможности ошибок сейчас или позже.
- Если это ошибка, сначала сделайте правильное присвоение переменной: $ varname = 0;
- Если она действительно определяется только иногда, проверьте ее:
if (isset($varname)), прежде чем использовать ее - Если это потому, что вы написали это неправильно, просто исправьте это
- Может быть, даже поворот предупреждений в вас Настройки PHP
4 ответа
Когда есть зависимости версий между компонентами, вы можете оказаться в нерабочей ситуации, если вам придется обновить один компонент (скажем, из соображений безопасности) до совместимой версии доступен зависимый компонент.
Это предполагает, что вы в первую очередь можете перейти в рабочее состояние. Может случиться так, что если вы попытаетесь использовать текущие версии всех зависимостей, вы обнаружите, что они не подыгрывают.
Чем больше количество зависимостей, тем выше риск.
Rails не работает. без этой проблемы. С каждым новым выпуском Ruby возникает борьба за инструкции по обновлению, например, по созданию драйверов баз данных.
Честно говоря, эта проблема со временем стала «лучше», хотя и с неровностями на дороге.
В этом нет ничего особенного. Преимущество Catalyst в том, что его части могут использоваться людьми, не использующими весь Catalyst. Это означает, что больше внимания уделяется критическим частям и исправляет ошибки в них.
Самая большая жалоба, о которой я слышу, - это то, что раздражает смотреть, как все эти сообщения проходят в оболочке CPAN при установке Catalyst. Решение состоит в том, чтобы воспользоваться преимуществами диспетчера пакетов вашей ОС, когда вы начнете. В Debian apt-get install libcatalyst-perl занимает 15 секунд для установки на машине, на которой не установлены другие модули Perl. 15 секунд. (Простая установка CPAN тоже не сложна, но я думаю, что стандартная оболочка CPAN задает вам много глупых вопросов, и это отпугивает новичков.)
Не беспокойтесь о зависимостях,
По моему личному опыту, чем больше у вас зависимостей, тем больше версий вам нужно отслеживать, а это может привести к кошмарным ситуациям. В частности, обновление одной зависимости (например, из-за ошибки, которую вы хотите исправить) может вызвать проблемы совместимости с другими зависимостями. Например, у меня лично была ситуация, когда gcc 4.0.3 работал с foo, но не с bar (зависимость от foo), а gcc 4.0.5 работал с bar, но не с foo. К счастью, 4.0.2 сработала.
Кроме того, больше зависимостей, как правило, указывают на продукты «монстры Франкенштейна», состоящие из частей, которые не были разработаны заранее для совместной игры. Хорошо интегрированный фреймворк предназначен для приятной и последовательной игры. Это, конечно, можно исправить, правильно обернув различия.
Это тема, о которой я видел сообщения раньше. Я собирался написать об этом статью и, наконец, сделал это.
Это здесь: Ложь о независимости
Я призываю вас прочитать это. Однако суть проста. Вопрос неправильный. Это не «Вы используете приложение или фреймворк с большим количеством зависимостей или тот, у которого их нет?»
Это: «Используете ли вы приложение или фреймворк, который имеет множество внешних зависимостей, или тот, который пытается делать все это внутренне?»
И следующий вопрос: «Действительно ли вы верите, что человек или люди, пишущие эту структуру, понимают все нюансы каждой мельчайшей детали каждой задачи, которая должна быть выполнена для обработки веб-запроса?»