Критика php: фрактал плохого дизайна / Хабр

8 фактов и мифов о PHP — Блог HTML Academy

Редакторы:
Кирилл Сенкевич, Евгений Шкляр

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

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

Факты о PHP

1. У PHP низкий порог входа

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

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

Иногда кривая обучения чуть-чуть кривее, чем кажется сначала

Так и с программированием — качество вашего кода будет зависеть от времени, которое вы потратите на изучение языка и практику.

2. PHP вообще везде

Здесь речь не о сфере применения языка, а о том, насколько легко запустить и протестировать ваш код в различных окружениях.

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

С локальной разработкой тоже всё просто — есть много хороших бесплатных решений, например OpenServer, в котором даже ничего настраивать не придётся, и PHP работает «из коробки».

3. У PHP развитая экосистема

Сравнивая различные языки программирования, следует брать в расчёт не только их синтаксис или предлагаемые фичи, но и экосистему.

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

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

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

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

Количество пакетов для PHP продолжает расти — на момент написания статьи их уже более двухсот тысяч.

Пакеты и их версии на packagist

Экосистема PHP развивается в нескольких направлениях. Кроме привычных фреймворков, популярность и поддержку сообщества разработчиков стали набирать фреймворки, ориентированные на асинхронные возможности PHP. Это проекты Swoole, ReactPHP и Amp.

4. PHP развивается

Некоторые ребята каждый год говорят, что PHP уже всё. Такие разговоры длятся лет десять. Тем не менее, PHP чувствует себя прекрасно: регулярно выходят новые версии языка, экосистема растёт, и в количестве вакансий недостатка тоже нет.

Обновляются как API расширений и синтаксис языка, так и внутренности интерпретатора. Последний пункт сильно влияет на общую производительность, которая возрастает от версии к версии. В PHP 7 разработчики частично переписали ядро и это положительно отразилось на его производительности: скорость работы увеличилась в два раза, а потребление памяти, наоборот, снизилось. Если не верите, можете посмотреть на замеры производительности PHP в сравнении с другими языками.

Мифы о PHP

Перейдём к мифам. Их, как и вокруг любой популярной технологии, скопилось немало, но мы остановимся на четырёх самых интересных.

1. PHP — решето

«Программы на PHP небезопасны» — распространённый повод для критики PHP.

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

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

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

2. PHP медленный

Вопрос производительности любой технологии всегда вызывает бурные дискуссии.

Facebook, Wikipedia и «ВКонтакте» строят на PHP приложения разного масштаба, а скорость их работы может легко оценить любой наш читатель. При этом повышение производительности всегда стоит среди приоритетных задач разработчиков. Например, при переходе с версии 5.6 на 7 производительность PHP выросла от 15 до 20%. В последних, минорных версиях языка, работа над повышением скорости исполнения кода продолжается.

3. Технология X скоро вытеснит PHP

Миф о серебряной пуле особенно любят муссировать в IT-сообществе: технология X скоро вытеснит Y, и тому подобное. Инструментов, с помощью которых можно выполнять те же самые задачи, что и на PHP, много: JavaScript, Ruby, Python, C#, да и мало ли что ещё.

У каждой технологии есть свои фанаты и хейтеры, с любой из них можно писать плохой код или делать шедевры. Вопрос в другом.

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

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

4. На PHP пишут плохой код

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

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

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

К счастью всех нас, те времена давно прошли, и появилась культура написания хорошего кода. Теперь у нас есть руководства по стилю, стандарты кодирования, линтеры и другие вещи, которые помогают писать хорошо.

Выводы

PHP — это удобный язык программирования высокого уровня.

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

Но не забывайте: язык программирование — это просто форма выражения, а содержание — это качество кода. И содержание в этом случае зависит не от языка, а от вашего опыта и навыков. Чтобы развить навыки, разобраться в языке с нуля и получить ценный опыт разработки настоящего проекта, познакомьтесь с PHP на интерактивном курсе и приходите на интенсив к нам, в HTML Academy.

Обсуждаем будущее PHP / Блог компании Edison / Хабр

Это мертвый язык программирования или нет?

У PHP наверняка были лучшие времена. Но действительно ли он мертв?

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

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

PHP все еще доминирует в Интернете

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

Одна из причин, по которой PHP используется многими сайтами, заключается в том, что WordPress использует PHP. Доля WordPress на рынке составляет около 34 процентов всех сайтов. Это 75 миллионов сайтов.

Поддержка публикации — компания Edison, которая занимается разработкой и диагностированием хранилища документов Vivaldi.

Кроме того, есть и другие CMS, такие как Drupal (3%) и Joomla (2%), которые также занимают значительную долю рынка. И есть некоторые популярные системы управления магазинами, такие как Magento, которые занимают около 1 процента от общей доли рынка.
Многие большие системы управления контентом и магазинами используют PHP, что делает PHP важным и актуальным.

Создание сайтов с нуля

Я вижу аргумент о создании сайтов с нуля, так как многие люди, которые используют WordPress, например, не знают, как программировать. Создание сайта в WordPress не требует от вас умения писать код. Многие люди, у которых есть веб-сайт на WordPress, вероятно, даже не знают, что он работает на PHP. Таким образом, PHP все еще используется людьми, которые создают веб-сайты с нуля?

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

Программирование

Так как PHP существует с 1994 года, язык со временем стал немного загроможденным. Есть много способов создать такую ​​же функциональность, и многие из них довольно хакерские. Это создает ситуации для создания плохого кода на PHP. Очевидно, что можно написать плохой код на любом языке, но PHP делает его немного легче из-за того, как он вырос.

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

С другой стороны, можно утверждать, что большинство веб-разработчиков не пишут сырой PHP. В большинстве случаев вы будете использовать какой-то фреймворк, который многое сделает для вас. Популярный PHP-фреймворк, который очень чистый — это Laravel. Преимущество работы с фреймворком состоит в том, что большая часть грязной работы выполняется под капотом. Фреймворк заставляет вас писать более чистый код.

PHP 7

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

Code wise, объявления типов и новые операторы были введены. Обработка ошибок также была улучшена.

Рабочие места

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

Если вы посмотрите на эту ссылку в разделе заданий StackOverflow, вы найдете множество заданий, требующих PHP.

Заключение

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

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

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

Так что вы думаете о PHP, есть ли будущее у этого языка программирования или он мертв?

не все так однозначно? / Хабр

Привет, Хабр! Представляю вашему вниманию перевод статьи «PHP in decline: The rise and fall of a programming language» автора Сары Шлотхауэр (Sarah Schlothauer).

Когда-то PHP был одним из самых популярных языков программирования, однако на сегодняшний день он продолжает терять свою былую популярность. Это особенно заметно при его сравнении с Python, а также рядом других языков программирования. Индекс TIOBE за сентябрь 2019 года ясно указывает на то, что PHP вполне может вылететь из десятки наиболее востребованных языков программирования.

Пора ли заказывать по умершему панихиду? Или наш «феникс» еще будет летать?

PHP уверенно следует по траектории падения своего индекса TIOBE, заданной еще пять лет назад. В частности, показатели индекса TIOBE за сентябрь 2019 года говорят о том, что за последние 12 месяцев этот язык программирования опустился в списке на две позиции — с 7 на 9 место.

Ниже приведен скриншот индекса TIOBE Index за сентябрь 2019 (источник):

Что касается языков-«новичков», то в этом месяце под номером 11 в списке дебютирует Apache Groovy.

В прошлом году он занимал скромное 34-е место, поэтому его нынешняя позиция в списке является, несомненно, большим успехом. Groovy в некотором смысле похож на Java, что позволяет Java-разработчикам легко освоить этот язык и интегрировать его с Java/библиотеками сторонних разработчиков.

Причины снижения популярности PHP

На заре юности Интернета PHP был очень популярен. В 2004 году он даже стал языком года по версии индекса TIOBE (согласитесь, что сейчас об этих славных временах мало кто вспомнит).

Что же привело PHP к такому печальному финалу?

Собственно, процитируем непосредственно сам индекс TIOBE:

«До конца 2009 года все было отлично, но затем, за два года, этот язык программирования потерял половину своей доли рынка, которая снизилась с 10 до 5%. В 2014 произошло еще одно двукратное уменьшение сегмента рынка, на котором господствовал PHP — до 2,5%. Что же произошло с этим языком программирования? Недостатком PHP являлась его уязвимость в вопросах безопасности, которая была, в свою очередь, производной его простоты. При этом PHP мучительно долго боролся с этим недостатком. В частности, в 2014 году основной идеолог использования PHP — компания Facebook — запустила Hack, намереваясь заменить им PHP, так как последний не мог обеспечить должную масштабируемость. К тому же к этому времени в качестве универсальных языков веб-разработки начали использовать JavaScript, TypeScript и Python».

Взлеты и падения

Недавнее видео на Reddit от Global App Testing наглядно иллюстрирует историю расцвета и упадка различных языков программирования за последние 10 лет. На видео указаны самые популярные языки на StackOverflow с 2008 года. Посмотрите его — оно не столько информирует нас о сухих фактах и цифрах, сколько завораживает своей подачей графической информации.

На видео видно, о каком языке программирования было задано больше всего вопросов.

Вы удивитесь, но несколько раз за свою историю PHP был популярнее Java! Словно на ипподроме, кажется, что лошадка с кличкой PHP вот-вот станет первой. Однако примерно с сентября 2016 года нашего фаворита начинает обгонять Python, после чего PHP уже не суждено оправиться от полученной бреши в броне. История языка начинает плавно идти по наклонной.

Ну что, конец?

Перефразируя строки известной песни «Чайфа», «не спеши ты его хоронить». Да, PHP существенно потерял в популярности, но сообщество программистов на этом языке живет и здравствует.

Конференции по PHP проходят по всему миру. Только за последний год PHP стал центральной темой митапов и встреч программистов в Японии, Бразилии, Украине, Германии, Китае, США и на Тайване.

Кроме того, официальный Твиттер-аккаунт php.net в настоящий момент насчитывает 67.7 тысяч подписчиков. Кроме того, 5 сентября 2019 года вышел последний релиз языка PHP — версии 7.4. При этом Reddit-аккаунт PHP насчитывает 105 тысяч членов, активно обсуждающих соответствующие фреймворки, IDE, а также последние новости из мира PHP.

Не стоит также упускать из виду и другие показатели популярности PHP. Свежий отчет IEEE Spectrum зафиксировал 13-е место PHP в своем рейтинге, где «соседями» этого языка программирования стали Assembly (этажом ниже) и HTML/CSS (этажом выше).

Если вы все еще беспокоитесь о «здоровье» PHP, беспокоиться не о чем, потому что в рейтинге языков программирования RedMonk за июнь 2019 года PHP занимает 4 место!

Ниже приведен скриншот рейтинга языков программирования RedMonk Q3 2019 Programming Language Rankings (источник):

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

Да и вообще вы видели символ языка PHP? Лично ВЫ готовы похоронить эту милую зверюшку?

Современный PHP — прекрасен и продуктивен / Хабр

Почти 8 месяцев тому назад я пересел с проектов python/java на проект на php (мне предложили условия от которых было бы глупо отказываться), и я внезапно не ощутил боли и отчаяния, о которых проповедуют бывшие разработчики на ПХП. И вот что я думаю по этому поводу.

Что есть что

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

Python. Когда речь заходит о проектах на python (чаще всего на Django), мы получаем платформу, которая позволяет достаточно удобно и просто наращивать функционал, строить rest-api сервера, проводить шардирование системы и прочее. Логика работы фреймворка очень понятная и прямолинейная. Даже совсем зеленый разработчик может за пару часов набросать небольшой бложик с админкой. Плюс документация Django – одна из самых качественных, что я видел. К этому всему добавляется синтаксический сахар python, который помогает реализовывать определенные паттерны весьма элегантно. Если мы отходим от Django в сторону Tornado/aiohtpp/Twisted/Flask итд – то там начинается боль, ибо код в них писать гораздо неприятней, чем в Django.

Java. Если мы говорим про Java, например, Spring – то это системы, которые вызывают анальную боль тем, что заставляют тебя конфигурировать все, что можно конфигурировать. Порог вхождения очень высокий, огромное число нюансов, которое нужно держать в голове, плюс сам синтаксис Java заставляет тебя писать весьма объемные конструкции (правдиво для всех проектах на шестой Java). Но в качестве награды мы получаем весьма надежные и гибкие системы, которые могут пережить не один десяток программистов с весьма посредственными руками.

Что же касается PHP

Перед началом работы я прочитал книгу: Мэтт Зандра – PHP объекты, шаблоны и методики программирования, и убедился, что PHP в общем-то без особой боли позволяет реализовывать те или иные паттерны разработки. Т.е. в PHP можно писать правильный код, который будет не сильно отличаться от того, что мы получаем на Python/Java.

Zend Framework 1

Проект внутреннего сервиса меня встретил Zend Framework 1 на PHP 5.3. Скажу сразу, что многие решения на данной платформе выглядят весьма спорно, а язык PHP 5.3 имеет ограничения на установление типа возврата функций (методов), тем не менее, достаточно быстро понимаешь, где что лежит, как что прокидывается, а как что формируется.

Например, если мы рассматривает Zend Forms, то они практически под копирку делают то, что делают классические формы в Django. Синтаксис построения запросов в ДБ Zend DB Table – не вызывает какого-то негатива, и весьма очевидно работает.

Т.е. буквально за 2-3 дня я смог полноценно разбираться и стал писать код, который делал то, что от него требовалось вполне адекватным способом.

Symfony 3.4

Спустя 3 месяца меня перевели на другой проект на Symfony 3.4 и PHP 7.1 – и вот это просто бомба. У меня откровенно было ощущение, что мне дали в ручки Django, куда добавили надежность системы из Java.

• Шаблонизатор Twig – полный клон Jinja от Django.
• Doctrine ORM – аналог Hibernate
• Аннотации Symfony – аналог декораторов из Python
• Auto-wiring Symfony – даже работает очевидней, чем DI в Spring
• Очевидные конфигурации секрьрности
• Удобное построение rest-APi клиентов.
• Удобное написание джоб для крона (в данном случае в симфонии они называются консольные команды)
• Удобный дебагер и консольный помощник.

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

Единственный жирный минус – это недостаточная документация. Т.е. в документации указываются самые простые кейсы, а все что интересней, уже требует копания в исходниках symfony, ну и фреймворк на удивление не так популярен в Гугле, как бы того хотелось.

Поэтому, я абсолютно не понимания, почему люди плюют в сторону PHP, когда он работает и весьма клево.

А есть ли разница

Также хочу отметить такой момент, что после того, как ты поработал на 3-4 современных веб-фреймворках, тебе приходит понимание, что все везде работает схожим образом. Отличаются названия и реализации, а общие концепции 1 в 1. Поэтому, скажем, если вы работали на Django, то пересесть на php Symfony / .Net CORE MVC – можно без особо труда за пару месяцев.

P.S.: если я все же слеп и глуп, прошу в комментарии.

неправильный путь / Блог компании Mail.ru Group / Хабр

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

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.

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

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

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

Принцип KISS, который некоторые расшифровывают как «Keep It Simple, Stupid», — чрезвычайно мудрый и правильный, опытные люди призывают следовать ему. Но даже KISS может стать угрозой для проекта, если довести его до абсурда. Есть такое понятие, как излишняя простота, что в нашем случае приводит к недостатку функциональности.

Неправильный путь: религиозное следование правилам и руководствам.

Все PHP-фреймворки общего назначения — отстой!
Расмус Лердорф

В PHP-сообществе по-настоящему плохая тенденция превратилась в де-факто стандарт при разработке веб-приложений. Речь идёт об использовании популярных фреймворков общего назначения.

Это явление широко распространилось. Причина тому — не улучшение результатов разработки и не правильность выполнения каких-то операций с точки зрения технологий и архитектуры. Просто некоторые авторы фреймворков увлекли за собой сообщество разработчиков с помощью полемики, направленной против создания приложений с нуля. Характерными лозунгами стали «Не изобретайте колесо!» и «Не надо всё делать самостоятельно, об этом уже позаботились более опытные».

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

Этим людям настолько нравится увлекать других за собой, становиться своеобразными лидерами мнений в PHP-сообществе, убеждать всех использовать свежие и «модные» open source инструменты, что они забывают удостовериться в осмысленности и толковости своих советов. Фреймворк общего назначения можно сравнить с собранным на фабрике домом. Строительство приложения с помощью такого фреймворка сделает вас кодером или программистом в той же степени, как возведение заранее собранных домов превратит вас в плотника.

В этой статье мы различаем фреймворки и библиотеки по следующим признакам:

• Библиотека — это набор многократно используемого кода. Например, стандартные библиотеки С или Go. Код библиотеки можно легко и без ограничений внедрить в проект. Она состоит из маленьких фрагментов, у каждого из них есть конкретная функциональность.
• Фреймворк — это не просто набор многократно используемого кода: вы не сможете вырезать кусок из фреймворка и вставить его в проект. Эта система помогает создавать ПО, но в то же время накладывает на вас ограничения, присущие самому фреймворку. Кроме того, во фреймворке немало взаимозависимой функциональности: одна часть не сможет работать без других.

В мире Python и Ruby создание веб-сайтов с нуля — занятие довольно утомительное, поскольку эти языки для создания веб-сайтов не предназначались. В результате фреймворки общего назначения, такие как Django и Ruby on Rails, быстро стали популярны именно для сайтостроительства на Python и Ruby.

А PHP Расмус Лердорф изначально создавал как набор инструментов, написанных на С, позволяющих легко и быстро разрабатывать динамический HTML. PHP таким задумывался и таким остался, он сам и есть фреймворк.

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

Использовать библиотеки в проектах совершенно естественно. В комплекте поставки PHP идёт набор библиотек, которые могут расширить ваш код. Например, PDO — маленькая библиотека, предоставляющая согласованный интерфейс для обращения к базам данных в PHP.

А вот использование фреймворка поверх PHP — совсем другое дело.

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

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

Чётко уясните: строк кода в любом проекте должно быть как можно меньше, чтобы код стал как можно чище и читабельнее!

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

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

Всегда используйте прагматичный подход, при котором:

Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.

Словарь английского языка Collins, полная версия, 12-е издание, 2014

Неправильный путь: всегда использовать фреймворк поверх PHP.

У меня сильная аллергия на оторванные от жизни проекты и шаблоны проектирования. Питер Норвиг написал хорошую статью о том, что шаблоны проектирования — это лишь недостатки вашего языка программирования. Перейдите на язык получше. И он абсолютно прав. Все поклоняются шаблонам и только и думают: «Ага, я воспользуюсь шаблоном Х».

Брендан Айх. Coders at work — Reflections on the Craft of Programming

Шаблоны проектирования — это многократно используемые решения часто возникающих проблем в архитектуре приложения. Шаблоны — это не законченный проект, который может быть напрямую преобразован в код. Это лишь описание, идея того, как решить проблему, для использования во многих разных ситуациях. Объектно ориентированные шаблоны обычно демонстрируют связи и взаимодействия между классами или объектами без определения финальных классов или объектов приложения.

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

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

Когда я вижу в своей программе шаблоны, для меня это сигнал о неприятностях. Структура программы должна отражать только решаемую проблему. Любые другие закономерности в коде говорят (по крайней мере, мне) о том, что я использую недостаточно сильные абстракции. Например, что я вручную генерирую расширения макросов, которые нужно написать.
Пол Грэм

Нельзя попадать в ловушку философии или идеи, стоящей за конкретным шаблоном или решением. Наша главная задача — сделать код как можно более лёгким для понимания, а значит, безопасным и простым в сопровождении.

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

Я думаю, изначально шаблоны были некими узнаваемыми лучшими решениями частых проблем. Но спустя некоторое время мы обнаружили, что приложения стали в десять раз сложнее, чем нужно, потому что люди пытаются запихнуть туда все шаблоны, о которых они читали («Моё приложение хорошо продумано, потому что по горло нагружено шаблонами»). Так что моё представление о ценности шаблонов изменилось.

Пол Уитон. Evil Design Patterns

Всегда используйте прагматичный подход, при котором:

Действие или политика продиктованы рассмотрением прямых практических последствий, а не теорией или догмой.

Словарь английского языка Collins, полная версия, 12-е издание, 2014

Неправильный путь: искать шаблон для решения проблемы.

Проблема ОО-языков в том, что они тащат за собой всё своё неявное окружение. Вы хотели банан, но при этом получили гориллу, которая держит банан, и все джунгли в придачу.

Джо Армстронг. Coders at work. Reflections on the Craft of Programming

Абстракция — это сила. А что меня действительно отвращает и о чём я говорил ещё в 1990-е, так это CORBA, COM, DCOM, объектно ориентированная чушь. В то время каждый стартап предлагал какую-нибудь безумную вещь, которая при запуске вызывала 200 тысяч методов и выводила «Hello world». Это же пародия! Вам, как программистам, не нужно ассоциировать себя с такими вещами.

Брендан Айх. Coders at work. Reflections on the Craft of Programming

Многие разработчики и компании сегодня считают, что ООП — единственный оправданный способ разработки. А те, кто с этим спорят, немедленно осознают, что идут против «общепринятого мнения» индустрии.

Блоги и форумы, посвящённые программированию, полны защитников ООП, уверенных в том, что они понимают, о чём говорят, хотя какого-либо стандартного определения не существует.

Но дело в том, что так называемое объектно ориентированное программирование очень часто бывает излишне сложным!

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

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

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

Один из лучших способов понять парадигму программирования — посмотреть, как она возникла. В чём причина? Из-за каких проблем в других парадигмах понадобился новый подход? Была ли проблема практическая или академическая? И сколько времени прошло с момента создания парадигмы?

Неважно, что говорит человек Х или какое определение даёт человек Y. Важны исторические предпосылки возникновения парадигм.

Есть два пути разработки архитектуры приложения. Первый — сделать её настолько простой, чтобы, очевидно, недостатков не было. Второй — сделать её настолько сложной, чтобы очевидных недостатков не было.
Чарльз Энтони Ричард Хоар

Раньше, ещё до пришествия ООП, примерно в конце 1950-х, для создания многих программ использовали языки с упором на неструктурированное программирование. Их иногда называют языками первого и второго поколений. Неструктурированное программирование исторически стало первой парадигмой. Её активно критиковали за спагетти-код.

Есть и высоко-, и низкоуровневые языки, использующие неструктурированное программирование. Например, BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинный код, ранние системы ассемблера (без процедурных метаоператоров), ряд скриптовых языков. Программа на неструктурированном языке обычно состоит из последовательно расположенных команд или выражений, обычно по одной на строку. Строки либо нумеруются, либо могут содержать метки, позволяющие потоку выполнения переходить к любой из строк (вроде непопулярного выражения GOTO). В 1960-х появилось структурное программирование, во многом благодаря известному письму Эдсгера Дейкстра Go To statements considered harmful.

Структурное программирование — это парадигма, улучшающая чистоту, качество и процесс разработки с помощью подпрограмм, блочных структур и циклов. Это в противовес простому перепрыгиванию выражения GOTO.

Затем из структурированного программирования возникло процедурное. В его основе лежит концепция «вызова процедуры». Это ещё одно название для «вызова функции». Процедуры также известны вам как подпрограммы или методы. По сути, это серия вычислений, которые необходимо выполнить. Любая процедура может быть вызвана другими процедурами или самостоятельно в любое время в ходе исполнения программы.

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

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

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

Затем, в основном из-за появления Java, появились новые модные термины, а «процедуру», или «функцию», переименовали в «метод», когда он принадлежит отдельной области видимости. Переменные переименовали в «атрибуты», когда они принадлежат отдельной области видимости.

Так что объект, по сути, — это просто набор функций и переменных, которые теперь называют методами и атрибутами.

Методы и атрибуты изолируются внутри отдельной области видимости с помощью «класса». А когда создаётся экземпляр класса, он называется объектом.

Объекты могут ссылаться друг на друга, и благодаря этому методы (функции) внутри них тоже «взаимодействуют» друг с другом. Также объекты могут «наследовать» методы от других объектов, тем самым расширяя их, это называется «наследование». Это способ многократного использования кода, позволяющий создавать независимые расширения приложений через публичные классы и интерфейсы. Взаимосвязи между объектами породили иерархию. Наследование было создано в 1967 году для языка Simula 67.

Объекты также могут наследовать методы от других объектов и «переопределять» их с помощью дополнительной или изменённой функциональности, это называется «полиморфизм».

В разных языках эти идеи реализованы очень по-разному.

Объектно ориентированное программирование — это иной способ организации кода. Это расширение процедурного программирования, связанное с сокрытием данных (инкапсуляцией) и избеганием глобальных областей видимости. Это расширение функций посредством «заимствования» их чертежей без влияния на оригинальный код (наследование). И это переопределение функций без влияния на оригинальный код (полиморфизм).

Модель ООП позволяет легко создавать программы путём аккреции (наращивания). На практике это зачастую означает, что это структурированный способ написания спагетти-кода.

Пол Грэм. Ansi Common Lisp

Неправильный путь: всегда использовать объектно ориентированное программирование.
Один из частых аргументов, оправдывающих применение фреймворков, — нежелание людей иметь дело с кодовыми базами, сделанными из фрагментов кода, написанного другими.

Это довольно странное мышление, в основном характерное для веб-разработчиков, говорит о недостатке профессионализма и опыта.

Совершенно нормально создавать приложение и работать с кодом, написанным другими. Это часть повседневной работы профессионального программиста, и не нужно её бояться.

Профессионал не будет ныть, что его работа теперь полностью зависит от кода сотрудника, который, вероятно, больше не имеет отношения к компании или проекту, а вот если бы этот сотрудник использовал фреймворк А или фреймворк Б, то это сэкономило бы вам день работы.

Профессионалы так не думают. Ни один.

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

Программирование во многом подразумевает взаимодействие с людьми, использующими чужой код. Это часть работы: пытаться улучшить существующую кодовую базу, и иногда приходится её полностью переписывать. Почитайте, что говорят мастера программирования в книге Coders at work. Reflections on the Craft of Programming.

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

Ядро Linux содержит более 20 миллионов строк кода, написанных исключительно с помощью процедурного программирования. В его создании участвовали 14 тысяч человек — и никаких фреймворков. Разные возможности BSD и большая часть Linux GNU userland также написаны только с помощью процедурного программирования без применения фреймворков.

То же самое можно сказать о сотнях open source проектов по всему миру, заброшенных авторами только для того, чтобы их подхватили другие опытные программисты. По многим из этих проектов очень мало документации (или её вообще нет), нет комментариев в коде, нет руководств или иных видов помощи.

Да чего уж там — вся кодовая база PHP написана на С, процедурном языке, без фреймворков.

Когда вы определяете класс в PHP или когда вы запускаете свой любимый PHP-фреймворк, вы выполняете чью-то процедурную работу!

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

Безусловно, существует кошмарный спагетти-код, но никто не пишет его намеренно. Иногда это результат нехватки опыта, зачастую — вина клиентов, много раз меняющих спецификации посреди разработки. Но в обоих случаях вы бы всё равно получили спагетти-код, даже при использовании фреймворка. И неважно, насколько интенсивно вы станете применять объектно ориентированную парадигму: результат окажется тем же.

Как программисты, мы должны предотвращать такие ситуации, но это нормально, в этом заключается искусство программирования, это часть того, что называется быть программистом!

Неправильный путь: бояться кода, написанного другими.

FIG расшифровывается как Framework Interoperability Group (Группа по совместимости фреймворков).

PHP-FIG была создана разработчиками фреймворков на конференции php|tek в 2009 году. С тех пор её состав увеличился с 5 до 20 участников.

С PHP-FIG связано много споров. Одни считают это лучшим начинанием PHP-сообщества со времён возникновения самого PHP. Другие уверены, что стоит вообще поскорее забыть о существовании этой группы.

Одна из проблем заключается в том, как PHP-FIG позиционирует себя в своём FAQ:

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

Однако если мы посмотрим на работу нескольких участников группы, становится очевидно, что реальная цель полностью противоречит заявленному. Группа всячески старается превратить PHP-FIG в «группу PHP-стандартов», что было их первоначальным названием. В книгах участников группы, на их сайтах, в блогах, на форумах и т. д. работу PHP-FIG именуют современным PHP, а все остальные подходы объявляют устаревшими.

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

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

Если и нужна какая-то группа, то её стандарты должны отражать интересы всего PHP-сообщества, а не одних лишь разработчиков фреймворков и open source CMS проектов. Такая группа должна представлять разработчиков самого языка PHP, с гораздо большим количеством участников, причём с правом голоса.

Если вы решили следовать стандартам PHP-FIG, то вы должны понимать, что некоторые из них — например, стандарты автозагрузчика PSR-0 и PSR-4 и ряд других — напрямую влияют на то, как вы пишете код ПО.

Во многих сферах требуется высокомасштабируемое, критичное ко времени выполнения, экономически выгодное ПО, которое просто невозможно создать, если следовать стандартам PHP-FIG.

Неправильный путь: следовать стандартам PHP-FIG, за исключением PSR-1 и PSR-2.

С программистами есть одна проблема: вы никогда не знаете, что делает программист, пока не становится слишком поздно.

Сеймур Крей. defprogramming.com

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

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

Нельзя просто добавить безопасность в приложение!

Чтобы сделать небезопасное приложение безопасным, возможно, придётся существенно перепроектировать его. Вы должны определять происхождение угроз для вашего ПО и внедрять методики безопасного кода с самого начала, придерживаясь их в течение всего планирования и разработки приложения.

Безопасность критических программных ресурсов сегодня важна как никогда, поскольку основной вектор атак неуклонно перемещается на уровень приложения. По итогам исследования SANS 2009 года, атаки против веб-приложений составили более 60 % всех атак, зарегистрированных в интернете.

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

Сложность убивает. Она высасывает жизнь из разработчиков, затрудняет планирование продуктов, их создание и тестирование, ставит перед нами вызовы в сфере безопасности и утомляет конечных пользователей и администраторов.
Рей Оззи

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

Неправильный путь: не разрабатывать приложение безопасным по умолчанию.

Всё вышеописанное легко понять неправильно — давайте кое-что проясним.

В чём цель вашего сайта и почему вы плывёте против течения?

Цель — начать дискуссию о современных методиках и крайних точках зрения.

Так вы говорите, что объектно ориентированное программирование это плохо или хорошо?

Нет, конечно, нет! Речь о том, чтобы вы понимали: не стоит решать все проблемы исключительно посредством ОО-парадигмы. Нельзя делить всё на чёрное и белое, это ошибка. В рамках одного приложения могут существовать самые разные проблемы, и иногда лучший выход — использовать разные парадигмы в зависимости от конкретной ситуации. А если вы решаете проблему с помощью неподходящего способа, то ни к чему хорошему это не приведёт.

Вы говорите, что фреймворки — зло?

Мы не осуждаем конкретно фреймворки. Мы осуждаем лишь их постоянное использование поверх PHP.

Если фреймворк помогает мне быстро начать и продолжить работать, что в этом плохого?

Если вы проанализируете ситуацию и долгосрочные последствия и поймёте, что «быстро начать и продолжить работать» — единственная проблема, которую вы когда-либо решали, то в этом нет ничего плохого. Но тогда мы говорим не о программировании или разработке ПО, а об использовании point-and-click решений.

Быстро начать и продолжить работать — это не создание приложения; это означает, что вы не анализировали проблему и не осознали долгосрочных последствий своего выбора.

Вы хотите сказать, что сторонние пакеты — это плохо?

Нет. Мы рекомендуем использовать сторонние библиотеки. Код, который вы можете легко и без ограничений внедрять в свои проекты. Это отличная возможность!

Кто вы?

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

Каков ваш опыт в разработке ПО?

Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы всегда делаете то, что говорят другие.

1. PHP: Неправильный путь — на Hacker News. Когда мы запустили наш сайт, на Hacker News появилось много комментариев, в которых отражено немало ценных аргументов.
2. Как программировать без ООП. Свежая и альтернативная точка зрения: Брайан Уилл в трёх видео рассуждает о том, что не стоит начинать с ООП. В завершение он приводит несколько замечаний, как писать не ООП код.
3. Кодеры за работой. Размышления о ремесле программирования. Интервью основаны почти на 80 часах бесед с 15 величайшими программистами и специалистами по информатике. Здесь вы найдёте многогранный рассказ о том, как они учились программировать, как они оттачивали своё мастерство и что они думают о будущем программирования.
4. Черты квалифицированного программиста. Компетентность означает достаточное количество опыта и знаний для выполнения задачи. Квалифицированность — знание, почему вы делает что-то именно таким способом и как это укладывается в общую картину. Иными словами, квалифицированный практик всегда компетентный практик, но обратное необязательно верно.
5. Руководства по безопасному программированию. Не зависящий от технологий документ с набором общих методик безопасного программирования в формате чек-листа, который можно внедрять в жизненный цикл разработки ПО. Используя эти методики, вы избежите большинства распространённых уязвимостей.
6. Принципы безопасного проектирования. Безопасность веб-приложений — неотъемлемый компонент любого успешного проекта, будь то open source приложение, веб-сервис сквозной обработки или проприетарные бизнес-сайты. Хостеры совершенно справедливо остерегаются небезопасного кода, пользователи остерегаются небезопасных серверов. Задача этого руководства — помочь бизнесу, разработчикам, дизайнерам и архитекторам решений создавать безопасные веб-приложения. Если пользоваться им с самых ранних стадий, то стоимость создания безопасных приложений будет сравнима со стоимостью небезопасных, при этом в долгосрочной перспективе финансовая эффективность окажется несравнимо выше.
7. Выживание на глубине: безопасность в PHP. Все жертвы успешных взломов быстро отмечают в пресс-релизах и на сайтах: безопасность для них крайне важна, и они относятся к ней со всей серьёзностью. Примите это близко к сердцу до того, как прочувствуете на практике.
8. Улучшение существующей структуры кода с помощью рефакторинга . Рефакторинг позволяет улучшить имеющуюся структуру кода. Это изменение системы таким образом, чтобы внешнее поведение кода не менялось, но при этом внутренняя структура становилось более гармоничной. С помощью рефакторинга вы даже можете превратить плохую структуру в хорошую. В книге обсуждаются принципы рефакторинга, рассказывается, где его стоит применять в первую очередь и как настраивать нужные тесты. Также приведён каталог более чем из 40 проверенных рефакторингов с описанием, когда и зачем их применять, и пошаговые инструкции по внедрению. Заодно иллюстрируются схемы работы рефакторингов. Книга написана на примере Java, но её идеи применимы в любом другом ОО-языке.
9. Практика программирования. Сборник практических вопросов, актуальных для программистов.
10. Прагматичный программист. Здесь исследуются ключевые процессы программирования, от подмастерья до мастера: выработка требований, выполнение работ, правильное сопровождение кода. Рассматриваются самые разные вопросы, начиная с личной ответственности и развития карьеры и заканчивая методикой разработки архитектуры ради сохранения гибкости, простоты адаптации и многократного использования кода.
11. Понимание языков программирования. Выбор языка программирования — один из важнейших факторов, влияющих на общее качество программной системы. К сожалению, слишком многим программистам не хватает лингвистических навыков: они влюбляются в свой «нативный» язык и не способны критически анализировать его ограничения. Книга «Понимание языков программирования» написана, чтобы объяснить:
    • какие альтернативы доступны разработчикам,
    • какие языковые конструкции лучше использовать для повышения безопасности и читабельности,
    • как эти конструкции реализованы и как их можно эффективно компилировать,
    • какова роль языка в выражении и усилении абстракций.

PHP: критика перехода с оригинального API MySQL на mysqli и PDO

Оригинальный API MySQL (функции mysql_*() — например, mysql_query() и пр.) с версии PHP 5.5.0 объявлен устаревшим. Вместо него разработчики PHP рекомендуют использовать модуль mysqli или объекты данных PHP (PDO). Эти средства обладают расширенным по сравнению с традиционным API функционалом, но действительно ли они удобнее в повседневной практике?

mysqli

mysqli — «MySQL improved extension» («улучшенный модуль MySQL») — прямой наследник оригинального API MySQL, обладающий более широкими возможностями. Чтобы почувствовать разницу, достаточно посмотреть на список его методов и сравнить с таковым оригинального модуля. Однако нужно отметить, что отличие в реальных возможностях на самом деле только одно: mysqli имеет возможность отправки множественных запросов¹. Хотя иметь такую возможность и удобно, на практике её наличие ощутимой роли не играет².

Другими словами, разницы в реальных возможностях обычного и улучшенного модулей практически нет. Зато есть разница в интерфейсе. Рассмотрим, как в простейшем случае выглядит самая обычная операция — установление соединения с сервером MySQL и выполнение запроса:

// оригинальный модуль
mysql_connect(‘host’, ‘user’, ‘password’);
mysql_query(«SELECT 1»);

// улучшенный модуль, процедурный интерфейс
$mysqli = mysqli_connect(‘host’, ‘user’, ‘password’);
mysqli_query($mysqli, «SELECT 1»);

// улучшенный модуль, объектный интерфейс
$mysqli = new mysqli($host, $user, $password);
$mysqli->query(«SELECT 1»);    

Здесь важно заметить, что функция mysql_query() не требует передавать в явном виде указатель на соединение (хотя и позволяет это делать). В подавляющем большинстве случаев для работы требуется только одно соединение с MySQL, и, однажды установив его, вполне удобно и естественно просто вызывать mysql-функции, не ссылаясь на соединение в явном виде каждый раз.

Функция же mysqli_query(), напротив, требует передавать объект, указывающий на соединение. Этот объект потребуется во всех местах, где нужно будет делать запрос. Это означает, что в коде с локальной областью видимости — функциях и классах — придется либо заводить глобальную переменную, либо передавать этот объект явно.

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

Резюмируя сказанное, приходится констатировать, что на практике модуль mysqli не обладает какой-то дополнительной полезностью по сравнению с оригинальным. Пользоваться же им менее удобно.

PDO

PHP Data Object (Объекты данных PHP) — расширение языка, определяющее абстрактный интерфейс доступа к базам данных (это означает, что одни и те же методы PDO могут использоваться для разных СУБД).

На практике реально ощутимым отличием PDO от других интерфейсов к MySQL является возможность легко делать следующие две операции:

• вставку в запрос параметров с экранированием
• получение результата запроса в виде ассоциативного массива

Работа с MySQL, в основном, и заключается именно в этих двух вещах, поэтому многие разработчики останавливают свой выбор на PDO.

Однако есть один нюанс. Рассмотрим, как в самом простом случае средствами PDO выполняется запрос:

$DBH = new PDO(‘mysql:host=…;dbname=…’, ‘user’, ‘password’); // соединяемся с БД
$query = $DBH->prepare(«SELECT 1»); // готовим запрос
$query->execute(); // выполняем запрос

Важно отметить, что для отправки запроса требуется вызывать не один метод, а два — prepare(), а затем execute(). На уровне механизма СУБД в данном случае задействуются т.н. prepared statements — специальный инструмент СУБД, позволяющий ускорить последовательное выполнение повторяющихся запросов, построенных по одному и тому же шаблону.

Вместе с тем, на практике идущие подряд однотипные запросы встречаются довольно редко. Напротив, обычно запросы разные, и это полностью нивелирует положительный эффект от предварительного разбора.
Более того, в конечном итоге вместо одного запроса к MySQL делается два, в результате чего схема с prepare() и execute() оказывается даже медленнее обычного одиночного запроса.

PDO позволяет выполнить запрос и напрямую — для этого предназначен метод query(). Однако при использовании этого метода вставку в запрос параметров и их экранирование приходится проводить вручную, поэтому query() не пользуется популярностью и разработчики предпочитают связку из prepare() и execute() в любом случае, потому что это удобнее.

Следует также подчеркнуть, что при использовании PDO (как и в случае с mysqli) есть необходимость заводить объект, который в областях видимости функций и классов недоступен.

Резюмируя сказанное, нужно отметить, что по сравнению с другими модулями PDO предоставляет несколько более удобный функционал, однако реализация его выполнена неоптимально. Кроме того, высокий уровень абстракции интерфейса плохо сказывается на осведомлённости разработчиков о происходящем на стороне MySQL-сервера.

Что делать?

Одним из решений всех вышеперечисленных проблем является библиотека удобных функций MySQL, при разработке которой основной целью было сделать программирование самых распространенных операций при работе с MySQL (таких как сохранение результата запроса в виде ассоциативного массива, обработка ошибок, подстановка массива в запрос) максимально удобным. Вот несколько примеров:

// если в глобальной области видимости есть переменная $mysqli,
// библиотека будет пользоваться инструментами mysqli,
// в противном случае — оригинального модуля MySQL

// включаем mysqli
$mysqli = mysqli_connect(…);

// простая отправка запроса
mysql_q(«TRUNCATE sometable»);

// получение результата скалярного (один столбец, одна строка) запроса
$now = mysql_getcell(«SELECT NOW()»);

// получение строки таблицы:
$row = mysql_getrow(«
    SELECT *
    FROM watches
    WHERE id = 1052
    «);
   
// получение столбца в виде одномерного массива:
$ids = mysql_getcolumn(«
    SELECT id
    FROM watches
    WHERE mark = ‘Edox’ AND price > 5000
    «);

// получение записей таблицы с подстановкой в запрос параметров:
$sql = «
    SELECT *
    FROM watches
    WHERE mark = :mark AND price > :price
    «;
$params = array( ‘mark’ => ‘Edox’, ‘price’ => 5000 );
$data = mysql_gettable($sql, FALSE, $params);

// подстановку можно делать во всех вышеперечисленных функциях

Подробнее о библиотеке можно прочитать в соответствующей статье.

© Все права на данную статью принадлежат порталу webew.ru.
Перепечатка в интернет-изданиях разрешается только с указанием автора
и прямой ссылки на оригинальную статью. Перепечатка в печатных
изданиях допускается только с разрешения редакции.

Почему процедурный стиль на PHP это плохо? — Хабр Q&A

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

Значит Вы начали сразу же писать код решающий задачу, вместо того чтобы подумать над архитектурой. ООП нужен потому что Мы люди УЖЕ ДУМАЕМ ООпнуто!

Когда Вам говорят : Машина едет. Что в голове происходит? Как правило у любого человека возникает образ майбаха или бэхи или ниссан несущийся по просторам. Я к тому что Человек в голове имеет четко заданный ТИП и если ему скажут: «Машина едет это когда 2 передние ноги выбрасываются потом ржание и потом еще 2 задние», то у него сразу же срабатывает «Нет! Это не машина едет, это конь скачет».

Так и в ООП: При хорошо написанной ООП программе у Вас не возникнет мысли что процедура шифрования по алгоритму AES лежит в пакете game_polygon_utils. Ну никак не возникнет, ибо разрыв шаблонов. Где полигоны и где шифрование?! 😉 Хорошая ООП-разработка, да и не только ООП, это итеративная переработка. Вы каждый раз рефакторите, улучшаете, облагораживаете, в конечном итоге у Вас появляются сущности, функции в тех местах где вы их ожидаете увидеть.

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

Вообщем как в математике:
Функция говорит о том как объект выглядит и каким требованиям соответствует, но как его получить не понятно! А процедура как раз и говорит как этот объект получить. Кстати Николас Вирт разрабатывая Pascal для своих студентов именно по этой причине ввел function и procedure. Он хотел подчеркнуть что функция это декларативная часть программы, а процедура императивная. ООП — это как выглядит программа, т.е. декларативная часть программы, а вот конкретные методы и функции это уже императивная.

Критика

31. Декабрь 2017 г. (23:37 ч)

Здесь есть место критике и тому, с чем у пользователей были проблемы.
Может быть, у вас есть проблемы с чем-то, и вы можете найти здесь помощь.

Комментарии пользователей

.

Reader-Response Criticism // Purdue Writing Lab

Эта страница предоставлена ​​вам OWL в Университете Пердью. При печати этой страницы вы должны включить полное юридическое уведомление.

Авторские права © 1995-2018, Лаборатория письма и СОВ при Университете Пердью и Пердью. Все права защищены. Этот материал нельзя публиковать, воспроизводить, транслировать, переписывать или распространять без разрешения. Использование этого сайта означает принятие наших условий добросовестного использования.

Критика отклика читателей (1960-е годы по настоящее время)

Резюме:

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

Что вы думаете?

На самом базовом уровне критика, основанная на реакции читателя, рассматривает реакцию читателя на литературу как жизненно важную для интерпретации смысла текста. Однако критика отклика читателя может иметь несколько различных подходов.Критик, использующий теорию реакции читателя, может использовать психоаналитическую линзу, феминистскую линзу или даже структуралистскую линзу. Что объединяет эти разные линзы при использовании подхода, основанного на реакции читателя, так это то, что они утверждают, что «… текст не может быть отделен от того, что он делает» (Tyson 154).

Тайсон объясняет, что «… теоретики реакции читателя разделяют два убеждения: 1) что роль читателя не может быть исключена из нашего понимания литературы и 2) что читатели не принимают пассивно значение, представленное им объективной литературой. текст, скорее они активно воплощают смысл, который находят в литературе »(154).Таким образом, теория реакции читателя имеет общие основания с некоторыми деконструктивистами, обсуждаемыми в постструктурной области, когда они говорят о «смерти автора» или ее вытеснении в качестве (автора) итальянской фигуры в тексте.

Типичные вопросы:

• Как взаимодействие текста и читателя создает смысл?
• Что пофразовый анализ короткого художественного текста или ключевой части более длинного текста говорит нам об опыте чтения, предструктурированном (встроенном) в этот текст?
• Усиливают ли звуки / формы слов в том виде, в каком они появляются на странице или как их произносит читатель, значение слова / произведения?
• Как мы можем интерпретировать литературный текст, чтобы показать, что реакция читателя является или аналогична теме рассказа?
• Что критика, опубликованная в отношении литературного текста, предполагает о критиках, которые интерпретировали этот текст, и / или об опыте чтения, вызванном этим текстом? (Тайсон 191)

Вот список ученых, которых мы призываем вас изучить, чтобы углубить ваше понимание этой теории:

• Питер Рабинович — Перед чтением , 1987
• Stanley Fish — Есть ли текст в этом классе? Полномочия интерпретирующих сообществ , 1980
• Элизабет Фройнд — Возвращение читателя: критика отклика читателей , 1987
• Дэвид Блайх
• Норман Холланд — Динамика литературного отклика , 1968
• Луиза Розенблатт
• Вольфганг Исер — Подразумеваемый читатель: модели общения в прозе от Беньяна до Беккета , 1974
• Ганс Роберт Яусс

.

Технические статьи, лингвистика, критическая теория

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

Последние публикации

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

Внутренняя безопасность для телекоммуникационных облаков: защитите инфраструктуру с помощью встроенных мер. В этом коротком документе объясняется, как VMware Telco Cloud делает упор на внутреннюю безопасность — безопасность, которая интегрирована с программным обеспечением и инфраструктурой, что делает ее программируемой, автоматизированной, адаптивной и контекстно-зависимой. Издано VMware.

Сообщение в блоге: Адаптация к меняющемуся ландшафту телекоммуникационной компании и изменение требований с помощью встроенных средств безопасности. Опубликовано в блоге VMware Telco Cloud.

VMware Ready для Telco Cloud. Краткий обзор решения.

Kubernetes на vSphere для чайников. Книга опубликована Wiley и VMware.

Ускорение цифровой трансформации с помощью контейнеров и Kubernetes: введение в облачную технологию. Эта электронная книга знакомит вас с контейнерами и Kubernetes, объясняет их ценность для бизнеса, исследует их варианты использования и показывает, как они могут ускорить цифровую трансформацию вашей организации.Опубликовано VMware Press.

Заявление об отказе от ответственности: Хотя Criticism.Com содержит ссылки на официальные документы, которые я написал, работая в VMware или EMC, мнения, выраженные на страницах, опубликованных на Criticism.Com, являются исключительно моими собственными и не являются мнением или взглядами VMware. или любой компании, в которой я работал в прошлом, например EMC. Официальные документы, опубликованные VMware или EMC, находятся на соответствующих веб-сайтах; это просто ссылки на эти документы.

Контейнеры на виртуальных машинах или на «голом железе» ?: Развертывание и безопасное управление контейнерными приложениями в масштабе .В этом техническом документе рассматриваются возражения против запуска контейнеров на виртуальных машинах с техническими объяснениями и ответами, основанными на фактах. В нем утверждается, что объединение контейнеров и виртуальных машин создает идеальный катализатор для надежного и надежного развертывания и эксплуатации контейнерных приложений в любом масштабе. Издано VMware.

Управление цифровой трансформацией с помощью контейнеров и Kubernetes: как Kubernetes управляет контейнерными приложениями для повышения ценности бизнеса. Официальный документ, опубликованный VMware.

Электронный буклет Cloud Native Stack Security. Издано VMware.

Безопасность: блокировка административного доступа Kubernetes для предотвращения криптоджекинга. Незащищенная панель управления Kubernetes в Интернете — это открытое приглашение для хакеров захватить ваши облачные вычислительные ресурсы для добычи криптовалюты. Вот как заблокировать панель управления. Опубликовано в блоге VMware по облачным приложениям.

Глоссарий терминов для облачных вычислений. В этом буклете представлены определения терминологии в облачном пространстве.Определения не предназначены для аксиоматических определений в стиле словаря, а скорее для описания простым языком значения термина и объяснения того, почему технология, связанная с ним, имеет значение. Издано VMware.

Демистификация Kubernetes. Издано VMware.

Управление микросервисами в нескольких кластерах Kubernetes. Издано VMware.

Управление микросервисами на уровне приложений с Istio. Издано VMware.

Защита облачных платформ с помощью Project Lightwave. Издано VMware.

Заявление об отказе от ответственности: Хотя Criticism.Com содержит ссылки на официальные документы, которые я написал, работая в VMware или EMC, мнения, выраженные на страницах, опубликованных на Criticism.Com, являются исключительно моими собственными и не являются мнением или взглядами VMware. или любой компании, в которой я работал в прошлом, например EMC. Официальные документы, опубликованные VMware или EMC, находятся на соответствующих веб-сайтах; это просто ссылки на эти документы.

Недавнее фото

Закат над Сиэтлом и озером Вашингтон, лето 2020 года.

Недавние твиты

Твиты Стива Хениша

Подписаться на @SteveHoenisch

Официальные документы

Заявление об отказе от ответственности: Хотя Criticism.Com содержит ссылки на официальные документы, которые я написал, работая в VMware или EMC, мнения, выраженные на страницах, опубликованных на Criticism.Com, являются исключительно моими собственными и не являются мнением или взглядами VMware. или любой компании, в которой я работал в прошлом, например EMC.Официальные документы, опубликованные VMware или EMC, находятся на соответствующих веб-сайтах; это просто ссылки на эти статьи. r

Управление цифровой трансформацией с помощью контейнеров и Kubernetes: как Kubernetes управляет контейнерными приложениями для повышения ценности бизнеса. Официальный документ, опубликованный VMware.

Контейнеры на виртуальных машинах или на «голом железе» ?: Развертывание и безопасное управление контейнерными приложениями в масштабе . В этом техническом документе рассматриваются возражения против запуска контейнеров на виртуальных машинах с техническими объяснениями и ответами, основанными на фактах.В нем утверждается, что объединение контейнеров и виртуальных машин создает идеальный катализатор для надежного и надежного развертывания и эксплуатации контейнерных приложений в любом масштабе. Издано VMware.

Языкознание

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

Создание согласованности с помощью пассивного голоса: Джозеф М. Уильямс, автор двух влиятельных книг по академическому и профессиональному письму, выступает за использование пассивного голоса для управления потоком информации в предложениях. Для Уильямса пассивный залог не только развивает идею, добавляя к ней детали, но и плотно объединяет предложения в связное целое. Подробнее: пассивный залог может помещать новую информацию в синтаксический слот, который подчеркивает ее — конец предложения.

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

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

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

Критическая теория

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

Знак Соссюра: Знак, означающее и означаемое являются концепциями школы мысли, известной как структурализм, основанной Фердинандом де Соссюром, швейцарским лингвистом, во время лекций, которые он читал между 1907 и 1911 годами в Женевском университете.Его взгляды произвели революцию в изучении языка, положили начало современной лингвистике и повлияли на критическую теорию. Центральный постулат структурализма состоит в том, что явления человеческой жизни непостижимы, кроме как через их сеть взаимоотношений, составляющих знак и систему (или структуру), в которую этот знак встроен первичными понятиями. Таким образом, знак — например, слово — получает свое значение только по отношению к другим знакам в системе знаков или в отличие от них.

Миф психоанализа: Витгенштейн против Фрейда В этом эссе мой центральный тезис состоит в том, что если, как говорит Витгенштейн, фрейдистский психоанализ основан на мифе, его применение к реальным психологическим проблемам не может и не может решить их.Вместо этого все, что он может сделать, это прояснить их или представить их в ином свете. Мой аргумент подразумевает, что именно так Витгенштейн думал о результатах психоанализа, во многом так же, как он думал о применении своей философской техники к философским проблемам, особенно к проблемам метафизики, этики и эстетики. Таким образом, Витгенштейн также развенчивает более крупный миф: идеи, полученные в психоанализе, ведут к научному разрешению психологических проблем. Читайте дальше…

Газетные и журнальные статьи

Выгодные поездки: посмотрите страну на машине и сэкономьте на выезде, в Chicago Tribune .

Книжные проекты и электронные книги

Kubernetes на vSphere для чайников. Книга опубликована Wiley и VMware.

Ускорение цифровой трансформации с помощью контейнеров и Kubernetes: введение в облачную технологию. Эта электронная книга знакомит вас с контейнерами и Kubernetes, объясняет их ценность для бизнеса, исследует их варианты использования и показывает, как они могут ускорить цифровую трансформацию вашей организации. Опубликовано VMware Press.

Электронный буклет Cloud Native Stack Security.Издано VMware.

Глоссарий терминов для облачных вычислений. В этом буклете представлены определения терминологии в облачном пространстве. Определения не предназначены для аксиоматических определений в стиле словаря, а скорее для описания простым языком значения термина и объяснения того, почему технология, связанная с ним, имеет значение. Издано VMware.

Энциклопедия Демократической партии и Энциклопедия Республиканской партии, М.Э. Шарп, Издательство.Выиграл премию журнала Choice за выдающуюся академическую книгу.

Связанные

Резюме: Автор технических официальных документов и евангелист в области технологий.

Подробнее | Карта

.

определение критики по The Free Dictionary

Критика

обзор или критика.

критическая теория, доктрина или подход, основанный на методе, использованном Аристотелем в Поэтике , подразумевающий формальный, логический подход к литературному анализу, который сосредоточен на самом произведении. Ср. Платоническая критика .

Редкий . критик гомеровской литературы, утверждающий, что у Илиады и Одиссеи были разные авторы.

школа литературной критики, которая сосредотачивается на произведении как автономном объекте, значение которого должно быть получено исключительно из исследования самого произведения. Ср. Новая критика . — contextualist , n., Прил. .

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

подробная критика книги, диссертации или другого сочинения.

критическое толкование или экспликация, особенно библейских и других религиозных текстов. — экзегетический, экзегетический , прил. .

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

критический упор на стиль, композицию и художественные средства с ограниченным вниманием к содержанию — формалист , n .- формалистический , прил. .

применение теорий личности, разработанных Фрейдом, к развитию персонажей и другим аспектам художественного творчества. Ср. Психоаналитическая критика . — Freudian , n., Прил. .

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

практика необоснованной или несправедливо резкой критики; поиск ошибок.- гиперкритика , н., Прил . — сверхкритический , прил. .

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

подражание, используемое в литературной критике для обозначения теории подражания Аристотеля. — миметик , прил. .

критический подход или метод, который ищет мифический смысл или образы в литературе, выходя за пределы непосредственного контекста произведения во времени и месте. Ср. Юнгианская критика .

критический подход к литературе, который концентрируется на анализе и объяснении отдельных текстов и считает историческую и биографическую информацию менее важной, чем осведомленность о формальной структуре произведения. — New Critic , n .

американское антиреалистическое, антинатуралистическое и антиромантическое литературное и критическое движение примерно 1915-1933 годов, основными представителями которого были Бэббит, Мор и Ферстер, находившееся под влиянием Мэтью Арнольда, и чьи цели заключались в том, чтобы показать важность разума и воли в контексте честности и достоинства.- новый гуманист , н., Прил .

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

практический подход к литературной критике, при котором текст рассматривается в универсальных терминах с минимальным обращением к сложному аппарату референции вне текста. Ср. Теоретическая критика .

подход к критике или критическая техника, которая применяет принципы, теории и практики психоанализа к литературе, как при анализе произведения, так и автора. См. Также Фрейдизм .

в критике, жесткой или строгой оценке произведения искусства или литературы с точки зрения кодекса стандартов критика или школы стиля или критики, связанной с критиком, художником или писателем или отличной от них. См. Также искусство; язык; литература.- пурист , н., прил. .

действие по поиску собственных ошибок и недостатков. — самокритичный , прил .

тщательное изучение определенного литературного произведения с целью установления его исходного текста. — текстолог , n .

критический подход или доктрина, которая исследует литературное произведение в свете определенных теорий литературы или использует текст в качестве опоры для развития теории литературы. Ср. Практическая критика .

практика высказывать горькие, придирчивые и принижающие критические суждения. — Zoilus, Zoili , n .

-Ologies & -Isms. Copyright 2008 The Gale Group, Inc. Все права защищены.

Критика

(См. Также ПОИСК НЕИСПРАВНОСТЕЙ .)

синий карандаш Удалить или вырезать, изменить или сократить; отметить для исправления или улучшения. Используется исключительно для письменных материалов, синий карандаш происходит от синего карандаша, которым многие редакторы делают изменения в рукописи и комментарии.

проклятый со слабой похвалой Хвалить в таких сдержанных или равнодушных выражениях, что похвала становится бесполезной; осуждать, используя слова, которые в лучшем случае выражают посредственность. Впервые его использовал, вероятно, Александр Поуп в его Послании к доктору Арбетноту 1735 г. :

Черт со слабой похвалой, согласие с гражданской ухмылкой.

арахисовая галерея См. ЗНАЧЕНИЕ .

выстрел в горшок Случайная, небрежная критика или осуждение; суровое замечание вылетело от бедра, лишенное предусмотрительности и направленности. Webster’s Third цитирует ссылку К. Х. Пейджа на

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

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

пращи и стрелы Колючие атаки, язвительная критика; любое страдание или недуг, обычно преднамеренно направленный или причиненный.Эти слова взяты из знаменитого монолога, в котором Гамлет размышляет о самоубийстве:

Будь благороднее в уме — страдать

Пращи и стрелы невероятной удачи,

Или взяться за оружие против моря бед

И противостоять покончить с ними. (III, i)

Как обычно используется, выражение часто сохраняет страдать исходной фразы, но обычно завершает мысль заменой возмутительного состояния другим объектом, как в следующем примере:

На пути к В Соединенных Штатах предприятие пострадало от ударов недоброжелателей, таких как Джордж Мини и Джозеф Папп.(Роланд Гелатт, в Saturday Review , февраль 1979 г.)

Критик секундомера Закономерный формалист, чье внимание так приковано к традиционным критериям или несущественным мелочам, что он не может уделять внимания или даже видеть истинное и полное объект его заботы. Лоуренс Стерн дал нам термин в Тристрам Шенди .

«А как Гаррик вчера вечером произносил монолог?» — О, вопреки всем правилам, милорд, совершенно неграмотно. Между существительным и прилагательным, которые должны совпадать по числу, падежу и роду, он сделал разрыв, таким образом — остановившись, как если бы вопрос хотел уладиться; и между именительным падежом, который, ваше светлость, должно управлять глаголом, он каждый раз прерывал свой голос в эпилоге на секундомер, милорд, дюжину раз, на три секунды и три пятых.

«Замечательный грамматик! Но приостановился ли и смысл его голоса? Разве пропасть не заполнилась никаким выражением отношения или поддержки? Глаз молчал? Вы присмотрелись? «Я смотрел только на секундомер, милорд». «Отличный наблюдатель!»

Живописные выражения: тематический словарь, 1-е издание. © 1980 The Gale Group, Inc. Все права защищены.

.