Библиотека knigago >> Компьютеры и Интернет >> Базы данных >> 97 этюдов для архитекторов программных систем

Нил Форд , Майкл Хайгард , Билл де Ора - 97 этюдов для архитекторов программных систем

97 этюдов для архитекторов программных систем
Книга - 97 этюдов для архитекторов программных систем.  Нил Форд , Майкл Хайгард , Билл де Ора  - прочитать полностью в библиотеке КнигаГо
Название:
97 этюдов для архитекторов программных систем
Нил Форд , Майкл Хайгард , Билл де Ора

Жанр:

Базы данных

Изадано в серии:

Профессионально, 97 этюдов, 97 Things

Издательство:

Символ-Плюс

Год издания:

ISBN:

978-5-93286-176-9, 978-0-596-52269-8 (англ)

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

Краткое содержание книги "97 этюдов для архитекторов программных систем"

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

Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Читаем онлайн "97 этюдов для архитекторов программных систем". [Страница - 3]

подходит к текущей ситуации.

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

Всегда ставьте долгосрочные потребности клиента над своими собственными краткосрочными потребностями, — и вы не ошибетесь.


В начале 1990-х Нитин Борванкар (Nitin Borvankar) работал в Ingres и Sybase, где создавал первые веб-приложения на базе SybPerl и OraPerl, а вскоре после этого — на базе ранних версий Enterprise Java. Он также был активным участником New-EDI — процесса IЕТF-стандартизации[1] EDI в Интернете. С 1994 года работал, независимым консультантом и исследователем в области организации и интеграции данных в масштабах предприятия, а также обмена сообщениями. В настоящее время занимается схемами баз данных для приложений с фолксономической[2] организацией контента в системах масштаба предприятия, а также проблемами сопровождения БД в социальных сетях, находящих практическое применение в коммерческих отраслях. Входит в Policy Group проекта Data Portability, где занимается, подготовкой лицензионных соглашений и вопросами прав пользователя на владение данными. Помимо этого пишет о базах данных на сайте GigaOm.com и ведет блог http://tagschema.com. Является владельцем патента в области передачи сообщений через границы доверия (trust boundaries).

Снижайте неотъемлемую сложность, устраняйте второстепенную сложность Нил Форд

Книгаго: 97 этюдов для архитекторов программных систем. Иллюстрация № 3 Неотъемлемая сложность (essential complexity) представляет собой проблему, изначально присущую любой задаче. Например, задача координации воздушного движения в национальном масштабе является сложной сама по себе. Управляющая система должна отслеживать в реальном времени точное местоположение каждого самолета (включая высоту), его скорость, направление и место назначения, чтобы предотвратить столкновения в воздухе и на посадочных полосах. Необходимо также оперативно управлять расписаниями полетов, чтобы избежать заторов в аэропортах в постоянно меняющихся условиях — при резком изменении погоды все расписание приходится пересматривать.

С другой стороны, второстепенная сложность (accidental complexity) обусловлена теми задачами, которые, как нам кажется, необходимо решить для снижения неотъемлемой сложности. Примером второстепенной сложности может служить устаревшая система управления полетами, используемая по сей день. Система проектировалась для решения сложной проблемы управления движением тысяч самолетов, но это решение порождает свои собственные проблемы. Современные системы управления полетами настолько сложны, что само их обновление становится трудным, если не невозможным делом. Почти во всем мире управление полетами осуществляется по технологиям более чем 30-летней давности.

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

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

Как этого добиться? Отдавайте предпочтение инфраструктурам, созданным на базе работающего кода, а не в башнях из слоновой кости. Соотносите объем кода, направленного на решение непосредственной задачи, с объемом кода, который просто обслуживает взаимодействие пользователя с приложением. С осторожностью относитесь к решениям, продвигаемым фирмами-разработчиками: такие решения не всегда изначально плохи, --">

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


Ваш e-mail является приватным и не будет опубликован в комментарии.