SKY way FAQ

1. Если во время разработки архитектуры объекта, вам видится красивое естественное описание свойств и методов, следует ли следовать такому видению?

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

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

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

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

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

3. SKY way не использует namespace и код сайта packagist.org?

В данный момент, да, это так. Код на packagist.org следует `PHP right way`, который является ошибочным в проекте SKY. Сайт packagist.org - очередная, не очень удачная попытка организовать большую базу кода для повторного использования на PHP. На самом деле, нет никакой проблемы, в портировании БД кода с этого сайта в систему БД кода coresky.net. Вероятно, аналогичным образом произошло портирование части кода с сайта phpclasses.org в packagist.org.

Инструкция `namespace`, в данный момент, не используется в коде CORESKY, да, это так. Нет очевидной необходимости ее использовать, в соответствии с принципом KISS, который основополагающий в проекте SKY.

4. PHP right way это ошибка?

Да, в нем недостаточно верно оценены все факторы, которые влияют на качество работы программистов.

5. В коде CORESKY нет роутеров и ORM?

Нет и скорее всего не будет. ORM это слишком "крутая обертка" для того чтобы работать с БД. Нет необходимости, чтобы решать проблемы работы с БД таким сложным способом, их можно решить гораздо проще, не выдумывая сложные сущности. То же самое касается и роутеров. Нет проблем, в роутинге, чтобы решать их таким способом, как это делается в трендовых, на данный момент, Framework. Роутеры это ненужная сущность. Нужно всегда оценивать потенциальную частоту использования кода, в той или иной форме, прежде чем проектировать сущности.
опубликовано ENERGY - 18 Jul 2018 03:14 GMT
последнее редактирование - 21 Jul 2018 09:44 GMT
 +  0  -  комментировать