Pull to refresh

Небесный путь в PHP

Reading time8 min
Views13K
Идею проекта SKY можно излагать по разному, но самое короткое и простое изложение следующее. В интернете существует много сайтов, сила которых в основном обусловлена текстовым и фото-видео контентом пользователей, но нет ни одного, сила которого бы была обусловлена кодом пользователей. Уточню: конечно, есть сайты сохраняющие код пользователей, например «packagist.org», но нет ни одного, которые бы могли достигнуть уровня популярности социальной сети в отношении кодового контента (назовем это цель X), в котором ведется активный скрупулезный анализ всех деталей кода многими участниками. Так сайт packagist сопоставим с проектом SKY, достигшем цели X, также, как можно сопоставить любую инсталляцию форума phpbb с сайтом Facebook. В данный момент проект SKY мало известен, но возможна ли указанная популярность? Моё мнение – конечно, и ключ к этому — простота, следование принципам KISS в дизайне кода. Имхо, и php достиг высокой популярности, в первую очередь, благодаря простоте.

Вообще, я считаю «верный путь в php» большой досадной ошибкой. Точнее некоторые его важные фундаментальные принципы. Писать код в глобальную область видимости и использовать eval() в коде нужно шире, как это делается в SKY framework. По крайней мере, дорогой читатель, я надеюсь, что вы допускаете разумность существования двух путей, а уж какой путь истинно верен, только время способно показать. Часто новое это хорошо забытое старое, прошу вас, не торопитесь думать, что «SKY way» это бесперспективное прошлое.

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

«SKY way» образует некоторые небольшие запросы к изменениям в php в текущий момент, например, хорошо бы было иметь функции: get_context($deep) и filter_context($array). Первая бы выдавала массив переменных соответствующих контексту уровня глубины, где $deep = 0 — свой контекст переменных, 1 — контекст уровня вызова функции, в которой находится код get_context(1). Возвращаемый массив — такой же, как и для callback функции для set_error_handler(). Вторая бы фильтровала массив, для вывода на экран программиста и анализа им переменных, при этом, например $GLOBALS, не должна быть показана в «чистом» виде, но лишь в сокращенном. «SKY way» не следует принципу изолирования, когда программист просто не использует глобальную область видимости для переменных, чтобы избежать нечаянного их переопределения в процессе разработки. Вместо этого, в «SKY way» имеются специальные средства, чтобы не допустить такие ошибки, в частности, например используя вышеуказанную функцию get_context(). Принцип изолирования и другие принципы, которые используются, например в Symfony и других популярных в данный момент Framework, приводят к слишком высокому уровню сложности архитектуры, в сравнении с «SKY way».

Второй пример. Чтобы избежать ошибок второго рода, классически, рекомендуется просто не использовать eval(). Но если аргументом для eval() есть код, находящийся в константе — нет абсолютно никакой опасности в использовании eval(). Однако, все равно, не рекомендуется использовать eval(), рекомендуется опасаться его «как огня». В «SKY way» такая логика считается ошибочной. Альтернативы для eval() нет. Наоборот, та альтернатива, которая используется в Symfony и Framework со сходной архитектурой, считается сомнительной, когда eval() не используются широко, так как, подобный путь слишком увеличивает сложность. Усложнять архитектуру кода для повторного использования (КПИ) на PHP, все равно, что, «пилить сук на котором сидишь». Но можно ли использовать eval() не опасаясь подвергнуть приложения риску? Можно. Можно, например, при использовании eval() выдавать ошибку PHP WARNING, когда достоверно неизвестно о безопасном использовании eval(), в остальных случаях не выдавать ошибку. Также можно, например, в Framework, сделать реестр использования eval(), чтобы привлечь внимание разработчиков к этим местам в коде или использовать комбинированный, гармоничный с самим PHP способ. Я подразумеваю, что реестр содержит текстовые описания гарантий безопасности. Кстати, можно представить ситуацию, когда начинающий программист не знает об опасности eval(), а наличие реестра, акцентирует его внимание и он благодаря этому избежит ошибок безопасности.

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

В проекте SKY уделяется огромное внимание потенциальной частоте использования КПИ на реальных веб-приложениях. Так ядро SKY Framework (потенциально наиболее часто употребимый код), составляют всего лишь три файла, размером около 50 Kbytes и именно этот код должен быть подвержен максимальной кристаллизации сообществом. Гибкость кода, в том числе ядра, выбирается более низкой, в сравнении, например с гибкостью компонентов Symfony.

Ввиду ультимативного преследования принципов KISS, в SKY многие решения не типичны или даже противоположны тем, которые приняты сообществом, поддерживающим «верный путь в PHP»:

1) нет необходимости использовать (по крайней мере, как базовые средства разработки) технологии в Framework:

а) роутинг страниц, как механизм излишен. Реально нужные задачи, которые им решаются, легко реализовать простыми манипуляциями в коде приложения.
б) ORM как механизм излишен. Нет необходимости «делать обертку» для и без того лаконичного языка SQL.
в) Компилируемые шаблоны излишни. PHP сам по себе предоставляет достаточно средств, чтобы использовать PHP шаблоны с самым высоким качеством.
г) Механизм NAMESPACE излишен. Он решает задачу этапа разработки, на этапе выполнения, в том числе на production инсталляциях, что само по себе даже неверно логически.
д) и т. д. нет необходимости сейчас все вспоминать и перечислять…

2) В SKY уделяется гораздо большее внимание этапу разработки. В SKY все старается быть гармоничным, как окружающий мир. SKY Framework поставляется вместе с веб-приложением DEV.SKY, ориентированным на решение задач этапа разработки в гораздо большей мере, чем например, консольная утилита Symfony. Я бы сказал, что в SKY, «сапожник имеет сапоги».

3) нет папки vendor. Требуется переработка классов на packagist в соответствии с идеологией SKY. В SKY допускается (но, конечно, стараемся избегать) редактирование КПИ, в том числе ядра, разработчиками приложений. Во-первых есть стандартные средства для изменений кода ядра (с помощью приложения DEV.SKY) — получения из «чистого облака» кода «облачной модификации», это позволяет заменить высокий уровень гибкости компонентов Symfony, SKY-решением. «Чистое облако» это термин проекта SKY, характеризующий условно идеальный КПИ, потенциально способный стать полноценной заменой для не менее чем 70% сайтов реально существующих в Интернете. Во-вторых, обновления кода ядра, просто часто не требуется, ввиду того что он мал, прозрачен и кристаллизирован. В-третьих, обновления кода ядра, остаются возможными путем слития (ручного разрешения коллизий) и не представляют трудностей из-за того, что код мал и прост. Также обновления редки, ввиду того, что код кристаллизирован (идеален). В четвертых, стараться «уходить» от обновлений это скорее хорошо, чем плохо. Нельзя быть уверенным в постоянной благонадежности доверительных источников, нехорошо тратить личное время на обновления заведомо не идеального кода.

4) Вместо packagist, код третьего крыла, как и ядро SKY, хранится в БД кода, на том же сайте, в том же проекте SKY. Нет смысла собирать более 100К классов на PHP как на packagist, вместо этого, имеет смысл иметь гораздо меньшее кол-во классов на coresky.net, но подвергать код кристаллизации, постоянному совершенствованию. Не нужно иметь альтернативные решения на packagist, лучше иметь единые идеальные решения. В проекте SKY будет цениться умная мысль даже анонимного пользователя, с помощью пирамидальной системы рейтингов и бонусов. Любой участник системы будет способен легко влиять на любой код КПИ в SKY, если имеет ценные мысли.

5) и т. д. нет необходимости сейчас все вспоминать и перечислять…

На этом сайте, habrahabr, я иногда встречаю статьи подобные этой: PHP: фрактал плохого дизайна. Эта статья — интересная работа, но минус автору за то, что он не сделал анализ «железобетонного факта», не ответил на вопрос — почему язык PHP является ведущим в области веб разработки. Без такого анализа статья видится как «плач вопиющего..». Даже если автор написал эту статью без специального заказа от создателей конкурирующих языков, она имеет 100% рекламный (анти-рекламный) характер. Кстати, мое мнение: язык PHP похож на простой C/C++ с возможностями языка высокого уровня, именно этот факт, первую очередь, а не верная маркетинговая стратегия или что-либо иное, принесло ему, имеющуюся популярность. Важна также возможность расширения языка с помощью модулей «extension», написанных на C и удачное время начала разработки. Автор хвалит Perl, но Perl был раньше и проиграл в популярности, это факт. Подобно этой статье, предлагающей напрочь отказаться от PHP, я рассматриваю «верный путь в PHP», как подобный, но еще более тонкий маркетинговый ход, предлагающий напрочь отказаться от других подходов с целью использовать только этот. Мне видится, существующая в данный момент, к сожалению, большая «армия» профессионалов, поддерживающая «правильный путь в PHP» и небольшое количество профессионалов, чувствующих что в «правильном пути» что-то не так, к вторым, я отношу и себя. Первых я прошу не быть категоричными в убеждениях, позволить существовать «небесному пути», вторых я приглашаю на проект для более детального изучения того, что имеется уже сейчас в проекте SKY.

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

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

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

а) создание свободного идеального КПИ как для веб-разработки, но также и для другого программирования. Создание формального подхода для получения идеального кода не только для веб.

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

в) возможно создание контролируемого искусственного интеллекта, в отличие от недавно прозвучавшего в новостях DEEPMIND, который, несмотря на принятый «комитет по этике ИИ», вероятно работает по принципу «черный ящик» и вероятно представляет угрозу. Нельзя создать ИИ типа «черный ящик», чтобы он был безопасен. Хакеры знают как можно «взломать все», но если ИИ будет умнее людей, он также, обязательно вырвется на свободу. Эта проблема сродни проблеме CO2 в атмосфере и глобальному потеплению: все всё понимают, но продолжают ездить на бензине, также же и с ИИ: хочется сделать первый раз неважно какой, но реально работающий.
Only registered users can participate in poll. Log in, please.
Все ли Вам нравится в «верном пути PHP» и современных трендовых фреймворк?
73.94% да105
34.51% нет49
142 users voted. 115 users abstained.
Tags:
Hubs:
Total votes 50: ↑14 and ↓36-22
Comments271

Articles