PunBB + PE

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

Стартовая точка — движок форума FluxBB v1.4. Это очень простой и надежный форум без излишеств.

Характеристика улучшаемой системы:
Изначально проектировался как "движок, который каждый будет настраивать под себя", а не как готовое законченное решение. В нем нет механизма плагинов, все изменения предполагаются как "моды", т.е. инструкции по добавилению нового кода в существующий. Движок писался под PHP 4 и практически не содержит классов. (Одно исключение: класс базы данных — в зависимости от конфигурации порождается объект работы с БД MySql, Postgres или Sqlite) Как следствие, повсеместно используются глобальные переменные и константы. В то же время код выглядит аккуратным написанном в едином coding standard и он неплохо справляется со своей задачей. Форум быстрый и умеет почти все, что требуется от форума: поддерживает многоязычность интерфейса, имеет встроенный поиск и управление правами групп, есть кеширование. В зачаточном состоянии есть шаблоны вывода. За годы существования накоплено большое количество модов.

Цели улучшения:
Сделать ядро движка более приспособленным для будущего расширения. Моды должны успупить место плагинам (хуки, события). Глобальных переменных быть не должно. Вывод страницы надо выделить из основного кода в отдельные модули представления. Можно сказать, что улучшение — это внедрение ООП в старый код.

Прогресс:
1. Волшебная таблетка: "суперкласс" конфигурации приложения. Вместо глобальных переменных и констант будет обращение к кнфигурации. Когда нужно подключить дополнительный класс это сделает автозагрузчик класса. Когда нужно получить общую переменную или объект мы будем получать его через метод суперкласса. Из кода должны исчезнуть операторы include|reqire и global и некоторое количество проверок. Вместо:

global $db, $lang_forum;

будет

$db = Qb::loadDb();
$lang_forum = Qb::loadTranslation('forum');

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

2. Для большего контроля создадим перехватчик ошибок и протоколирование. Конструкции вида

$db->query("sql") or error("message")

уйдут. Вместо них при неудачном запросе возникнет исключение внутри самого query(), а глобальный перехватчик исключений выполнит запротоколирует ошибку.

3. Сейчас текст запросов к БД формируется путем склейки строки. Чтобы избежать SQL-injection применяется обращение к $qb->escape()

query('SELECT * FROM '.$db->prefix.'forums AS f WHERE f.id='.$db->escape($id))

Заменим эту технику на шаблон запроса с "плейсхолдерами":

query('SELECT * FROM :p_forums WHERE f.id=:id', $id)

.
Затем вместо явного написания SQL в теле модуля переходим к именованным запросам. Зависимость от диалекта SQL спрячем, как это делается для "языковых констант". Что-то вроде техники gettext().

query('Get forum', $id)

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

5. Вводим понятие "событие". На событие через конфигурацию можно навесить обработчик. Таким образом обходимся без модов.

6. Весь код, порождающий HTML выносим в модули представления. Постепенно переводим этот код на более удобные шаблоны.

RServer    о, это философский вопрос, а вообще то artoodetoo выше уже ответил на него.