Проблема выбора архитектуры и структуры

Мы планируем переписать одно из наших фундаментальных приложений. Это веб-интерфейс, и мы заперты в PHP. Однако это не веб-сайт. Это ближе к корпоративному приложению.

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

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

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

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

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

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

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

Итак, мои вопросы таковы:

Я прав в своей озабоченности? Или они правы, и я просто перечувствую?
Если я прав, есть ли какие-либо рекомендации относительно того, как справиться с ситуацией?
Как я могу получить команду на моей стороне, не вызывая мятежа?

Ответ 1

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

Что касается получения команды на вашей стороне, существует множество решений, потому что существует множество причин сопротивления.

Я рекомендую эту книгу: Вождение технических изменений: почему люди в вашей команде не действуют на хорошие идеи и как убедить их в том, что они должны Терренс Райан. Это скоро появится, но вы можете заказать бета-электронную книгу сразу, и это относится к окончательной электронной книге, когда она готова.

(отказ от ответственности: я рассмотрел проект этой книги и опубликовал ту же компанию, которая выпустила мою собственную книгу.)

Ответ 2

У меня возникли проблемы с изображением архитектуры высокого уровня без подробной информации, но для чего это стоит:

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

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

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

Если у вас на самом деле нет власти над ними (и даже если у вас есть), попросите их пошутить на вас в течение ограниченного времени. По моему опыту, архитектурные недостатки и проблемы, как правило, выходят довольно быстро, как только вы входите в него ( "Нам нужно сделать xyz. Как мы это делаем в Framework X?" ). Интенсивный сеанс моделирования сценариев (и проблем) может заставить людей хотеть дважды подумать о той платформе, которую они выбирают.

Ответ 3

Я бы сказал, что вы оба правы. Учитывая, что архитектура в порядке. Но архитекторы часто склонны перегружать вещи. Это не редкость для разработчиков обвинять архитекторов в жизни в башне Слоновой Кости, пока они спускаются в окопы. Однако, находясь в траншеи, довольно низко вниз, поэтому разработчики часто не видят леса для деревьев, что может привести к столь же нежелательным ad-hoc-архитектуре или островным решениям, которые не слишком хорошо соединяются.

Что касается фреймворков, обеспечивающих архитектуру более высокого уровня уже, ну да. Они делают. Но это не значит, что вам нужна архитектура. То, что вы найдете в рамах, (надеюсь), смоделировано после установленных шаблонов проектирования. В шаблонах проектирования предлагаются решения общих проблем. Если вам не нужно решать эти проблемы, вы также не используете их. Это неправильный выбор. Теперь, это довольно общее, но вы получаете идею.

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

Ответ 4

Попросил ли кто-нибудь из других разработчиков применить приложение в YII, подобное тому, которое требуется для сборки сейчас? Если нет, то у вас есть хоть какие-то основания для отталкивания и а) выяснить, какие сильные и слабые стороны YII (попросите их рассказать вам) и b) как они соответствуют требованиям вашего проекта.

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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