Должна ли компания обеспечивать использование единой архитектуры во всех усилиях по разработке? - PullRequest
0 голосов
/ 12 февраля 2009

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

Небольшая предыстория: я разрабатываю и поддерживаю большое зрелое приложение (VFP для пользовательского интерфейса, Oracle PL / SQL для среднего и внутреннего сегмента), которое используется исключительно внутри компании. Я спрашивал своих начальников о переписывании пользовательского интерфейса на C #, но мне сказали, что все будущие усилия по разработке должны быть сделаны на Java / Spring. Я объяснил, что количество усилий при переходе от настольного приложения к веб-приложению будет значительно больше, чем простой переход на C #. Я также объяснил, как весь интерфейс должен подвергнуться серьезной переработке, чтобы перейти на веб-браузер. Наконец, я объяснил, что это приложение используется только внутри компании, поэтому при использовании веб-архитектуры не будет такой большой выгоды, как это получит внешнее приложение. К сожалению, мои аргументы не поколебали их.

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

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

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

Ответы [ 5 ]

2 голосов
/ 12 февраля 2009

Чтобы быть справедливыми, вопрос, как указано что-то из соломы людей аргумента. Конечно, ответ будет нет , если мы примем условие «независимо от стоимости» буквально.

РЕДАКТИРОВАТЬ : OP удалил формулировку "независимо от стоимости", однако остальная часть моего ответа все равно должна применяться.

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

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

1 голос
/ 12 февраля 2009

Я согласен с вами и Робом Уэллсом, что плохая идея применять единую доктрину архитектуры. Единственное, что может сработать в этом случае, - это провести анализ стоимости каждого решения (Java Vs. C #) и представить им фактические цифры и убедительные доказательства. Вы также можете попытаться увидеть, есть ли какие-либо тематические исследования. Если они недоступны, возможно, вы захотите узнать, не сделала ли какая-либо другая компания что-либо подобное, изучить ее последствия и использовать ее, чтобы убедить свое руководство. Тем не менее, это может быть больше работы, чем кодирование на Java (шучу :)). Я желаю вам удачи в убеждении вашего руководства.

0 голосов
/ 12 февраля 2009

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

0 голосов
/ 12 февраля 2009

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

Выбор Java и веб-приложений - это не обязательно только один язык.

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

Причины для этого могут включать

  • Необходимость в обучении людей только на одном языке и наборе инструментов
  • Облегчение перемещения людей между проектами, поскольку технология аналогична.
  • Упрощение обслуживания, так как персонал, работающий над приложением позже, не должен знать несколько языков.
  • Нет необходимости покупать инструменты (IDE, браузеры рефакторинга и т. Д.) Для нескольких языков
  • Упрощение использования рабочих столов, отличных от Windows
  • Сокращение эксплуатационных расходов на поддержку приложения (например, не нужно устанавливать настольные системы или сокращать количество технологий, которые им необходимо знать)
  • ИТ-директор получает откаты от поставщиков инструментов Java:)

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

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

0 голосов
/ 12 февраля 2009

номер

Это все равно что идти к архитектору, который может работать только с бетоном.

Вы можете наложить только одно решение на все проблемные пространства.

Редактировать: Имейте в виду, было бы очень трудно убедить любое руководство в том, что достойная рентабельность инвестиций возникнет в результате переписывания зрелой системы.

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