Проблема группы выбора архитектуры и фреймворка

Мы находимся в процессе планирования переписывания одного из наших основных приложений. Он основан на сети, и мы привязаны к PHP. Однако это не сайт Web 2.0. Это ближе к корпоративному приложению.

Это ни в коем случае не просто. Есть как минимум 2 основных интерфейса (думаю, их 4, но это уже другая тема). Он должен быть одновременно настраиваемым и настраиваемым. Я ожидаю от 50 до 200 установок в год, поэтому простота обслуживания является серьезной проблемой.

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

Однако остальная часть команды хочет сначала выбрать структуру (они хотят использовать YII) и пропустить высокий уровень архитектуры полностью. Их аргумент состоит в том, что фреймворк сначала создал архитектуру высокого уровня, и позвольте вам «просто начать кодировать».

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

Я действительно опасаюсь, что мы идем по неправильному пути.

Руководство считает меня старшим. разработчик. Так что технически я могу отвергнуть большинство других. Но я не выше их, поэтому на практике делать это было бы плохо. Стоит упомянуть, что существует серьезный языковой барьер (они говорят по-польски, я говорю по-английски).

И я думаю, что должен упомянуть, что мне действительно не нравится большинство фреймворков RAD PHP. Не потому, что они плохие в любом случае, а потому, что они имеют тенденцию (ИМХО) навязывать менталитет, что архитектура не важна, поскольку они делают это за вас. Не говоря уже о том, что они обычно хотят, чтобы вы работали их путем (Rails славится этим), а не способом, который имеет смысл для текущего проекта. Поэтому я обычно использую только фреймворк как набор библиотек. Использовать классы, когда они имеют смысл, и создавать свои собственные, когда этого требуют требования проекта).

Итак, мои вопросы следующие:

  1. Прав ли я в своем беспокойстве? Или они правы, и я просто слишком остро реагирую?
  2. Если я прав, есть ли какой-нибудь совет, как справиться с ситуацией?
  3. Как я могу привлечь команду на свою сторону, не вызывая мятежа?
]
11
задан Michael Petrotta 6 September 2010 в 20:13
поделиться