PHP
Неправильный путь
Последнее обновление: 2023-01-31
В мире программирования PHP сложились определенные тенденции, которые некоторые люди продвигают в своих книгах или на сайтах. Они позиционируют их, как «современный PHP» или «новейшие технологии». В то время как все другие подходы объявляют отсталыми, глупыми или неправильными, ошибочными.
Похоже, что эти люди неустанно работают над тем, чтобы привлечь всех остальных последовать их примеру, заставить использовать их способы программирования.
Этот сайт был создан в попытке представить прагматичный взгляд на программирование PHP. Эта точка зрения была обусловлена опытом и практикой, а не теорией, академическими догмами и модными направлениями. Сайт The Wrong Way – это живой документ, и он будет обновляться по мере поступления дополнительной информации.
Не стесняйтесь вносить свой вклад.
Одной из проблем насаждаемых правил и основных принципов программирования является то, что они часто хороши только для достижения цели в определенном контексте. Будучи вырванным из него, хорошее правило может стать ужасным правилом. На самом деле любое хорошее правило становится плохим, если довести его до крайности.
Это важно понимать, потому что многие правила и принципы разработки программного обеспечения, которые в разное время разрабатывались разными людьми, доводятся до крайностей, попав в руки к экстремистам.
Опыт показывает, что неверное использование общих правил и принципов всегда приводит к усложнению, дырам в безопасности, багам, а в некоторых случаях и к полному краху.
Принцип KISS (Keep It Simple, Stupid), «делай это проще, тупица», является чрезвычайно мудрым и хорошим принципом. Как правило, он рассматривается опытными людьми, как замечательный совет, которому стоит следовать. Однако даже этот совет представляет опасность для проекта, если он доведен до крайности. Если всё слишком просто, то это может привести к отсутствию необходимой функциональности.
Неверный путь: Религиозное следование правилам и руководящим принципам. 
Все PHP-фреймворки общего назначения отстой!
В PHP сообществе обнаруживается действительно нехорошая тенденция: для разработки веб-приложений негласным стандартом стало использование универсальных фреймворков.
Этот тренд возник и обрел популярность не потому, что данный способ каким-то образом улучшает результаты процесса разработки, или потому, что это правильно с точки зрения технологии или архитектуры. Эта тенденция стала популярной, потому что некоторым разработчикам фреймворков удалось отмести аргументы сторонников «программирования с нуля» такими заявлениями: «Зачем изобретать велосипед?» или «Не делай это сам, это сделают люди более квалифицированные, чем ты!»
Многие сегодняшние программисты совершенно игнорируют фундаментальные принципы качественного рационального программирования, и они тратят кучу времени, выдумывая новые уровни сложности, только для того, чтобы казаться более умными, более крутыми и более востребованными, нежели их коллеги.
Эти люди, похоже, одержимы мыслью стать в некотором смысле лидерами PHP сообщества, иметь последователей своего метода, которые используют их последние модные опенсорсные инструменты. При этом они забывают убедиться в том, чтобы советы, которые они дают, были бы полезными и надежными.
Фреймворк общего назначения можно сравнить с каркасным домом (это дом, который собирается из готовых блоков). Разработка программ на основе таких фреймворков не делает вас кодером или программистом, подобно тому, как сборка такого дома не делает вас плотником.
На этом сайте мы отличаем фреймворк от библиотеки следующим образом:
В мире Python и Ruby создание веб-сайтов с нуля утомительно, потому что ни Python, ни Ruby изначально не были созданы для этого. В итоге фреймворки, такие как Django и Ruby on Rails, быстро стали популярными и широко используемыми для создания веб-сайтов на этих языках. Напротив, Расмус Лердорф изначально создал PHP, как набор инструментов, написанных на C, который дает вам возможность быстро и легко разрабатывать динамический HTML. По существу PHP сам по себе был и остается фреймворком. С тех пор PHP бурно развивался, и сегодня его не только можно использовать для генерации HTML или создания веб-сайтов, но и рассматривать, как своего рода фреймворк. PHP, написанный полностью на процедурном C, по своей сути является определенным уровнем абстракции для разработки веб-приложений. Использование библиотеки в вашем проекте вполне естественно. Сам PHP поставляется в комплекте с набором библиотек, которые вы можете использовать, чтобы расширить свой собственный код. PDO, например, представляет собой небольшую библиотеку, которая обеспечивает последовательный интерфейс для доступа к базам данных в PHP. А вот использование фреймворка поверх PHP – это совсем другое дело. Когда вы используете фреймворк в PHP, вы добавляете новый слой абстракции поверх другого, уже существующего, который уже был готов к использованию. Дополнительный уровень абстракции, обеспечиваемый фреймворком, может просто организовать код в заранее подготовленные шаблоны или же может усложнить дело за счет переплетения сотен или даже тысяч классов и методов в кошмар зависимостей. Но как бы там ни было, вы добавляете в свой код новые уровни сложностей, которые совсем не нужны!
Познание программы начинается с интерфейса. Знание интерфейса – это результат знания базовой технологии, а также и всех уровней абстракции. Чем больше количество уровней абстракции используется, тем менее эффективным становится интерфейс, и тем более подвержено ошибкам приложение. Чем выше уровень абстракции, тем больше будет утрачено деталей и эффективности.
Примите, как очевидное: ** Идеально количество строк в проекте должно быть настолько мало, насколько это возможно, пока все остается четким и читабельным.**
То, что вам совершенно не нужно, это фреймворк. Нет общих проблем, каждый человек имеет свою, очень специфичную проблему. Её он и пытается решить.
Некоторые компании с воодушевлением приняли PHP фреймворки и начали свои следующие проекты, используя их. Только, в конце концов, это привело к катастрофе. Мало того, что они обнаружили, что фреймворки плохо решают их специфические потребности, но они оказались ещё и невероятно медленными. Было невозможно их масштабировать, и в результате разработчики стали ломать саму основу в попытках удалить оттуда все ненужное.
Всегда используйте прагматический подход:
Действие или мышление должны скорее учитывать возможные практические последствия, чем руководствоваться теориями или догмами.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Неправильный путь: Всегда используйте фреймворк поверх PHP.
У меня просто аллергия на башни из слоновой кости и на шаблоны проектирования. Когда Питер Норвиг был в Harlequin Inc, он написал статью о том, что шаблоны проектирования на самом деле лишь прикрывают дефекты в вашем языке программирования, вам надо выбрать язык программирования получше. И он абсолютно прав. Поклоняясь паттернам, можно думать только категориями: «Так, сейчас я буду использовать шаблон X»
– Брендан Айк в “Кодеры за работой - Размышления о ремесле программирования”
В программной инженерии шаблон проектирования представляет собой многоразовое решение для проблем, с которыми обычно сталкиваются при разработке программного обеспечения. Шаблон проектирования - не окончательная конструкция, её можно преобразовать непосредственно в программный код. Это описание решения проблемы, которое может быть использовано в различных ситуациях. В объектно-ориентированных языках шаблоны проектирования, как правило, показывают отношения и взаимодействия между классами или объектами без указания классов и объектов конечного приложения. PHP поддерживает императивную, функциональную, объектно-ориентированную, процедурную и рефлексивную парадигмы. PHP это набор из огромного количества различных инструментов, которые дают возможность решить многие проблемы многими различными путями – не только одним способом. Суть PHP это свобода, быстрые и масштабируемые решения, наличие множества различных способов справиться с проблемами. Когда мы пытаемся совершенствоваться, а в данном случае речь идет об улучшении кода, мы иногда так зацикливаемся на философии конкретного паттерна или идеи, что перестаём думать практично.
Когда я вижу в своей программе шаблоны, я расцениваю это как тревожный знак. Модель программы должна отражать только ту проблему, которую должна решить. Любая другая закономерность в коде, по крайней мере для меня, является признаком того, что я использую недостаточно мощные абстракции. Например, что я вручную генерирую расширения макросов, которые нужно написать.
– Пол Грэм
Мы не должны быть втянуты в философию или идею конкретного шаблона или решения. Наша главная задача – сохранить код максимально понятным и простым для навигации, насколько это вообще возможно. И в результате будет легко поддерживать этот код и легко обеспечивать его безопасность. Мы также должны помнить, что существует такая вещь, как анти-паттерн. Это тоже шаблон, который обычно используется, но на практике оказывается неэффективным и/или контрпродуктивным.
Я думаю, что шаблоны начинали как общепризнанные лучшие решения для общих проблем. Но теперь, после того, как какое-то время паттерны были в ходу, мы имеем приложения, которые в десятки раз сложнее, чем это необходимо. И это только потому, что люди пытаются впихнуть в них все шаблоны, о которых когда-либо читали («мое приложение хорошо спроектировано, потому что до краев напичкано разными паттернами»). Так что мое впечатление об их ценности немного изменилось.
– Пол Уитон в “Зло шаблонов проектирования”
Всегда используйте практический подход:
Действие или стратегия должны быть продиктованы скорее соображениями достижения качества немедленных практических результатов, чем теориями или догмами.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
Неправильный путь: Искать шаблон, чтобы решить проблему.
Проблема объектно-ориентированных языков в том, что они тянут за собой всё, что с ними связано. Вы хотели банан, а получили обезьяну, его держащую, и еще все джунгли в придачу.
– Джо Армстронг в «Кодеры за работой - Размышления о ремесле программирования»
Абстракция – великая сила. А что у меня вызывает аллергию еще с 1990-х, так это CORBA, COM, DCOM и всякая объектно-ориентированная чушь. Каждый новый проект в то время обязательно имел какую-нибудь примочку, которой было нужно 200 000 вызовов только для того, чтобы напечатать Hello World. Это профанация. Настоящие программисты таким не занимаются.
– Брендан Айк в «Кодеры за работой - Размышления о ремесле программирования»
Многие разработчики программного обеспечения и многие компании считают, что объектно-ориентированное программирование сегодня является единственным разумным способом разработки. Любой, кто выступит против него, сразу же осознает тот факт, что он спорит против «традиционной мудрости».
На блогах и форумах по программированию есть очень много людей, которые отстаивают ООП, и которые уверены, что знают, о чем говорят. И это несмотря на отсутствие какого-либо четкого его определения!
Дело в том, что так называемое объектное программирование зачастую становится тяжелым бременем из-за ненужной сложности!
Как компьютерные теоретики и программисты мы должны научиться опровергать предубеждения и находить лучшие решения для поставленной задачи.
На сегодняшний день одним из основных преимуществ PHP является поддержка обеих императивных, функциональной, объектно-ориентированной, процедурной и рефлексивной парадигм. PHP представляет собой огромный набор инструментов с большим количеством различных механизмов, которые позволяют решить многие проблемы по-разному, не только одним путем.
** Как только мы начинаем навязывать различные внутренние проблемы приложения одной специфической парадигме, мы перестаем думать творчески, перестаем работать эффективно.**
Один из лучших способов понять специфическую парадигму программирования – посмотреть на её эволюцию. Что послужило причиной для ее развития? Какие проблемы, имеющиеся в других парадигмах, привели к новому образу мышления? Была ли это реальная мировая проблема, либо она была академической? И как эта парадигма с тех пор изменилась?
Не имеет значения, что говорит человек X, и какое определение дает человек Y. Важна история возникновения парадигм.
Есть два способа построения программ. Первый – сделать её настолько простой, что в ней очевидно не будет недостатков. Второй – сделать её такой сложной, что в ней не будет очевидных недостатков.
В прошлом, еще до пришествия объектно-ориентированных языков, примерно в конце пятидесятых, было создано множество программ с использованием неструктурированного программирования. Их иногда называют языками первого и второго поколений. Неструктурированное программирование исторически является самой ранней парадигмой. Её сильно критиковали за спагетти-код.
Существуют как высокоуровневые, так и низкоуровневые языки, которые используют неструктурированное программирование. К ним относятся ранние версии BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, машинный код, ранние ассемблерные системы (без процедурных метаоператоров) и некоторые скриптовые языки.
Программа в неструктурированных языках, как правило, состоит из последовательных команд и операторов по одному в каждой строке. Строки обычно нумеруются либо имеют метки, позволяющие потоку переходить к любой строке в программе (например, с помощью непопулярного оператора GOTO).
В шестидесятые годы структурное программирование появилось в основном благодаря знаменитой статье Эдсгера Дейкстры «Доводы против оператора GOTO»
Структурное программирование – это парадигма, которая улучшает ясность, качество и результат разработки программного обеспечения путем использования подпрограмм, блочных структур и циклов. В отличие от использования элементарных ответвлений программы, таких как оператор GOTO.
Позже из структурного программирования возникло процедурное. Оно основано на концепции «вызова процедур». А это просто другое название «вызова функций». Процедуры так же известны как подпрограммы или методы. Процедура просто содержит ряд вычислительных шагов, которые должны быть выполнены. Любая процедура может быть вызвана в любой момент во время выполнения программы, в том числе и другими процедурами или даже собой.
Вначале все процедуры были доступны из любой части программы в качестве глобальных данных. В небольших программах это не представляло проблемы, но, как только программа усложнялась, и ее размер увеличивался, небольшие изменения в одной части программы стали в значительной степени влиять на многие другие части.
Никто не планировал таких изменений и появления такого количества зависимостей. Небольшое изменение в одной процедуре могло привести к череде ошибок во многих других процедурах, зависящих от её исходного кода.
Новая технология развивалась, что позволило разделить данные на разные области видимости, называемые «объектами». Только конкретные процедуры, относящиеся к одной области видимости, могли получить доступ к данным той же области. Это называется скрытие данных или инкапсуляция. Результатом стала намного лучшая организация кода.
Сначала объекты не назывались объектами, они рассматривались только как области видимости. Позже, когда зависимости и связи между переменными и процедурами внутри этих областей уменьшились, их стали рассматривать как отдельные изолированные сегменты. В результате родились такие понятия, как объекты и объектно-ориентированное программирование.
Еще позднее, в основном благодаря развитию Java, появились некоторые «словечки», процедуры и функции перестали называться функциями, а стали называться методами, если они находились внутри границ объекта. Переменные тоже больше не называют «переменными», они были переименованы в «атрибуты», если они находились в отдельной области видимости.
Таким образом, объект, по сути, это просто набор функций и переменных, которые теперь стали называться «методами и атрибутами».
Методы и атрибуты изолированы внутри отдельной области с помощью использования «класса». После создания экземпляра класса он называется объектом.
Объекты могут друг на друга ссылаться, и с помощью этих ссылок методы (функции) внутри могут «общаться» друг с другом. Объекты могут также «перенимать» методы от других объектов, тем самым их расширяя. Это называется «наследованием». Это способ повторного использования кода, позволяющий создавать независимые расширения программ через публичные классы и интерфейсы. Взаимосвязи объектов приводят к иерархии. Наследование было изобретено в 1967 году для языка программирования Simula 67.
Объекты могут так же наследовать методы от других объектов и «переопределить» их с добавлением или изменением функциональных возможностей. Это называется «полиморфизм».
Эти в разных языках программирования эти идеи реализованы разными способами.
Объектно-ориентированное программирование – это совершенно другой способ организации кода, чем был раньше. Это продолжение процедурного программирования с добавлением сокрытия данных (инкапсуляции) и избеганием глобальных областей видимости. Речь идет о расширении функций путем «заимствования» своих схем без влияния на исходный код (наследование). И речь идет о переопределении функций, при котором не затрагивается исходный код (полиморфизм).
Объектно-ориентированная модель позволяет легко наращивать программы за счет аккреции. На практике это, как правило, означает, что она обеспечивает структурированный способ записи спагетти-кода.
– Пол Грэм в Ansi Common Lisp
Неправильный путь: Всегда использовать объектно-ориентированное программирование.
Когда используют фреймворки, приводят такой аргумент: кодеры не ходят иметь дело с кодовыми базами, которые написал с нуля кто-то другой.
Этот странный менталитет в основном встречается среди веб-разработчиков PHP сообщества, и он говорит о недостатке профессионализма и опыта.
Работа с чужим кодом при разработке приложений это нормально, это часть ежедневной работы профессионального программиста. И это не то, чего стоит бояться.
Профессионал не будет ныть по поводу того, как он или она оказался в полной зависимости от программиста-предшественника, который, возможно, больше не участвует в проекте, и вот если бы только предшественник использовал бы фреймворк А или фреймворк B, то это сэкономило бы целый день работы.
У профессиональных программистов менталитет другой. Они так не делают.
Возможно, в наличии такого дефектного мышления играет роль низкий порог вхождения в сферу PHP. Как бы там ни было, это признак того, что человек идет по неправильному пути.
Основной удел программирования состоит из необходимости работать с чужим кодом. Это просто часть работы – пытаться улучшить существующую кодовую базу. А иногда и полностью её переделывать.
Посмотрите, что говорят великие программисты в книге «Кодеры за работой. Размышления о ремесле программирования».
Некоторые из крупнейших и наиболее выдающихся кодовых баз были созданы сотнями людей, которые никогда даже не встречались друг с другом. Эти базы разрабатывались без использования каких-либо фреймворков. Они созданы исключительно на процедурном языке программирования, при их разработке ничего не использовалось, кроме процедурной парадигмы. И разработчики этих баз даже не помышляли делать это как-то иначе.
Ядро Linux содержит более чем 20 миллионов строк кода, написанных полностью на процедурной парадигме. Его разрабатывали более чем 14.000 участников, и они не использовали никаких фреймворков.
Различные BSD пакеты и большинство пользовательских Linux GNU были написаны исключительно с использованием процедурного программирования, без фреймворков.
То же самое относится и к сотням опенсорсных проектов по всему миру, которые были брошены первоначальными разработчиками, но были подхвачены и развиты другими умелыми программистами. Многие из этих проектов имели очень скудную документацию (если имели вообще), не снабжались ни комментариями в коде, ни какими бы то ни было указаниями, как это использовать, и вообще не содержали никакой поддержки.
Вся кодовая база PHP, раз на то пошло, сделана на C, чистой процедурной парадигме и без единого фреймворка.
Всякий раз, когда вы определяете класс или запускаете свой любимый PHP фреймворк, вы пользуетесь плодами чьей-то процедурной работы!
Конечно, встречается и кошмарный код, который, возможно, никак не проектировался, либо код, который ужасно разросся, но клиент не захотел его переделывать. В такой кодовой базе вы не можете найти концов, но никакой фреймворк не защитит вас от этой ситуации. Часто это естественный процесс роста программы. В конечном итоге в этой ситуации любой фреймворк будет разорван на куски.
И, конечно, существует ужасный спагетти-код, но никто не делает его таким специально. Иногда это является результатом отсутствия опыта, иногда виноват клиент, потому что часто меняет спецификацию прямо в процессе разработки. Так или иначе, в обоих случаях вы получите спагетти-код независимо от того, используете ли фреймворк или нет. И сколько бы вы ни старались применить объектно-ориентированное программирование, результат будет тем же - спагетти.
Как программисты, мы все стараемся предотвратить такие ситуации и это нормально, это искусство программирования, это часть того, что значит быть программистом!
Неправильный путь: Бояться чужого кода.
FIG расшифровывается как Framework Interoperability Group (Группа по совместимости фреймворков).
PHP-FIG была создана разработчиками фреймворков на конференции php|tek в 2009 году. С тех пор к ним обратился и выступил за этот стандарт еще ряд разработчиков, и группа увеличилась с 5 до 20 участников.
Вокруг PHP-FIG существует много споров. Многие полагают, что это лучшее, что случилось в PHP сообществе, после самого PHP, в то время как другие считают, что это нужно забыть как страшный сон.
Одна из проблем, связанных с PHP-FIG, это то, как они сами себя представляют в своем FAQ:
Идея группы — предоставить участникам возможность говорить об общности между нашими проектами и найти способы совместной работы. Наша основная аудитория – это мы сами, но мы очень хорошо понимаем, что за нами наблюдает всё остальное PHP-сообщество. Если другие захотят принять то, что мы делаем, они могут это сделать, но это не цель. Никто в нашей группе не хочет указывать вам, как программисту, как строить приложение.
Однако когда мы рассматриваем работу некоторых членов группы, мы можем ясно видеть, что цель совершенно противоречит приведенному выше тезису. Они неустанно пытаются сделать из PHP-FIG «Группу PHP стандартов». Это, кстати, и было их первоначальным названием. Они делают это, позиционируя свою работу «современным PHP» в своих книгах, на сайтах, на различных форумах, блогах, определяя все остальные направления, как устаревшие.
Одной из проблем, связанных с PHP-FIG является то, что хотя многие фреймворки и опенсорсные проекты приняли некоторые стандарты группы, эти стандарты в основном касаются проблем с точки зрения фреймворков. А это часто делает их непригодными в реальных практических ситуациях.
Многие разработчики создают программное обеспечение для промышленного применения, и оно должно быть чрезвычайно эффективным, надежным и экономически выгодным, таким, чтобы клиенты готовы были его покупать и использовать. Они не должны отвлекаться на стандарты, которые разработали фанатики фреймворков. Если они будут это делать, это станет катастрофой для бизнеса.
Если какая-то группа и должна быть создана, то она должна отражать интересы всего PHP сообщества, а не только сторонников фреймворков и опенсорсных CMS. Она должна быть представлена разработчиками самого PHP, с гораздо большим числом членов, имеющих право голоса.
Если вы решили принять стандарты, разработанные PHP-FIG, вы должны понимать, что некоторые из этих стандартов, такие, как стандарты автозагрузчика PSR-0 и PSR-4 и ряд других стандартов, оказывают прямое влияние на то, каким в итоге будет ваш код.
Во многих сферах требуется высоко масштабируемые, не требующие много времени для разработки, экономически эффективные программы, которые просто невозможно создать, если следовать стандартам PHP-FIG.
Неправильный путь: Следовать стандартам PHP-FIG, религиозно.
С программистами есть одна проблема: вы никогда не знаете, что делает программист, пока не становится слишком поздно.
– Сеймур Крей в defprogramming.com
Безопасный код – это метод написания программ, устойчивых к атакам злонамеренных хакеров или просто развлекающихся людей, а также вредоносных программ. Безопасное кодирование помогает защитить данные от кражи или повреждения. Кроме того, небезопасная программа может предоставить злоумышленнику доступ к серверу или учетным данным, в результате чего могут быть разные последствия: от отказа в доступе к базе для отдельного пользователя, потере секретных данных до падения сервера и взлома тысяч аккаунтов.
Каждая компьютерная программа является потенциальной мишенью для атаки. Злоумышленники будут пытаться найти уязвимости в системе безопасности ваших приложений, чтобы похитить важную информацию, нарушить целостность программ и данных, получить контроль над серверами и сетями. Собственность клиентов и ваша репутация под угрозой.
Безопасность – это не то, что можно добавить к программному обеспечению!
Небезопасное приложение может потребовать обширной реконструкции, чтобы появилась возможность обеспечить его безопасность. Вы должны определить характер угрозы для вашего программного обеспечения и использовать практику безопасного кодирования, начиная с этапа проектирования и на протяжении всего развития вашего приложения.
Защита критически важных ресурсов программного обеспечения сегодня является важной, как никогда, так как внимание злоумышленников постоянно перемещается на прикладной уровень. Исследование, проведенное SANS 2009, показало, что атаки на веб-приложения составляют более 60% от общего количества атак, наблюдаемых в Интернете.
PHP необычен тем, что это одновременно и язык программирования и веб-платформа. Это означает, что PHP имеет много веб-функций, встроенных в язык, что делает возможным очень просто написать небезопасный код.
Сложность убивает. Она высасывает жизнь из разработчиков, затрудняет планирование продуктов, их создание и тестирование, бросает вызовы в сфере безопасности и приводит конечных пользователей и администраторов к разочарованию.
– Рей Оззи
Для того чтобы разрабатывать приложения с надлежащими требованиями безопасности, методы безопасного кодирования с акцентами на всевозможные угрозы должны постоянно, изо дня в день, внедряться в процессы, операции и даже мысли.
Как правило, гораздо дешевле построить безопасное приложение изначально, чем исправлять проблемы безопасности после того, как пакет программного обеспечения уже завершен. Не говоря уже о том, что нарушение безопасности может повлечь за собой дополнительные расходы.
Неправильный путь: Не разрабатывать приложение безопасным по умолчанию.
Очень просто неверно истолковать то, что мы написали, поэтому давайте проясним некоторые вопросы.
Q: В чем смысл этого сайта и почему вы выбрали конфронтационный подход?
A: Для того чтобы начать дискуссию о современных методиках и крайних точках зрения.
Q: Вы говорите, что объектно-ориентированное программирование плохо или неправильно?
A: Нет, конечно же, нет! Мы говорим: не стоит решать все проблемы только использованием объектной парадигмы. Нельзя делить всё на чёрное и белое, это неправильно.
Даже в рамках одного приложения могут существовать самые разные проблемы. Иногда мультипарадигма – лучшее решение, всё зависит от задачи, которую вы решаете.
А если вы насильно решаете проблему с помощью неподходящего способа, случаются нехорошие вещи.
Q: Вы говорите, что фреймворки — зло?
A: Мы не пытаемся судить конкретные фреймворки. Мы осуждаем лишь их постоянное использование поверх PHP.
Q: Если фреймворк помогает мне быстро начать и продолжить работать, что в этом плохого?
A: Если вы проанализируете ситуацию, её последствия в долгосрочной перспективе и поймёте, что «быстро начать и продолжить работать» — единственная проблема, которую вам надо решить, то в этом нет ничего плохого. Но тогда мы говорим не о программировании или разработке ПО, а об использовании point-and-click решений.
Быстро начать и продолжить работать – это не проектирование приложения. Это значит, что вы не анализировали проблему и не осознали долгосрочных последствий своего выбора.
Q: Вы хотите сказать, что сторонние пакеты — это плохо?
A: Нет. Мы рекомендуем использовать сторонние библиотеки. Код, который вы можете легко и без ограничений внедрять в свои проекты. Это здорово!
Q: Кто вы?
A: Наш сайт посвящён идее борьбы с экстремизмом в PHP-сообществе, а не личному продвижению или получению признания. Если мы раскроем имена, это лишь отвлечёт внимание от поднятых на сайте проблем. Давайте просто оставаться сосредоточенными на идеях.
Q: Каков ваш опыт в разработке программного обеспечения?
A: Чтобы прийти к идеям, мыслям и решениям, отражённым на нашем сайте, не требуется большого опыта, если вы просто остаетесь сфокусированными на основной теме, которая заключается в том, чтобы всегда делать конкретные вещи.
PHP: Неправильный путь — на Hacker News
Почему наипростейший код бьет «лучшие практики»
Кодеры за работой. Размышления о ремесле программирования.
Черты квалифицированного программиста.
OWASP Руководства по безопасному программированию.
Принципы безопасного проектирования.
Выживание на глубине: безопасность в PHP.
Улучшение существующей структуры кода с помощью рефакторинга
Понимание языков программирования
какие альтернативы доступны разработчикам, какие языковые конструкции лучше использовать для повышения безопасности и читабельности, как эти конструкции реализованы, и как их можно эффективно компилировать, какова роль языка в выражении и усилении абстракций.
Сотрудничать на GitHub.