Нет PHP для больших проектов? Почему бы и нет?

Question

Я прочитал несколько постов, в которых люди заявляли (не предлагали, не обсуждали, не предлагали), что PHP не следует использовать для больших проектов.

Будучи главным разработчиком PHP, я задаю два вопроса:

1. Что определяет «большой проект»?
2. Почему бы и нет? Каковы подводные камни использования PHP

У меня небольшая команда разработчиков, и по своему опыту я знаю, что качество строительства, организация, документация, комментирование и инкапсуляция являются нашим высшим приоритетом. Мы можем разрабатывать отличные проекты, используя нашу собственную структуру и подход, но, тем не менее, я не хочу инвестировать дальше, если трачу свое время.

Мысли

Answer 1

Мне очень не нравится, когда люди прямо говорят, что PHP - ужасный язык, потому что вы можете писать код, который смешивает представление с логикой, или что он позволяет вам делать инъекции SQL. Это не имеет ничего общего с языком, это разработчик.

PHP доказал свою высокую масштабируемость: Википедия является одним из крупнейших и самых популярных сайтов в Интернете, и на нем работает PHP. Достаточно сказано?

Существует множество инструментов / библиотек, которые дают вам основу для работы, снижая вероятность того, что кто-то напишет плохой, менее обслуживаемый код: см. CakePHP, Symfony, PDO, Smarty и т. Д. И т. Д. И т. Д. И т. Д.

Он получил плохую репутацию, потому что это язык с очень низкими барьерами для входа: он бесплатный, вы можете получить очень дешевый хостинг на PHP, документация лучшая из всех , в Интернете есть множество учебных пособий, плюс очень легко многое (например: открыть URL-адрес и получить содержимое файла: file('http://www.google.com');). Это означает, что многие новички подобрали его и сделали с ним множество очень хитрых сайтов, но это произойдет с тем языком, который вы выберете в качестве первого.

Работайте с солидной средой ORM (около 30 вопросов о SO, которая является лучшей), и она будет относиться к вам хорошо.

Answer 2

Многие люди, которые говорят, что не используют его, действительно говорят, что не используют PHP 4. Это сводится к этому

Вы можете написать хороший код на любом языке

и

вы можете написать плохой код на любом языке

PHP может очень часто превращаться в запутанные библиотеки спагетти-кода и превращать ваше «приложение» просто в серию скриптов (хороший пример этого см. В Moodle ...)

Я думаю, что большая часть «Не используйте PHP для больших вещей» происходит из-за того, что PHP взломан из его первоначальной цели: языка шаблонов. Это я могу понять, но есть много проектов, которые доказывают, что вы можете это сделать (Drupal, mediawiki, Facebook).

Answer 3

Нет причин, по которым вы не можете использовать 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(), но вы будете удивлены, как часто люди этого не делают); и
• Кодирование довольно легко разрешить атакам с использованием SQL-инъекций.

Лично я предпочитаю mysqli по всем вышеперечисленным причинам, но у него есть свои проблемы: а именно, что использование полей LONGTEXT приводит к сбою mysql и по крайней мере с 2005 года все еще не исправлено (да, я и некоторые другие пользователи подняли ошибку). 1019 *

Сравните это с Java (с которым я более знаком), и JPA или Ibatis - намного лучшие ORM-решения с более высокими начальными затратами, но они помогут вам в масштабе предприятия.

Так что вам не запрещено делать большие проекты на PHP. Просто сложнее в том, что вам приходится все больше и больше работать самостоятельно, чтобы копировать то, что предоставляют вам другие платформы.

При этом PHP + memcached / APC + beanstalkd проходит долгий путь.

О, это другая проблема: PHP на самом деле не поддерживает фоновую обработку или многопоточность. Вам нужно что-то еще для этого (или автономные скрипты). Если вы используете что-то другое, почему бы не использовать это для веб-приложений (например, Java, Ruby, .Net и т. Д.)?

Answer 4

Поскольку вопрос , с которым я связался , был удален, я добавлю его сюда:

Вопрос

---

Я сделал ненормативную оценку в другой ветке вопросов, назвав PHP ужасным языком, и за него проголосовали как за сумасшедшего. Видимо, здесь много людей, которые любят PHP.

Так что мне действительно любопытно. Что мне не хватает? Что делает PHP хорошим языком?

Вот мои причины неприязни к нему:

• PHP имеет несовместимые имена встроенных и библиотечных функций. Предсказуемые шаблоны именования важны в любом дизайне.

• PHP имеет непоследовательное упорядочение параметров встроенных функций, например, array_map против array_filter, который раздражает в простых случаях и вызывает всевозможные неожиданные поведения или хуже.

• Разработчики PHP постоянно отказываются от встроенных функций и функций более низкого уровня. Хороший пример - когда они устарели при передаче по ссылке для функций. Это создало кошмар для тех, кто делает, скажем, обратные вызовы функций.

• Отсутствие рассмотрения в редизайне. Вышеуказанный износ исключил возможность во многих случаях предоставлять значения ключевых слов по умолчанию для функций. Они исправили это в PHP 5, но устарели при переходе по ссылке в PHP 4!

• Плохое выполнение пространств имен (раньше вообще не было пространств имен). Теперь, когда пространства имен существуют, что мы используем в качестве символа разыменования? Backslash! Символ, универсально используемый для выхода, даже в PHP!

• Чрезмерно широкое неявное преобразование типов приводит к ошибкам. У меня нет проблем с неявными преобразованиями, скажем, с плавающей точкой в ​​целое число или обратно. Но PHP (последний раз я проверял) с радостью попытается магически преобразовать массив в целое число.

• Плохая производительность рекурсии. Рекурсия является принципиально важным инструментом для написания на любом языке; это может сделать сложные алгоритмы намного проще. Плохая поддержка непростительна.

• Функции не чувствительны к регистру. Я понятия не имею, что они думают об этом. Язык программирования - это способ указать поведение компьютера и читателя кода без двусмысленности. Нечувствительность к регистру вносит много неясностей.

• PHP поощряет (практически требует) соединение обработки с представлением. Да, вы можете написать PHP, который этого не делает, но на самом деле проще писать код некорректно (с точки зрения дизайна звука).

• Производительность PHP без кеширования ужасна. Кто-нибудь продает коммерческий продукт для кэширования на PHP? О, смотри, дизайнеры PHP делают.

Хуже всего то, что PHP убеждает людей в том, что проектировать веб-приложения легко. И это действительно облегчает большую часть вовлеченных усилий. Но дело в том, что разработка безопасного и эффективного веб-приложения - очень сложная задача.

Убедив так много людей заняться программированием, PHP научил целую подгруппу программистов плохим привычкам и плохому дизайну. Это дает им доступ к возможностям, которые им не хватает понимания для безопасного использования. Это привело к тому, что репутация PHP небезопасна.

(Однако я с готовностью признаю, что PHP не более или менее безопасен, чем любой другой язык веб-программирования.)

Что мне не хватает в PHP? Я вижу органически выращенный, плохо управляемый беспорядок языка, который порождает бедных программистов.

Так убедите меня в обратном!

---

Лучший ответ

---

Я попытаюсь ответить на каждое из ваших пунктов пули

PHP имеет неправильное именование встроенные и библиотечные функции. Предсказуемые шаблоны именования важно в любом дизайне.

Я люблю и ненавижу эту тему. Потому что по своей сути эта проблема правильная. Почему некоторые функции из двух слов разделены подчеркиванием, а некоторые нет? Почему параметры иглы и стога сена меняются местами в сигнатуре аргумента? Это нелепо. Но в конце дня ... это действительно имеет значение? Моя IDE с intellisense и php.net всего в одном клике от браузера, это просто не такая уж большая проблема. Это негатив против PHP как языка? Да. Это мешает моей способности быть эффективным программистом? Нет.

PHP разработчики постоянно отказаться от встроенных функций и функциональность более низкого уровня. Хороший пример, когда они устарели передача по ссылке для функций. это создал кошмар для тех, кто делает, скажем, функции обратного вызова.

Лично я думаю, что это не очень хороший момент. Устаревание необходимо для развития языка, особенно такого, у которого столько же круфт, сколько у PHP. В PHP много проблем с «облегчением быть плохим программистом *», но в то же время у группы PHP также возникают проблемы, когда они пытаются удалить глупые конструкции из языка, такие как передача во время вызова. -ссылка. Исключение передачи по времени звонка было одним из лучших ходов, которые они когда-либо делали. Для начинающего разработчика не было более простого способа выстрелить себе в ногу, чем с помощью этой «функции».

Отсутствие рассмотрения в редизайне. Вышеуказанный износ устранил способность во многих случаях обеспечивать значения ключевых слов по умолчанию для функций. Они исправили это в PHP 5, но они устарела передача по ссылке в PHP 4!

Я не думаю, что это вообще отсутствие внимания вообще, я думаю, что вы были просто ужалены этим конкретным изменением и у вас остался кислый вкус во рту. Языковые изменения часто известны месяцами, если не годами раньше времени. Для перехода с 4 на 5 было предоставлено руководство по миграции, а различия версий задокументированы в руководстве. Передача по ссылке во время разговора была ужасной «особенностью» и не дает разработчику никакой выразительной силы, которую они не могут получить другими способами. Я рад, что это ушло (наряду с другими дерьмом, как магические цитаты)

Плохое исполнение пространств имен (раньше не было пространств имен вообще). Сейчас что пространства имен существуют, что мы используем как разыменование персонажа? Backslash! Используемый персонаж универсально для экранирования, даже в PHP!

У меня смешанные чувства по этому поводу. Часть меня думает: «кого это волнует, экранирование персонажа в любом случае не имеет значения вне строки», а часть меня думает, что «они наверняка могли бы использовать что-то лучше». Но могли ли они? Я не знаю, я не разработчик для парсера Zend. Это огромный упущение, что до 5.3 PHP никогда не имел пространств имен вообще? Да, абсолютно.

Чрезмерно широкое неявное преобразование типов приводит к ошибкам. У меня нет проблем с неявные преобразования, скажем, с плавающей точкой целое число или обратно Но PHP (последний я проверил) с удовольствием попытаюсь волшебным образом преобразовать массив в целое число.

Я думаю, что можно не согласиться с тем, как PHP это делает, но не согласен с тем, что это делает язык "плохим". Но спросите меня, насколько я хочу сидеть в этой теме и спорить о слабой и сильной типизации. (P.S. Я не знаю, вообще ) Для записи: PHP выдаст ошибку уровня E_WARNING, когда тип аргумента имеет значение и не может быть решен путем принуждения.

Плохая производительность рекурсии. Рекурсия является принципиально важным инструментом для писать на любом языке; это может сделать сложные алгоритмы намного проще. Бедные поддержка непростительна.

PHP - это DSL для Интернета. Я делаю это полный рабочий день в течение 8 лет и, возможно, использовал рекурсию 4 или 5 раз, обычно для какого-то раздражающего каталога или обхода XML. Это просто не тот шаблон, который часто требуется для веб-разработки. Я не извиняюсь за медленную производительность, но это академическая проблема гораздо больше, чем проблема производства. Если вам нужна действительно мощная рекурсивная производительность, PHP уже не тот язык для вас.

Функции не чувствительны к регистру. я имею понятия не имею, о чем они думают этот. Язык программирования является способ указать поведение как компьютер и считыватель кода без двусмысленности. Нечувствительность к регистру вводит много двусмысленности.

Я полностью согласен с этим.

PHP поощряет (практически требует) соединение обработки с презентация. Да, вы можете написать PHP это не так, но это на самом деле проще написать код в неверном (с точки зрения звукового дизайна) образом.

* Хммм, эта тема звучит отчаянно знакомой ...

А если серьезно, я нахожу замечательным то, что люди будут жаловаться на язык, который на 100% позволит вам реализовать любую желаемую систему вывода (об этом говорят просто объем и стиль PHP-шаблонизаторов) - ИЛИ - пропустить все это накладные расходы и просто вывод напрямую. Это вовсе не делает PHP плохим. Это часть того, что делает PHP хорошим.

Производительность PHP безнадежна без кэширование. Кто-нибудь продает рекламу? кеширующий продукт для PHP? О, смотри, дизайнеры PHP делают.

Вы имеете в виду кэширование байт-кода (например, ускоритель) или кэширование вывода?

Если первое, то я действительно не знаю, насколько мне небезразлична эта тема. Ускорители бесплатны и просты в управлении. Мы могли бы поспорить о том, почему это не является частью языка, но, в конце концов, я не думаю, что это имеет большое значение.

Если вы говорите о кешировании вывода, тогда я не знаю, что вам сказать. ЛЮБОЙ веб-проект со значительным трафиком нуждается в кэшировании (например, начальный подкаст №27). Это вообще не проблема PHP .

В целом, я думаю, что вы считаете PHP "плохим" языком в очень академической манере. И в вашем предыдущем посте вы, вероятно, были отвергнуты такими людьми, как я, которые используют PHP, чтобы «добиться цели».

---

Второй по рейтингу ответ

---

Все ваши критические замечания (и некоторые другие) действительны. Вы можете и даже должны ненавидеть PHP.

Но опять же, у него есть некоторые преимущества:

• Повсеместный
• Быстро (особенно с использованием кэшей кода операции)
• Огромное сообщество (и отличная документация)
• Работает

Наконец, вы можете преодолеть многие, если не все недостатки, написав хороший код, который вы написали бы на любом другом языке. Вы можете написать надежный, безопасный и хорошо пахнущий код на PHP, который во много раз будет работать быстрее и будет легче размещать и масштабировать, чем многие альтернативы.

---

Третий лучший ответ

---

Что мне не хватает в PHP? Я вижу органически выращенный, плохо управляемый беспорядок языка это порождает бедных программистов.

Simple. Тот факт, что бедные программисты очень защищают свой язык. ;) PHP легко выучить, намного проще, чем альтернативы, и как только вы выучите его, это не совсем очевидно: 1) что не так с PHP, 2) как лучше альтернативы, и 3) как переключиться и изучить, одна из альтернатив.

И, возможно, тот факт, что у людей есть альтернативы? ASP? Это имеет множество проблем само по себе, от неспособности работать на большинстве веб-серверов (Apache), до некоторых нелепых и слишком сложных вариантов дизайна (webforms? Viewstate? AJAX, где ваши асинхронные "запросы перехватываются и запускаются последовательно * * 1 169?)Рубин на рельсах? Ну, возможно, кроме того, сколько веб-серверов поддерживают это снова? Это не совсем легко доступны в данный момент. И это медленно. Так что, возможно, «сила» PHP в том, что хорошей альтернативы не существует. По крайней мере, поэтому я держусь подальше от всех веб-программ, когда это возможно. PHP отстой, и я не слишком заинтересован ни в одной из альтернатив.

У PHP так много фундаментальных проблем, что это даже не смешно. От отсутствия поддержки юникода, до многих неявных преобразований типов, которые часто приводят к неожиданным дырам в безопасности, до полного смешивания представления и ... всего остального, или к модулю базы данных по умолчанию, который не используется (последний раз я проверял) параметризованные запросы. Мы говорим о языке, созданном для двух вещей: доступа к базе данных и генерации HTML, и который ужасен в обоих случаях.

Это просто неприятный беспорядок, язык, разработанный людьми, которые не имеют квалификации или не способны разработать язык. ;)

---

Answer 5

Для меня худшим грехом PHP является соединение презентации с бизнес-логикой. Это не значит, что вы не можете написать это лучше, но это не поощряет вас, и, во всяком случае, побуждает вас этого не делать.

Большое количество уязвимостей безопасности также связано с сайтами PHP. Я не могу доказать, что это непропорционально (ведь многие сайты написаны на PHP), но я подозреваю, что это так. Если я прав, то, поскольку уязвимости в области безопасности представляют собой класс ошибок, я подозреваю, что сайты PHP, как правило, также более подвержены ошибкам.

(Я не думаю, что указание на несколько крупных сайтов и утверждение, что им удалось сделать это на PHP, кстати, является каким-то аргументом против этого. Это похоже на то, что сигареты не вызывают рак, потому что ваш следующий Дверь соседа курила и дожила до 100 лет.)

Answer 6

Для меня, говоря о больших или даже огромных проектах, это (прежде всего) сводится к одному слову: Зависимости .

Проблема с языком сценариев, как и во всем мире: самое большое преимущество - это самый большой недостаток в то же время.

Самым большим преимуществом является бесплатный и быстрый код. Просто напишите сценарий, и он будет служить своей цели. Не нужно многословия, просто код.

Самым большим недостатком является, в некотором смысле, проверка, не мешает ли этот сценарий другим сценариям. Или лучше: измените старый скрипт, на который полагаются другие. Вы уверены, что все зависимости работают так, как вы хотели?

Это не относится к "нормальному" генерированию веб-страниц, что бы здесь ни означало нормальное. Но у нас есть продукт, основанный на 500 тыс. Строк исходного кода, с настройками для клиентов, которые также содержат дополнительные 100 тыс. Строк кода. И я смертельно рад, что компилятор проверяет все зависимости и предупреждает / выдает мне ошибки в случае, если я что-то сделал не так (например, произнесение нижнего уровня здесь, неправильный ввод переменной или вызов метода).

Я думаю, что тот факт, что другие языки по своей природе предоставляют более простые в использовании «предприимчивые» функции (т. Е. Серверы приложений для «банковских операций»), сводит на нет то, почему многие не видят PHP в целом (или лучше). : огромные) проекты.

Answer 7

Проверьте этот похожий вопрос - Может ли PHP обрабатывать сайты уровня предприятия, а также Java

Повторная съемка - Facebook, Wikipedia, Yahoo.com, Digg, Flickr и многие другие гигантские сайты работают на PHP. Если вы когда-нибудь приблизились к созданию чего-то такого калибра, вы все равно можете быть уверены, что сможете достичь этого с помощью PHP.

Насколько обслуживаемыми, расширяемыми, надежными, безопасными и эффективными будут ваши приложения, зависит только от вас и не зависит от языка. Хотя в пользу PHP он имеет очень удобные инструменты для создания веб-приложений.

Answer 8

Есть что-то в конструкции языка PHP, что для меня недостаточно. Например, имя функции. Не рекомендуется использовать несколько способов именования функций на одном языке. Смесь между подчеркиванием (имя_функции), слова слипаются (имя функции) и т. Д. Я имею в виду, это действительно беспорядок. Слишком много функций, которые очень похожи или выполняют одни и те же действия, но их имена так запутаны. Это не характерно для хорошего языка программирования.

В больших развертываниях язык должен быть достаточно простым и специфичным для написания. Что-то, что пропускает PHP, например объявление типов переменных, становится очень трудным для понимания и последующего решения.

Другим пунктом является постоянное добавление функций и отмена некоторых других. Предполагается, что добавление ООП в PHP 5 облегчит работу программистов, но как насчет соображений обратной совместимости?

Основная причина, по которой этот язык программирования такой, как он есть, заключается в его происхождении: персональная домашняя страница. Он не предназначен для больших развертываний.

Я знаю, что прилагаются большие усилия для того, чтобы сделать этот язык языком корпоративного веса, и лично я жду достаточно хорошего языка программирования на стороне сервера с открытым исходным кодом; но пока этот день не наступит, под мостом будет много воды.

Answer 9

См .: http://www.ukuug.org/events/linux2002/papers/html/php/

Answer 10

Это все хорошие ответы.

Я был новичком. Я занимаюсь программированием всего 5 лет, но я напрямую поддерживаю и управляю 85 маленькими и большими веб-сайтами, и я скажу вам, что потенциальные возможности получить иск из-за того, что веб-сайт будет закрыт в течение дня, во многом помогут вашему желанию учиться как и как сделать лучший код.

Приятно слышать, как разработчики делятся своими мыслями по этому вопросу. Я не думаю, что PHP - лучший, но, похоже, мои инвестиции в «лучшие практики» хорошо обслуживаются.

Спасибо всем!