Главные принципы проекта SKY

SKY / MAIN /
PRINCIPLES1
Чтобы получать идеальный код нужно всегда следовать главным принципам: короткий и простой код как всех файлов в отдельности, так и для совокупности. Необходимо стремиться к тривиальной простоте
кода. Код, который часто используется, необходимо делать максимально коротким, использовать короткие идентификаторы и функции вместо длинных идентификаторов и классов. То же относится к именам идентификаторов, именам классов и функций, - те которые часто используются - короткие, которые редко - можно длинные и максимально сами себя описывающие.

При разработке кода для повторного использования, необходимо выдерживать рациональный баланс между объемом функциональности и простотой кода. Например, код первого крыла "main/sky.php" поддерживает работу с БД MySQL и может потенциально работать на 90% сайтов в текущий момент существующих в Интернете. Чтобы работать с другой БД - нужно использовать порт файла "main/sky.php" для работы с другой БД. Чтобы получить недостающую функциональность не связанную с типом БД, необходимо взять "облачную модификацию" файла CLEAR-CLOUD. То есть не следует делать код излишне гибким и подразумевать что, недостающая функциональность может быть получена портированием файлов CLEAR-CLOUD и их облачной модификацией.

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

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

Главные ошибки современного устоявшегося подхода построения веб-приложений на PHP:

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

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

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

В проекте SKY, выбраны другие фундаментальные основы архитектуры, чем в PSR, отсюда следуют различия во многом, что от них зависит. Но некоторые аспекты PSR, не зависящие от фундаментального выбора, совпадают с выбором правил проекта SKY.
published ENERGY - 21 Sep 2015 12:04 GMT
last edit - 29 May 2018 15:16 GMT
 +  0  -  add comment