Некоторые предложения по стилю бизнес-кода PHP

Автор оригинала: David Wong.

1. При повторном вызове в цикле

   Пример кода:

   Вышеуказанные блоки кода имеют очень серьезные проблемы.

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

   Таким образом, приведенный выше код может быть преобразован в:

   Другим примером является:

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

   Приведенный выше код может быть изменен следующим образом:

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

   Содержание документа должно быть размещено вне обращения.

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

2. О удобочитаемости вызовов классов или методов на бизнес-уровне.

   В связи с этим давайте сначала рассмотрим пример кода:

   Call_user_func, call_user_func_array, класс отражения и т. Д. Могут напрямую создавать экземпляры или вызывать некоторое содержимое переменных, Что, по-видимому, не является проблемой при компиляции и работе машины, но люди будут более обеспокоены, если они посмотрят на это. Вам нужно вернуться к источнику, чтобы узнать, что вызывается и что отражается, хотя это очень просто написать. Грубо, но не дружелюбно по отношению к читателю. Более того, даже мощная среда разработки, такая как phpstorm storm, не может помочь вам определить источник отслеживаемости.

   Поэтому бизнес-код должен стараться избегать использования аналогичного кода.

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

3. О составлении вспомогательных методов

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

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

   Например, если вы хотите получить возврат JSON в Yii2, вам нужно написать следующий код:

   Если вы напишете дополнительный метод следующим образом:

   Тогда код может быть написан следующим образом:

   Например, получите все параметры, представленные сообщением:

   Ассистентские методы заключаются в следующем:

   Вызов заключается в следующем:

   Например, уничтожьте значение в массиве по ключу.

4. О повторном использовании и удобочитаемости логических блоков

   Например:

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

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

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

   В приведенном выше фрагменте кода dataList В будущем другие функции могут использовать тот же метод для получения соответствующих данных. данные['field1'] Это также должен быть независимый метод для выбора значения данных['field1'] Суждение также должно быть независимым методом. Это требует декомпозиции кода, которая не только обеспечивает простоту кода, возможность повторного использования и читабельность, но также позволяет избежать накопления множества бесполезных переменных в логическом блоке.

   В логике кода функция должна быть реализована одним методом, а метод должен выполнять только одну вещь.

   После разделения этого кода он станет следующим:

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

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

5. Предложения по стилю написания публичного метода

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

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

6. Загрузка страницы с помощью выделенного файлового сервера

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

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

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

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

   Файловые серверы могут использовать облака объектов.