Построение долгосрочной архитектуры приложений - PullRequest
0 голосов
/ 01 декабря 2011

Мне интересно узнать, как развиваются веб-приложения.Идея состоит в том, что если бы в веб-приложении на основе Java были внедрены новые технологии или методологии проектирования, какие 5-10 технологий стоит изучить?Также было бы полезно, если бы кто-то мог указать хорошие книги или онлайн-ресурсы для проведения этого исследования.

Ответы [ 3 ]

1 голос
/ 01 декабря 2011

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

1 голос
/ 01 декабря 2011

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

Прежде всего, знайте, с чем вы столкнулись.В конце 1960-х люди начали изучать, что происходит с приложениями с течением времени.За последние 40 лет эти наблюдения были превращены в свод законов (см. Меир Леман).Это может показаться очевидным, но это хорошая отправная точка:

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

Если вы занимаетесь этим надолго, самые большие вопросы, вероятно, организационные, а не технические.Например, какие технологии уже знают и любят использовать разработчики?Если разработчики планируют придерживаться компании в течение 5-10 лет, спросите, что именно в будущем их волнует.Лучшее место для сбора идей о «горячих» технологиях веб-приложений - http://www.infoq.com/.

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

Рассмотрим поставщиков.Однажды я работал на сайте, который представлял собой настоящий магазин IBM, потому что IBM производила надежное программное и аппаратное обеспечение.Однако клиент действительно был привязан к поставщику.В 1997 году клиент все еще использовал сети Token Ring и OS / 2. По мере необходимости предоставьте себе возможность переключать инструменты и технологии.Живое, дышащее приложение почти никогда не доживет до десятилетия использования, не переключая стеки технологий хотя бы один раз.

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

Удачи!-Aaron

1 голос
/ 01 декабря 2011

Одним из ключевых аспектов является производительность труда разработчиков. В этом пространстве были проведены отличные исследования и презентации Мэттом Райблом (в общем, не-EE-пространством) и Адамом Биеном для EE6.

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