Каковы преимущества / недостатки монолитного PHP-кодирования по сравнению с небольшими специализированными PHP-скриптами?
Исторически я использовал монолитный подход к кодированию PHP.
То есть я пишу один index.php, со средним размером 70k-250k, и использую
mod_rewrite
превратить остальную часть
REQUEST_URI
в параметры, передаваемые в index.php, чтобы контролировать происходящее.
Альтернативой может быть написание множества небольших php-скриптов, каждый из которых предназначен для определенной цели. Я думаю, что некоторые из моих более активных сценариев ajax могут извлечь из этого пользу.
Одна вещь, которая удерживала меня в этом мыслительном процессе, это то, что я не знаю, как использование включений, особенно условных включений, повлияет на производительность кэша кода операции.
Я вообще избегал включений вообще, если это возможно, из-за моей паранойи по этому поводу, но это приводит либо к дублированию кода, либо к сохранению монолитности.
В любом случае, поскольку я использую mod_rewrite, преобразование между двумя методологиями должно быть простым.
Я с нетерпением жду ваших комментариев.
РЕДАКТИРОВАТЬ: Одно из моих целевых приложений в настоящее время обрабатывает 80-100 страниц в секунду (у меня есть приличное оборудование). Большинство из них - запросы ajax. Все работает и быстро, но я разработал как программист PHP без критики и мне это нужно.
4 ответа
Модульный код легче понять и поддерживать. Огромная монолитная кодовая база может стать карточным домиком. На практике это прекрасно работает, но изменение любого из нижних элементов становится невозможным. Если вы разделите свой код на четкие абстракции, вам будет гораздо легче вносить изменения, и вы избавите себя от кошмара, если будете добавлять разработчиков.
Преимущества в производительности от неиспользования включенных файлов значительно перевешиваются простотой обслуживания и отладки большого приложения с использованием включенных файлов.
Переработка - это отходы. Копирование и вставка кода из одного приложения в другое является адским обслуживанием.
В дополнение к другим комментариям (с которыми я полностью согласен), другое мнение: я понял, что монолитный подход, если его приводить к крайностям, стоит ценной оперативной памяти - весь файл должен быть загружен для интерпретации, независимо от того, все от этого нужно или нет, и это само по себе съедает много с 8, 16 или 32 МБ, которые вы получаете за экземпляр.
Пожалуйста, не забывайте о тестировании и обслуживании кода. Я не могу представить, если вы можете написать юнит-тесты для проекта, который находится в одном файле. Более того, гораздо сложнее предсказать, какая функциональность может быть нарушена только что внесенными изменениями. В случае модульной архитектуры, если вы меняете какой-либо модуль, вы можете разбить только этот модуль и модули, которые зависят от него. Даже небольшие изменения могут быть фатальными для проектов с одним файлом (вы можете забыть закрыть цитату, которая разорвет все страницы сразу). Я думаю, что вы должны повторно протестировать всю функциональность даже после небольших изменений, которые мы внесли. И это может быть проблемой для тестировщиков, особенно если вы не можете использовать юнит-тесты.
Кроме того, если весь код, который я храню в одном файле, скорее всего, у вас будет плохой код. Такой код заставит вас использовать глобальные переменные. В этом случае трудно повторно использовать такой код в другом проекте. Конечно, вы можете скопировать его, но помните, что когда вы копируете что-то, вы копируете все его ошибки. Просто представьте себе проект, в котором вы можете использовать множество хорошо протестированных (скажем, благодаря юнит-тестам) библиотек. Когда появляется новая ошибка, она просто исправляется в одном месте.
Еще одна вещь, когда вы работаете в команде, используя один файл, будет больно. Даже если есть только 2 разработчика, они тратят много времени на объединение изменений.
В любом случае, если ваш проект совсем не большой, вы можете использовать один файл appoch.
Для сценариев командной строки Unix монолитный подход обеспечивает очень высокий уровень переносимости.
Использование одного (хэшбэнг) скрипта позволяет даже сбросить скрипт в usr/bin
sudo cp myprog /usr/bin
/* (...) */
sudo cp myprog /usr/games
/* (...) */
Это позволяет вызывать программу из любого места, с любого пути, просто набрав myprog, вместо того /PATH/./myprog. Убедитесь, что этому можно доверять!
Мы должны особенно заботиться о путях.
Несколько простых примеров о путях:
/* Create a folder in the home directory, named as the script name, if not existing. -*/
if (!is_dir($_SERVER["HOME"]."/".$_SERVER["SCRIPT_NAME"])){
@mkdir($_SERVER["HOME"]."/".$_SERVER["SCRIPT_NAME"]);
}
/* Program folder path: --------------------------------------------------------------*/
$PATH = $_SERVER["HOME"]."/".basename($_SERVER["SCRIPT_NAME"])."/";
/* Program running path, currently: --------------------------------------------------------------*/
$JOBPATH = getcwd();
Обработка сигналов POSIX
/* Register cleaning actions at SIGINT ------------------------------------- */
function shutdown() {
// Perform actions at ctrl+c
echo "Good bye!";
exit;
}
/* Register resize at SIGWINCH ---------------------------------------------- */
function consoleResize() {
@ob_start;
$W = (int)exec("tput cols"); // Columns count
$H = (int)exec("tput lines"); // Lines count
@ob_end_clean();
// Shell window terminal resized!
}
/* Register action at SIGSTOP (Ctrl + z) ---------------------------------------------- */
function sigSTOP() {
// Program paused!
}
/* Register action at SIGCONT (Type fg to resume) ---------------------------------------------- */
function sigCONT() {
// Program restarted!
}
register_shutdown_function("shutdown");
declare(ticks = 1);
pcntl_signal(SIGINT, "shutdown");
pcntl_signal(SIGWINCH, "consoleResize");
Это не означает, что мы должны записывать все в одном блоке, но объединение рендеринга в один файл дает множество дополнительных возможностей в unix env.
Можно много сказать, скрипт php as cli - потрясающий зверь.