Я прочитал несколько сообщений, где люди заявляли (не предлагали, не обсуждали, не предлагали), что PHP не должен использоваться для крупных проектов.
Будучи главным разработчиком PHP, я задаю два вопроса:
Я управляю небольшой командой разработчиков, и по собственному опыту мы знаем, что качество, организация, документация, комментирование и инкапсуляция – наш самый высокий приоритет. Мы можем разрабатывать отличные проекты, используя наши собственные рамки и подход, но, тем не менее, я не хочу инвестировать дальше, если я трачу свое время.
Мысли?
Я действительно ненавижу это, когда люди говорят, что PHP – ужасный язык, потому что вы можете написать код, который смешивает презентацию с логикой или позволяет разрешить SQL-инъекцию. Это вовсе не связано с языком, это разработчик.
PHP оказался очень масштабируемым: Wikipedia – один из самых больших и популярных сайтов в Интернете, и он запускает PHP. Достаточно сказано?
Существует множество инструментов / библиотек, которые дают вам основу для работы, что делает менее вероятным, что кто-то напишет плохой, менее ремонтируемый код: см. CakePHP, Symfony, PDO, Smarty и т. Д. И т. Д. И т. Д.
Он получил плохой рэп, потому что это язык, который имеет очень низкие барьеры для входа: он бесплатный, вы можете получить очень дешевый PHP-хостинг, документация лучшая , есть много учебников онлайн, плюс это делает много вещей очень просто (например: откройте URL-адрес и получите содержимое файла: file('http://www.google.com'); ). Это означает, что много новичков подняли его и сделали с ним очень изворотливые сайты, но это произойдет с любым языком, который вы выберете в качестве первого.
Работайте с твердой картой ORM (есть около 30 вопросов о SO, о которых лучше всего), и это будет относиться к вам хорошо.
Многие люди, которые говорят, что не используют его, действительно говорят, что не используют PHP 4. Это сводится к этому
вы можете написать хороший код на любом языке
а также
вы можете написать плохой код на любом языке
PHP может очень часто давать себе возможность запутаться в библиотеках кодов спагетти и сделать ваше приложение действительно просто серией скриптов (см. Moodle для хорошего примера …)
Я думаю, что большая часть «Не использовать PHP для больших вещей» исходит из того, что PHP взломан с оригинальной цели: язык шаблонов. Что я могу понять, но есть много проектов, которые доказывают, что вы можете это сделать (Drupal, mediawiki, Facebook).
Нет причин, по которым вы не можете использовать PHP для больших проектов. В конце концов, Facebook построен на PHP. Однако будут проблемы, но есть проблемы с любым крупным проектом.
Что делает PHP настолько распространенным, это низкий барьер для входа и дешевого хостинга. Он работает как расширение Apache, и вы можете просто начать кодирование. Если вы перейдете на другие корпоративные платформы, такие как .Net или Java, у них есть гораздо более высокий барьер для входа, но они также оснащены большой инфраструктурой, которая поможет вам создавать приложения, масштабируемые.
Например, абстракция базы данных в PHP является (imho) горькой. Это специфический поставщик. С MySQL люди склонны делать такие вещи, как:
function get_users($surname) { mysql_query("select * from users where surname = '$surname'"); ... }
что плохо по нескольким причинам:
mysql_escape_string() но вы будете удивлены, как часто люди этого не делают); а также Лично я предпочитаю mysqli по всем вышеперечисленным причинам, но у него есть свои проблемы: а именно, что использование полей LONGTEXT приводит к сбою mysql и выполняется с по крайней мере с 2005 года, при этом все еще нет исправления (да, я и некоторые другие подняли ошибку).
Сравните это с Java (с которым я более знаком), а JPA или Ibatis – это значительно лучшие решения ORM с более высокими затратами на запуск, но они помогут вам в масштабах предприятия.
Поэтому вам не запрещено делать большие проекты на PHP. Это просто сложнее в том, что вам приходится все больше работать самостоятельно, чтобы воспроизвести то, что вам предлагают другие платформы.
При этом PHP + memcached / APC + beanstalkd проходит долгий путь.
О, это другая проблема: PHP не поддерживает фоновую обработку или потоки. Для этого вам нужно что-то еще (или автономные скрипты). Если вы используете что-то еще, почему бы и не использовать это для веб-материалов (например, Java, Ruby, .Net и т. Д.)?
Для меня худший PHP-грех – это сочетание презентации с бизнес-логикой. Дело не в том, что вы не можете написать это лучше, но это вас не поощряет, и, если что-нибудь, это вас не побуждает.
Большое количество уязвимостей безопасности также связано с PHP-сайтами. Я не могу доказать, что это непропорционально (в конце концов, многие сайты написаны на PHP), но я подозреваю, что это так. Если я прав, то, поскольку уязвимости безопасности являются классом ошибок, я подозреваю, что PHP-сайты в целом также более сложны.
(Я не думаю, что, указывая на несколько крупных сайтов и говоря, что им удалось это сделать на PHP, это, кстати, любой аргумент против этого. Это немного похоже на то, что сигареты не вызывают рак, потому что ваш сосед и дожил до 100.)
Проверьте этот похожий вопрос – может ли PHP обрабатывать сайты уровня предприятия, а также Java
Recapping – Facebook, Wikipedia, Yahoo.com, Digg, Flickr и многие другие гигантские сайты работают на PHP. Если вы когда-нибудь приблизились к тому, чтобы сделать что-то такое, вы все равно можете быть уверены, что можете попасть туда с PHP.
Насколько поддерживаемые, расширяемые, надежные, безопасные и эффективные приложения будут полностью соответствовать вашим требованиям и являются агностиками языка. В пользу PHP, однако, он имеет очень удобные инструменты для создания веб-приложений.
Для меня, говоря о больших или даже огромных проектах, он (в первую очередь) сводится к одному слову: зависимости .
Проблема с языком сценариев подобна во всем мире: наибольшее преимущество – это самый большой недостаток в то же время.
Наибольшее преимущество – свободный и быстрый код. Просто напишите сценарий, и он будет служить сервером. Не требуется многословия, просто код.
Наибольшим недостатком является, в некотором смысле, проверить, не вызывает ли этот сценарий другие скрипты. Или лучше: измените старый сценарий, на который другие полагаются. Вы уверены, что все зависимости работают по вашему желанию?
Это неверно для «нормальной» генерации веб-страниц, что бы ни означало здесь. Но у нас есть продукт, основанный на некоторых 500k строках исходного кода, с настройками для клиентов, состоящими из дополнительных 100k строк кода. И я очень рад, что компилятор проверяет все зависимости и предупреждает / делает ошибки на случай, если я сделал что-то неправильно (например, говоря на низком уровне здесь, ошибочно указав вызов переменной или метода).
Я думаю, что это и тот факт, что другие языки предоставляют более простые в использовании «предпринимательные» функции по своей природе (например, серверы приложений для «банковских обычаев») сводят на нет то, почему многие не видят PHP в больших (или лучше: огромных) проекты.
Наша компания управляет несколькими крупными веб-сайтами с использованием PHP и не имеет проблем, связанных с языком.
Все это хорошие ответы.
Я был новичком. Я только кодировал 5 лет, но я напрямую поддерживаю и управляю 85 небольшими крупными веб-сайтами, и я скажу вам, что, возможность получить иск, связавшись с веб-сайтом в течение дня, внесет большой вклад в ваше желание учиться как и сделать лучший код.
Приятно слышать, как разработчики делятся своими мыслями по этому вопросу. Я не думаю, что PHP является лучшим, но кажется, что мои инвестиции в «лучшие практики» хорошо обслуживаются.
Всем спасибо!
Есть кое-что о построении языка PHP, который недостаточно хорош для меня. Например, имя функции. Непревзойденная практика использует несколько способов назвать функцию на одном языке. Смесь между подчеркиваниями (имя_функции), слова склеиваются (имя функции) и т. Д. Я имею в виду, что это действительно беспорядок. Слишком много функций, которые очень похожи или делают одни и те же вещи, но их имена настолько запутывают. Это не характерно для хорошего языка программирования.
В больших развертываниях язык должен быть достаточно простым и специфичным для записи. Что-то, что PHP опускает, как объявление переменных типов, становится очень трудно понять и разобраться с ним позже.
Другим моментом является постоянное добавление функций и отмена некоторых других. Он предполагает, что добавление ООП на PHP 5 облегчит работу программистов, но как насчет соображений обратной совместимости?
Основная причина, по которой этот язык программирования похож на него, объясняется его происхождением: личной домашней страницей. Он не был предназначен для крупных развертываний.
Я знаю, что мы прилагаем большие усилия, чтобы сделать этот язык языком корпоративного уровня, и лично я жду достаточно хорошего языка программирования на стороне сервера с открытым исходным кодом; но до сегодняшнего дня он будет запускать много воды под мостом.