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

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

Я бы сказал, что вы оба правы. Учитывая архитектуру это хорошо. Но архитекторы часто склонны усложнять вещи. Разработчики нередко обвиняют Архитекторов в том, что они живут в Башне Слоновой Кости, когда они находятся в окопах. Тем не менее, находиться в траншее довольно низко, поэтому разработчики часто не видят леса за деревьями, что может привести к столь же нежелательным специальным архитектурам или островным решениям, которые плохо соединяются.

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

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

Answer 4

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

Сначала я хочу сделать формальную архитектуру высокого уровня.Прежде всего,

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

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

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

Answer 5

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

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

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

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

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

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

Answer 6

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