суббота, 22 января 2011 г.

Неофициальная история конструирования ПО

В начале, был один ярус, и это было хорошо . В бородатых восьмидесятых, был один мейнфрейм и тысячи «немых» терминалов пользователей, которые были подключения к одной и только одной Большой Железяке. Эти 3270 терминалов называли «немыми», потому что у них была только клавиатура и монитор. Без процессора. Это было просто устройство ввода / вывода.


Два яруса . Благодаря Биллу Гейтсу, компьютеры, в комплекте с их собственными процессорами, ушли в массы, а в конце 80-х и начале 90-х я был разработки клиент-серверных приложений с "толстым клиентом" — часть расчетов осуществлялась на локальной машине, а данные находились в базе данных на уделенном сервере. Жизнь была легкой и простой. И резюме разработчиков были точно такими же легкими и простыми. Вам было только необходимо знать SQL для работы с данными и какой-нибудь язык программирования. Вот, например C++… Ах, Вам тяжело его изучить? Используйте SQLWindows, PowerBuilder, Visual Basic или даже Delphi!
Основной темой для обсуждения была: где реализовывать бизнес-логику — на стороне клиента или в базе данных, как набор хранимых процедур? В последнем случае, вы были вынуждены мастерски владеть процедурными языками СУБД, например, такими как T-SQL или PL/SQL. Но, больше от Вас ничего не требовалось.
Архитектура приложений по-прежнему оставалась простой. При запуске, приложение не требовало от вас подключения к Интернету, и это было хорошо. Приложения запускались на локальном компьютере, и работало в локальной сети. Конечно же, если сервер баз данных падал или слишком многие пользователи одновременно хотели получить данные, то в работе Вашего локального приложения могли бы возникнуть проблемы и перебои. Но, это было единственное узкое место, да и случалось такое не каждый день.

Три яруса. В середине девяностых годов, создание веб-браузеров, открыло Интернет для общественности. Предприятия с нетерпением переделывали их проверенные и надежные клиент-серверные системы для того, чтобы просто сделать их доступными в Интернете. Зачем? Потому что они могли это сделать. Именно с этого момента все начало усложнятся. Тонкий HTML клиент взаимодействовал веб-сервером, либо мог предоставлять статический контент (тексты, изображения), не используя для этого к помощи стороннего ПО, а при необходимости, можно легко передать управление на другой сервер для более продуктивной работы. Интернет провайдеры предлагали пропускную способность для продажи. Сетевые соединения были медленными. Тонкие клиенты выглядели очень плохо по сравнению с толстыми клиентами на Visual Basic или PowerBuider.
Вопрос остался прежним: «Где размещать бизнес-логику?» Уж точно не на тонком клиенте. Теперь выбор был либо где-то веб-сервере или в СУБД. Одного только веб-сервера уже было недостаточно. Так как я сам из мира Java, то хочу объяснить Вам, что же там происходило.

Множество ярусов . Средний ярус превратился в несколько уровней. Веб сервер взаимодействовал со Сервлет-контейнером, который в свою очередь взаимодействовал с контейнером EJB, который либо работал с СУБД непосредственно либо просто помещает сообщение в очередь Message-Oriented Middleware. Чтобы сделать это еще более гибким, добавьте в коктейль несколько служб контроля доступа, так чтобы Java сначала посмотрела туда, перед тем как поместить сообщение в очередь. Давайте не будем забывать и о демилитаризованных зонах (DMZ), которые увеличивают общее число ярусов.
Вот когда появилось Новое Поколение Разработчиков. Эти люди, называющие себя Архитекторами программного обеспечения. Они требовали чтобы логические слои были специфичны и заточены под разрабатываемый проект. И они хотели их сейчас! Книга по шаблонам проектирования от «банды четырех» была легко доступна, — и шабаш начался.

Это было время расцвета фреймворков для создания ПО.

Если разработчик Java не знал Struts в начале этого века, то его шансы быть нанятым для разработки Enterprise проектов были близки к нулю. Сейчас все больше и больше людей понимают, что Struts был еще одним недопеределанным бесполезным MVC фреймворком, который усложнял архитектуру тысяч приложений. Но само существование таких фреймворков получило теплый прием и даже овации в легионах быдлокодеров (Code monkey), которые поняли, что они могут зарабатывать на жизнь, вставляя if и else в шаблоны, предоставленные местными архитекторами. Заканчивать ВУЗ для получения диплома по компьютерным наукам уже не нужно.
Первое десятилетие 21-го века подходит к концу, и мы все еще живем в очень хрупком мире программного обеспечения с дести ярусными архитектурами. Каждый дополнительный уровень (как движущуюся часть) делает архитектуру еще более хрупкой. Каждая подвижная часть покупается с дополнительными расходами — технической поддержкой. Но в мутной воде многоуровневых архитектур, команды поддержки довольно быстро начинают играть в игру перевода стрелок друг на друга.
Бюджет первоначально выделенных на проект, получает опустошается довольно быстро, владелец проекта начинает урезать функционал для экономии средств, что оставляет ему несколько кое-как работающих приложений. Это здорово, что наши офшорные партнеры готовы протянуть руку помощи! Мы в ней нуждается. Это как присланные деньги от родителей для студента, живущего в общежитии.

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

Приложение клиента запускается локально, оно имеет локальное хранилище, что позволяет работать как в онлайн, так и в офлайн режиме. И данных и код находятся настолько близко к пользователю, насколько это возможно. Вы думаете, почему Microsoft Excel является наиболее популярным программным обеспечением среди бизнес-пользователей на предприятиях? Потому что Excel позволяет пользователю иметь свой маленький кусочек данных и любительский, но рабочие код (формулы) очень близко. Прямо на рабочем столе. Нет необходимости просить этих Всемогущих Админов о милости и помощи. Нет зависимости от сетевого подключения или каких-то таинственных серверов, которые могут работать медленно или падать. Наиболее продвинутые пользователи даже научиться работать с базами данных MS Access, чтобы уменьшить зависимость от отдела IT. Так держать!


Рассмотрим пример автоматизации продаж. В настоящее время, наша компания работает над программным обеспечением, предназначенным для автоматизации работы страховых агентов. Я просто приведу один пример. Мы храним цифровые подписи клиентов в базе данных. Агент приходит в дом клиента, заполняет электронные формы и просит человека поставить подпись пальцем прямо по стеклу смартфона работающего под Android. Приложение на Adobe AIR сохраняет эту оцифрованную подпись в локальной базе данных смартфона. Как только агент сможет получить доступ к любой сети Wi-Fi, он сможет синхронизировать локальные данные с любым ПК или облаком. Разве это не в два яруса? Продавец может запустить и работать с приложением в независимости от наличия соединение с Интернетом. Когда соединение будет доступно, данные можно будет синхронизировать Уровнем 2. Вот и все. Клиент-Сервер вернулся.

Один ярус. Шансы довольно высоки, что через 10-15 лет мы снизим число уровней архитектуры обратно в один ярус превратить наши смартфоны в немые терминалы.
«Да, возможно я и мечтатель. Но я такой не один»
Джон Леннон


Оригинал: The Unofficial History of Software Engineering

Про эту замечательную статью я узнал из подкаста автора статьи Якова Файна (Будама). За что что ему спасибо. ;)

Если Вы хотите прослушать его комментарии к статье, то прошу Вас проследовать по ссылке ниже:
Америчка: #267 Неофициальная история конструирования ПО

Перевод статьи с английского на русский: Дмитрий Жарий

0 коммент.:

Отправить комментарий

 

.NET ate my MOSK;. Powered By Blogger © 2009 Bombeli | Theme Design: ooruc