Каковы преимущества / недостатки монолитного PHP-кодирования по сравнению с небольшими специализированными PHP-скриптами?

Question

Я исторически использовал монолитный подход к кодированию PHP.

То есть я пишу один index.php со средним размером 70k-250k и использую

mod_rewrite

чтобы превратить остальные

REQUEST_URI 

в параметры, передаваемые в index.php для управления происходящим.

Альтернативой может быть написание множества небольших php-скриптов, каждый из которых предназначен для определенной цели. Я думаю, что некоторые из моих более активных сценариев ajax могут извлечь из этого пользу.

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

Я вообще избегал включений, если это возможно, из-за моей паранойи по этому поводу, но это приводит либо к дублированию кода, либо к сохранению монолитности.

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

Я с нетерпением жду ваших комментариев.

РЕДАКТИРОВАТЬ: одно из моих целевых приложений в настоящее время обрабатывает 80-100 страниц в секунду (у меня есть приличное оборудование) Большинство из них - запросы ajax. Все работает и быстро, но я разработал PHP-программист без критики и мне это нужно.

Answer 1

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

Answer 2

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

Переработка - это отходы. Копирование и вставка кода из одного приложения в другое - адское обслуживание.

Answer 3

В дополнение к другим комментариям (с которыми я полностью согласен), еще одно мнение: я понял, что монолитный подход, если его приводить к крайностям, стоит ценной оперативной памяти - весь файл должен быть загружен для интерпретации, неважно, нужно ли все из этого или нет, и это само по себе съедает много из 8, 16 или 32 МБ, которые вы получаете за экземпляр.

Answer 4

Пожалуйста, не забывайте о тестировании и обслуживании кода. Я не могу представить, если вы можете написать юнит-тесты для проекта, который находится в одном файле. Более того, гораздо сложнее предсказать, какая функциональность может быть нарушена только что внесенными изменениями. В случае модульной архитектуры, если вы меняете какой-либо модуль, вы можете разбить только этот модуль и модули, которые зависят от него. Даже небольшие изменения могут быть фатальными для проектов с одним файлом (вы можете забыть закрыть цитату, которая разорвет все страницы сразу). Я думаю, что вы должны повторно протестировать всю функциональность даже после небольших изменений, которые мы внесли. И это может быть проблемой для тестировщиков, особенно если вы не можете использовать юнит-тесты.

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

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

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