avl

53. Давайте разработчикам больше полномочий

2009-12-27T19:26:00Z

(В оригинале - Empower developers)

Говорить гораздо проще, чем делать, и архитекторы ПО печально известны как раз первым. Чтобы ваши слова были не пустым сотрясением воздуха (что однако часто используется для создания vaporware*), вам нужна довольная команда разработчиков. Роль архитектора обычно заключается в установке ограничений, но архитектор может быть и тем, кто разрешает. Для этого вам нужно давать все возможные полномочия вашим разработчикам.

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

Убедитесь также в том, что у разработчиков есть все необходимые знания. Если потребуются тренинги, обеспечте их. Вкладывайте в книги и поощряйте активные дискуссии о технологиях. Рабочая жизнь программистов должна быть практичной, но при этом и активно-академической тоже. Если у вас есть средства, отправляйте команду на технические конференции и презентации. Если средств нет, используйте хотя бы тематические рассылки и бесплатные мероприятия в вашем городе. Участвуйте в отборе программистов. Ищите тех, кто хочет обучаться, кто старается основательно разбираться в технологиях (при этом убедитесь, что они способны работать и в команде). Сложно ожидать выдающихся результатов от посредственных исполнителей.

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

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

Автор оригинала - Timothy High

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

52. Фиксируйте обоснования

2009-12-26T18:29:45Z

(В оригинале - Record your rationale)

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

Один из способов документирования, не требующий больших усилий и почти всегда окупающийся – запись логических обоснований принятия решений при проектировании. Как объяснялось в статье «Все сразу получить невозможно», архитектура – это набор принятых решений о выборе той или иной возможности из факторов качества, стоимости, времени и других характеристик. И должно быть ясно как для вас, так и для вашего руководства, разработчиков и других заинтересованных сторон, почему было принято то или иное решение, и какие альтернативы оно затрагивает (Пожертвовали ли вы масштабируемостью для снижения стоимости аппаратной части и лицензионного ПО? Безопасность настолько важна, что для ее обеспечения допустимо было повысить время реакции системы?)

Точный вид такой документации может произвольно меняться в зависимости от требований проекта, начиная от заметок в текстовом файле, wiki или блоге до использования формальных шаблонов для записи всех возможных аспектов принятых архитектурных решений. Но каким бы ни был формат, документация должна давать ответ на вопросы «Какое решение было принято» и «Почему это решение было принято». Второй вопрос, часто задаваемый, и который поэтому тоже должен быть задокументирован – «Какие альтернативы были рассмотрены, и почему они не были приняты» (обычно такой вопрос задают в форме «Почему мы не реализуем мое решение»). Документация также должна быть удобной для поиска, чтобы ответ на нужный вопрос было всегда легко найти.

Такая документация может оказаться полезной во многих разных ситуациях:

Как способ коммуникации с разработчиками по поводу важных архитектурных принципов, которым они должны следовать
Для предотвращения «мятежа» разработчиков, когда они захотят получить ответ на вопрос о логике, стоящей за архитектурой (или даже для скромного принятия критики, если эта критика не приводит к отмене решения в результате его пристального рассмотрения)
Чтобы показать менеджерам и заказчикам, почему ПО было сделано именно так, как оно сделано, включая дорогие части аппаратных и программных компонент
При переносе проекта на новую архитектуру (как часто вам доставался в наследство кусок ПО вместе с желанием понять, почему дизайнер сделал его именно так?)

Однако, самые важные плюсы этой практики – это то, что:

Вам приходится явно указывать причины для того, чтобы убедиться, что ваши обоснования целостны (смотри статью «Проверяйте предположения»)
Результат может использоваться как стартовая точка для пересмотра решения, когда условия, повлиявшие на предыдущее решение, поменяются.

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

Автор оригинала - Timothy High

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

51. Проверяйте предположения, особенно собственные.

2009-12-25T19:15:13Z

(В оригинале - Challenge assumptions - especially your own)

"Предположение – причина большинства неудач", или более популярно: "Don’t assume – it makes an 'ass' of 'u' and 'me', что в дословном переводе звучит как «Предположения делают из нас ослов», увы, не передавая замечательную игру слов оригинала. И когда речь заходит о предположениях, за которыми стоят тысячи или даже миллионы долларов, то вышеприведенная фраза – уже не просто смешная шутка.

Одна из хороших практик разработки ПО – документировать причины того или иного решения, особенно когда за решением стоит компромисс (производительность или сопровождаемость, стоимость или время выхода на рынок и т.п.). Также можно записывать и контекст того или иного решения, включая факторы, повлиявшие на окончательное решение. Факторы могут быть функциональными или нефункциональными требованиями, а также могут быть просто «фактами», важными для принимающих решение (ограничение технологии, доступный уровень знаний, политическая ситуация и прочее).

Эта практика хороша тем, что когда эти факторы перечислены, то это может помочь выделить те предположения, которые были у архитектора, ответственного за разработку ПО. И часто эти предположения основаны лишь на «исторических причинах», традициях разработки, FUD-е или же даже на «Я где-то что-то об этом слышал»:

Open source проекты недостаточно надежны
Bitmap индексы приносят больше проблем, чем пользы
Заказчик никогда не согласится, что страница грузится пять секунд
Директор согласится только на продукцию крупного вендора

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

И не игнорируйте слово «релевантный». Иногда то, что было истинным в предыдущих версиях, не является таковым сейчас. Производительность bitmap-индексов в одной версии Oracle может отличаться от производительности в другой версии. Старая версия библиотеки могла иметь дыры в безопасности, исправленные в новой версии. Ваш поставщик надежного ПО может быть на грани банкротства. Технологии меняются каждый день, и с ними меняются и люди. Возможно, ваш шеф завтра станет фанатом Linux.

Факты и предположения – основа, на которой строится ваше ПО. Какими бы они ни были, будьте уверены в том, что они согласованные.

Автор оригинала - Timothy High

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

50. Границы и интерфейсы

2009-12-24T19:59:12Z

(В оригинале - Architects focus is on the boundaries and interfaces)

C тех пор как Нельсон разбил флот Испании и Франции в Трафальгарском сражении, «Разделяй и властвуй» стало девизом при решении сложных проблем. Более простая формулировка, означающая почти то же самое – разделение интересов. Разделение интересов дает нам инкапсуляцию, а инкапсуляция приводит к появлению границ и интерфейсов.

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

И здесь приходит на помощь концепция ограниченных контекстов и их отображений, описанная в книге Эрика Эванса “Domain-Driven Design”. Ограниченный контекст – это область, в пределах которой модель или концепция однозначно определены, обычно представляемая в виде облака с информативным названием, определяющим ее роль и ответственность в предметной области. Например, в системе доставки могут быть такие контексты как «Погрузка», «Расписание» и «Доставка морем». В других предметных областях будут другие имена.

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

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

Автор оригинала - Einar Landre

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

49. Знакомьтесь, архитектор Янус.

2009-12-23T13:38:07Z

(В оригинале - Janus the Architect)

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

Для каждого архитектора возможность Януса смотреть как в прошлое, так и в будущее – очень желаемый навык. Архитектор старается соединить видение и реальность, прошлые успехи и направления развития, ожидания заказчиков и руководства с ограничениями разработки. Создание таких мостов – основная часть работы архитектора. Часто архитектор может чувствовать себя пытающимся объять необъятное в процессе ведения проекта из-за большого количества различных сил, действующих в рамках проекта. Например, конфликт требований безопасности и простоты доступа, или удовлетворение сегодняшних бизнес-процессов и видения будущего. Хороший архитектор должен, как и Янус, иметь две головы, могущих одновременно думать две мыслы, чтобы быть способным создать проект, максимально удовлетворяющий столь разным требованиям.

Обратите внимание, что у Януса две полноценные головы, а не два лица. Это дает ему еще одну пару ушей и глаз, улучшая его информированность. Хороший ИТ архитектор должен быть замечательным слушателем и аналитиком. Понимание целей инвестиций критически важно для определения видения руководства относительно будущего вашей организации. Способность соотнести технические знания вашей команды с дизайном и используемыми на проекте технологиями поможет в создании эффективного процесса обучения и разработки и для успешного завершения проекта. Информация о доступных open source решениях вместе с программными инструментами может сильно повлиять на сроки сдачи и стоимость проекта. Хороший архитектор обязательно воспользуется возможностями этих готовых «составных частей» в нужных местах жизненного цикла проекта.

Есть менеджеры, ожидающие и требующие от архитекторов наличия «божественных» качеств чуть ли не в буквальном смысле слова. Сравнение же архитектора с Янусом говорит немного о другом. Хороший архитектор должен быть открытым для новых идей, инструментов и решений, способствующих движению вперед. Архитектор не должен тратить все свое время на менеджерские совещания или на написание кода лично. Вместо этого он должен принимать хорошие идеи и культивировать атмосферу, в которой эти идеи появляются. Архитектор должен обладать открытым разумом, способным сбалансировать множество разнонаправленных сил, тянущих проект в разные стороны. Все архитекторы стараются достигнуть успеха в выполнении проекта. А лучшие архитекторы стараются построить системы, выдерживающие проверку временем – системы, способные легко расширяться в будущем по мере роста организаци или изменения технологий. Такие архитекторы отслеживают и при необходимости меняют свои процессы, решения и методы для достижения максимального успеха. Они стараются гарантировать то, что их продукты устоят перед грядущими изменениями.

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

Автор оригинала - Dave Bartlett

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

48. Наблюдение вместо контроля

2009-12-21T22:51:13Z

(В оригинале - Don't Control, but Observe)

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

Таким образом, затратить усилия на построение гибкой и эволюционирующей системы – это хорошая идея. Но это также означает и то, что наша система будет постоянно меняться со временем. Система сегодня уже не будет такой, какая она была вчера. К сожалению, это делает документирование системы очень нетривиальной задачей. Хорошо известен факт, что документация устаревает в тот момент, когда отправляется на печать. Но для постоянно меняющейся системы все еще гораздо хуже. К тому же если система гибкая, то это также означает и то, что она достаточно сложна, и как следствие, сделать пресловутую “big picture” тоже будет сложно. Например, если все компоненты системы связываются друг с другом при помощи логических, конфигурируемых каналов, то лучше посмотреть на конфигурацию каналов, чтобы понять, что происходит. Отправка сообщения без понимания системы вряд ли приведет к ошибке компилятора, но наверняка расстроит пользователя, чьи действия были инкапсулированы в этом сообщении.

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

Во многих случаях получившуюся модель легко визуализировать. Однако сопротивляйтесь искушению нарисовать плакат 3 на 5 метров, весь заполненный квадратиками и линиями и содержащий каждый класс в вашей системе. Получившаяся картина может занять призовое место на выставке современного искусства, но не будет являться пригодной к использованию моделью. Вместо этого, используйте вид с высоты 300 метров, описанный Эриком Дорненбургом – уровень абстракции, который может реально показать полезную информацию. В результате вы сможете также убедиться, что модель соответствует определенным правилам, например, что в ней отсутствуют циклические зависимости или что никто не посылает сообщения в канал, который никем не прослушивается.

Потеря контроля – ужасная вещь, даже если речь идет об архитектуре ПО. Но если это дополнить наблюдением, извлечением модели и проверкой на корректность, то в результате получится способ проектирования 21-го века.

Автор оригинала - Gregor Hohpe.

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

47. Добро пожаловать в реальный мир!

2009-12-20T21:25:46Z

(В оригинале - Welcome to the Real World)

Инженеры любят точность, особенно это характерно для программистов, живущих в мире нулей и единиц. Им приходится работать с бинарными выборами: ноль или один, true или false, да или нет. Все ясно и согласованно, гарантируемо атомарными транзакциями, ограничениями и контрольными суммами.

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

Более того, широко распространенные системы вносят еще больше несоответствия. Сервисы могут быть недоступны, могут меняться без предварительного оповещения об этом или не поддерживать транзакции. Когда вы запускаете приложения на тысячах компьютеров, то сбой – это лишь вопрос времени. Эти системы слабо связаны, асинхронны, параллельны и не всегда поддерживают транзакционную целостность. И вам придется с этим жить.

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

Звучит ужасно и совсем не так, к чему вы готовились? К счастью, реальный мир справляется с такими же задачами вот уже очень долгое время: задержанные письма, невыполненные обещания, платежи, отправленные не по адресу – примеры можно перечислять бесконечно. И людям приходится отправлять письма повторно, игнорировать неправильные заказы или просить не обращать внимание на напоминание о платеже, если платеж уже выполнен. Поэтому не осуждайте реальный мир за вашу головную боль, а используйте его подсказки для нахождения решений. В конце концов, Starbucks тоже не используют методологию двухфазового коммита в своем процессе. Добро пожаловать в реальный мир!

Автор оригинала - Gregor Hohpe.

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

46. Борьба с повторами

2009-12-17T16:34:28Z

(В оригинале - Fight repetition)

Ваши разработчики выполняют повторяющиеся задачи, не задумываясь? В вашем коде встречаются повторяющиеся фрагменты? А код, написанный в стиле «Копипаст»? Если да, то ваша команда движется вперед гораздо медленнее, чем могла бы, и как ни странно, возможно, что причина этого – вы сами.

Перед объяснением почему, давайте сначала согласимся с несколькими утверждениями о разработке ПО:

Повторение – это зло.
Повторящаяся работа замедляет процесс написания ПО.

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

Но в вашей системе ничего этого нет, не так ли? Тогда посмотрите внимательней на конфигурационный файл. Что изменится, а что останется, если его применить к другой части системы? Посмотрите на прослойку бизнес-логики. Есть ли там шаблон, повторяющийся от метода к методу, вроде обработки транзакций, логирования, аутентификации или аудита? А если посмотреть в уровень доступа к данным? Не найдется ли там кода, отличающегося лишь именами полей? Посмотрите шире. Не найдется ли нескольких строк кода, часто стоящих рядом друг с другом и оставляющих ощущение повторяемости, даже если они используются в различных местах и с разными объектами? Все это примеры повторений. Разработчики привыкают «фильтровать» повторы при просмотре кода, как только определят, в чем отличия, но даже в этом случае они все равно снижают свою эффективность. Код, написанный так, написан для выполнения компьютером, а не для чтения разработчиком.

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

И этот кто-то – это вы.

Автор оригинала - Niclas Nilsson

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

И еще из навеянного музыкой

2009-12-16T21:17:14Z

Когда-то давно, услышав понравившуюся песню, полез в инет искать, кто это и что за песня. Оказалось, "Ten Sharp", песня "You". Скачал тогда их альбом "Best" в надежде что там будет чего-нибудь не хуже. Первое впечатление было не очень - тогда я его целиком так и не прослушал, а сегодня во время этой пятичасовой поездки прослушал и его тоже.

Впечатления подтвердились. Из всего альбома до "You" не дотягивает больше ничего, хоть как-то интересных вещей - только две-три.

И уже не первый раз замечаю, что у некоторых исполнителей такой реальный, классный хит получается лишь один, а все остальное как-то совсем другого уровня. "Eagles" с их "Отелем Калифорния", "Europe" с "Final Countdown", теперь еще вот "You"... Интересно, почему вот так?

Музыкой навеяло...

2009-12-16T21:10:55Z

Перед пятичасовой поездкой за рулем решил чего-нибудь бодрящего записать на диск, чтоб спать не хотелось. Выбор пал в том числе на Notre Dame De Paris - английскую и русскую версии. Свою задачу прогонять сон это произведение отлично выполнило. А в процессе прослушивания обратил внимание на такую деталь.

В английской версии Belle они просят у Люцифера "and run my fingers through her hair Esmeralda", а в русской версии - уже "я душу дьяволу продам за ночь с тобой".

Французского к сожалению я не знаю, но стало интересно, что же там в оригинале :) Вот тут вроде бы подстрочный перевод французского текста: "О, Люцифер! О, дай мне хоть раз дотронуться до волос Эсмеральды". И получается, что английский вариант гораздо ближе. А в русском варианте уж очень смелая замена "дотронуться до твоих волос" на "ночь с тобой" получилась.

45. Давайте учиться у архитекторов зданий

2009-12-15T22:17:32Z

(В оригинале Learn from Architects of Buildings)

«Архитекрура — это социальный акт и материальный театр человеческой активности» - Спиро Костоф.

Сколько архитекторов ПО видят свою роль исключительно или в основном технической? Не должны ли они быть сильнее вовлечены в коммуникации и споры между заинтересованными сторонами? Сколько предположений ими выдвигается на основании чистой теории, без учета человеческого фактора?

«Хороший архитектор — не тот, кто следует по пути разума, а тот, кто следует зову сердца» - Франк Ллойд Райт.

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

«Доктор может похоронить свою ошибку, а архитектор может лишь посоветовать посадить виноград» - тот же автор.

Не является ли техподдержка устаревших систем именно этим виноградом? Хватит ли у вас в роли архитектора силы духа уничтожит кусок работы, завершившийся провалом? Или предпочтете его спрятать? Райт также говорил «Лучший друг архитектора — кувалда». Что вы «уничтожали» в последний раз?

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

Вместо «Бог» читайте «Заказчик»

«В архитектуре, как в любом другом искусстве, финал должен задавать направление движения. Финал — это хорошее строение. Хорошее - значит ценное, устойчивое и приносящее удовольствие» = Генри Ваттон.

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

«Тот, кто не является художником или скульптором, не может быть архитектором. Он всего лишь строитель» - Джон Рускин.

Играет ли художественность хоть какую-то роль в вашей работе архитектором ПО? Собираете ли вы компоненты в систему, руководствуясь художественным чувством формы, равновесия и движения?

И наконец, цитата, не требующая комментариев, лекарство от самой разрушительной болезни архитекторов ПО.

«Звучит парадоксально, но все же в этом заключена важная правда. Архитектура не может быть выдающейся, если она идеальна» - тот же автор.

Автор оригинала - Keith Braithwaite

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

44. Гномы, эльфы, маги и короли

2009-12-14T15:47:12Z

(В оригинале - Dwarves, Elves, Wizards, and Kings)

В книге «Cryptonomicon» Randy Waterhouse приводит свою классификацию персонажей.

Гномы – трудолюбивы, старательно работая над созданием удивительных артефактов в своих темных пещерах. Они затрачивают невероятные усилия, двигая горы и меняя рельеф, и славятся своим мастерством.
Эльфы – элегантные, культурные, и проводят дни, создавая прекрасные магические вещи. Они настолько одаренные, что даже не понимают, что остальные расы считают эти вещи сделанными в других мирах.
Маги – невероятно сильны, и в отличие от эльфов, понимают магию, ее силу и природу, и способны применять ее с потрясающей эффективностью.

Однако есть еще и четвертый тип персонажей, на который Waterhouse ссылается, но явно не упоминает. Это короли – провидцы, знающие, как управлять всеми остальными расами.

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

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

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

Автор оригинала - Evan Cofsky

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

Микрософт + Fujitsu = очередной развод

2009-12-13T19:25:44Z

На сайте fujitsu можно прочитать о бесплатном апгрейде висты до вин7 для покупателей компутеров с предустановленной вистой. Кнопка "узнай больше" прямо таки просит ее нажать. И что же увидит там наивный покупатель, которому повезло купить ноутбук от fujitsu с предустановленной вистой?

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

Если в этот момент он еще не заподозрит неладное, и все же решит заплатить несколько евро за создание и доставку, и перейдет в раздел заказа этого бесплатного апдейта, то там он с удивлением узнает, что:
- стоимость создания носителя составляет 24.95 евро (да-да, речь идет о записи образа на диск!);
- стоимость доставки зависит от страны, скажем, для Словении это 18 евро, для Украины - 59 евро, для России - 61 евро (интересно, а обычной почтой почему не воспользоваться за цену в десять раз ниже?).

Вот такой вот "бесплатный" апдейт получается. Кстати, придти в магазин и купить там официальный апдейт, уже записанный на официальном диске, будет стоить 99 евро. Бесплатный же апдейт жителю Украины обойдется всего лишь в 83.95 евро. Как по мне, "бесплатным" это назвать сложно. Слово "бесплатный" должно означать именно то, что оно означает - а именно то, что платить не придется ничего. Просто сделать так, чтобы можно было скачать апдейт в виде образа диска - и все, никакого создания носителя и пересылки. А то, что предлагает fujitsu, называется словом "развод" :) Только одно дело, когда этим приемом пользуются представители "канадских компаний", и совсем другое - когда те же приемы используют солидные корпорации...

Винда - неиссякаемый источник примеров того, как делать не надо

2009-12-13T10:45:15Z

Казалось бы, элементарная задача - отобразить список файлов. Упорядоченный список. Но и тут разработчики винды постарались добавить креатива.

Итак, открываем windows explorer, выбираем любую папку, в которой много файлов, и выбираем режим показа "small icons". Получаем что-то вроде этого:

Что же тут не так? А вот что. Попробуйте на картинке выше найти файл Р2210492. Насколько быстро это у вас получилось? Глаза вам свое "фе" не сказали? :) И это ведь при том, что список отсортирован!

То, что шапка быстрого выбора сортировки подходит лишь к виду "details", так и быть, простим. Возможно, там действительно сложно что-то лучше придумать. Но чем руководствовался тот, кто сделал такой вывод файлов, по горизонтали и при это с группировкой по вертикали, оставляя широченные пространства между столбцами, остается загадкой. Чтоб что-то найти в таком выводе, приходится совершать немыслимые движения глазами:

И самое главное - что нормальное отображение в винде ведь присутствует. Стоит лишь выбрать вывод "List", как все становится на свои места, с выводом по вертикали!

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

Возможно, я конечно просто чего-то не понял, и у режима "Small icons" есть свое предназначение, и в какой-то ситуации он окажется суперудобным для какой-то задачи. Но пока я не могу ничего подобного представить. Если кто-то знает секрет, буду рад услышать о нем :) До тех пор же буду считать этот пример еще одним примером полного отсутствия какой-либо системы, продуманного пользовательского интерфейса и тестирования юзабилити в виндоуз виста :)

И еще из неопубликованного - февраль 2009, Пуст

2009-12-12T23:14:23Z

То, что у нас называется "Масленница", в Словении называется "Пуст". Но суть та же - проводы зимы и приветствие весны. Устраивается масштабный карнавал по всей Словении. В восточной ее части традиционный символ этого праздника - Курент. Однако и в других местах их тоже можно увидеть, Крань не стал исключением.

Но обо всем по порядку.

Итак, утро, центр. Те, кто пришли поучаствовать в конкурсе костюмов, уже готовятся.

А те, кто уже готовы, ждут начала.

Готовятся к празднику очень серьезно!

Но вот шоу начинается, и процессия начинает свое движение по главной улице города.

Интересная деталь той самой большой коровы на прицепе - продумано все до мелочей!

Актуальная той зимой для Европы тема не осталась незатронутой:

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

Не только куренты развлекают публику в этот день.

Те, кто просто пришли посмотреть, часто сами в разнообразных костюмах. Особенно дети.

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

Из старого (2008) - немного фоток из окрестностей терм Олимия

2009-12-12T22:51:35Z

Монастырь с одной из самых старых аптек Европы. Можно купить лекарственные травы, сборы, мед. Учитывая то, что регион этот удален от каких-либо промышленных объектов и почти заповедник, предложение неплохое!

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

И напоследок - подсветка фонтана на территории терм.

Место очень понравилось, хочется туда снова!

43. Будущее за разнообразием

2009-12-12T22:26:37Z

(В оригинале - Heterogeneity Wins)

Естественная эволюция компьютерных технологий привнесла важные изменения, касающиеся того, какие инструменты могут выбирать архитекторы для проектирования систем. Эти изменения возродили интерес к мультиязыковому программированию — использованию более одного языка в разработке систем.

Мультиязыковое программирование — это не новая концепция. Один из известных примеров из прошлого — поддержка COM-объектами, написанными на С++, Visual Basic. Эта архитектура использовала плюсы обоих языков, наиболее популярных на тот момент.

Что же привело к возрождению интереса к мультиязыковому программированию?

Главное изменение — то, что стандарты вместе с ростом пропускной способности каналов и вычислительной мощности ресурсов сделали жизнеспособными текстовые протоколы. Дни, когда бинарные протоколы были единственной альтернативой для эффективных распределенных систем, прошли. Текстовые протоколы взаимодействия начинались с XML/SOAP web-сервисов и эволюционировали дальше в архитектурные стили RESTful и другие протоколы, такие как Atom и XMPP.

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

Архитектор теперь может комбинировать специализированные, мощные инструменты, что позволяет мыслить категориями «какую концепцию здесь лучше всего применить», вместо более раннего «какую концепцию позволит применить используемый язык программирования». Различные языки программирования поддерживают различные парадигмы: объектно-ориентированную, функциональную или парадигму распределенных и параллельных вычислений. Какие-то из этих парадигм идеально подходят для решения каких-то задач, а какие-то не подходят совсем. И сейчас стало возможным одновременно комбинировать различные, на первый взгляд, несочетающиеся инструменты в элегантные решения гораздо проще, чем это было в прошлом.

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

И хотя временами выбор — не самая хорошая вещь, это точно наименее плохая альтернатива в контексте современной архитектуры ПО. Индустрия стоит перед лицом серьезных проблем (грядущая эра многоядерности и многопроцессорности обещает стать самой большой проблемой ИТ сообщества), и нам понадобятся все возможные механизмы взаимодействия, какие мы сможем задействовать, особенно еще и потому, что существующие платформы плохо приспособлены для их решения (The Free Lunch is Over by Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm).

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

Автор оригинала - Edward Garson

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

42. Язык профессионалов

2009-12-11T15:57:58Z

(В оригинале Talk the Talk)

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

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

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

Паттерны корпоративной архитектуры определяют фреймворки для архитектуры самого высокого уровня. Наиболее известные паттерны – это Event Driven Architecture, Service Oriented Architecture, Resource Oriented Architecture и Pipeline Architecture.

Паттерны уровня архитектуры приложения определяют то, как должны быть спроектированы отдельные приложения, входящие в корпоративную архитектуру. Наиболее часто встречающиеся паттерны – это J2EE паттерны (Session Façade и Transfer Object), а также паттерны, описанные в книге Martin Fowler «Patterns of Enterprise Application Architecture».

Паттерны интеграции важны для проектирования концепций распределения информации между компонентами, приложениями и подсистемами. Примеры интеграционных паттернов – общие файлы, удаленный вызов процедур и множество схем обмена сообщениями. Эти паттерны можно найти вот тут: http://www.enterpriseintegrationpatterns.com/eaipatterns.html.

Знание основных паттернов проектирования, описанных в книге «Design Patterns: Elements of Reusable Object-Oriented Software», обязательно для каждого проектировщика. Хотя эти паттерны могут казаться слишком низкоуровневыми для архитектора ПО, однако они являются частью стандартного словарного запаса, облегчающего коммуникацию с разработчиками.

Также очень важно знать и понимать различные антипаттерны. Термин «Антипаттерн» предложил Andrew Koenig для обозначения часто встречающегося процесса, приводящего к неудовлетворительному результату. Наиболее известные антипаттерны – это Analysis Paralysis, Design By Committee, Mushroom Management, и Death March. Знание этих антипаттернов поможет вам избежать множества ошибок, которые вы бы наверняка совершили без этого знания. Более полный список антипаттернов вы можете найти в википедии: http://en.wikipedia.org/wiki/Anti-patterns.

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

Автор оригинала - Mark Richards

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

Кулинарное

2009-12-10T20:29:14Z

Если кусок рыбы посолить, посыпать специями, завернуть в фольгу и испечь в духовке, а потом аккуратно прямо в фольге положить на тарелку, аккуратно фольгу развернуть, рыбу съесть, фольгу опять же аккуратно убрать с тарелки, скомкать и выбросить, то тарелка останется чистой! :)

И еще о современных машинах

2009-12-09T23:26:07Z

Подсмотрел все у того же ploughlike_elk. Все, надеюсь, знают старый анекдот про удаление гланд через задний проход. Так вот, Рено это применило в конструкции своих автомобилей! Итак, замена лампочки на Рено Меган!

Как тут снова не вспомнить про простые решения...

Еще о ПО от различных производителей...

2009-12-09T23:07:07Z

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

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

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

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

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

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

Гибридные авто - прорыв или тупик?

2009-12-09T22:50:03Z

И вновь о том, что надо делать вещи просто.

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

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

И вот появляются гибриды. Машина по-прежнему имеет все, что имеет классический автомобиль - двигатель внутреннего сгорания, трансмиссию, ПЛЮС к этому еще и электромотор, устройство распределения нагрузки с двух двигателей на колеса, рекуперативные тормоза, аккумулятор и средства его зарядки, и думаю много чего еще. Результат еще более переусложнен, и практически неремонтопригоден. Особенно за пределами официального сервис-центра.

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

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

Вот и делают все вид, что гибрид - новое и перспективное направление в автомобилестроении, словно никто и не слышал никогда о принципе "делать как можно проще"...

Автопром

2009-12-09T22:31:13Z

Недавно в рамках перевода "97 вещей" писал о том, что хороший архитектор будет стараться сделать вещи проще. Сам я полностью эту точку зрения поддерживаю.

А еще недавно во френдленте прочитал историю от автомеханика из Ирландии. Кому интересно - она вот тут: http://ploughlike-elk.livejournal.com/110856.html

Вкратце там речь идет о сломавшемся Ниссан Микра 2003 года. В котором отказал один из электронных блоков - электроусилитель руля. При том что отказал не сам усилитель, а встроенный в него иммобилайзер. Который (иммобилайзер) на этой машине распределен по пяти различным блокам. И при этом 4 из этих 5 блоков нельзя переставить с машины на машину. Т.е. часть, которая иммобилайзер, может быть "прошита" только один раз, при первой установке. Перепрошить нельзя.

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

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

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

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

Остается лишь надеяться, что в мире останутся те, кто считает, что все надо делать как можно проще.

41. Проектирование пустого пространства

2009-12-09T16:52:24Z

(В оригинале - Engineer in the white spaces)

Система состоит из взаимосвязанных частей. Организация из этих частей и связей между ними системы мы и называем проектированием. Когда мы рисуем диаграммы, мы часто обозначаем части квадратиками, а связи – соединяющими квадратики стрелочками.

При этом одна маленькая стрелочка может означать что-то вроде «Синхронный запрос-ответ с использованием SOAP-XML поверх HTTP». И это слишком много информации для одной маленькой стрелочки. Часто даже не хватает места полностью это написать над этой стрелочкой, и мы сокращаем надпись до чего-нибудь вроде «XML over HTTP» для внутреннего использования или «SKU Lookup» для показа заказчику.

Эта стрелочка выглядит как непосредственный контакт между приложениями, однако это не так. Пространство между квадратиками, пустое на диаграмме, в реальности заполнено аппаратными и программными компонентами. Такими как:

сетевые карты
коммутаторы
файрволы
маршрутизаторы
XML преобразователи
FTP серверы
Метро-сети
MPLS шлюзы
Океаны
Рыболовные траулеры, случайно повреждающие сетями кабели

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

Однажды я видел стрелочку с надписью «Выполнение». Один сервер был внутри компании клиента, другой был в другой компании. Эта стрелочка, критичная для удовлетворенности заказчика, будучи распакованной в цепочку событий, стала напоминать головоломку, а не простой интерфейс. Сообщение отправлялось обработчику, который записывал его в файл, который загружался периодически запускаемым FTP процессом, и так далее. Всего шагов в этой последовательности оказалось более двенадцати!

Важно понимать все, что стоит за каждой стрелочкой. Вместо «SOAP-XML over HTTP» следовало написать «Потребуется один запрос для каждого HTTP запроса, плюс подтверждение для каждого HTTP ответа. Планируется около 100 запросов в секунду и доставка ответов за время не более чем 250 миллисекунд в течении 99.999% времени».

И даже это еще не все, что нужно знать об этой стрелочке. Без следующей информации нам тоже не обойтись:

Что если запросы приходят слишком часто? Должны ли мы их отбрасывать без подтверждения, подтверждать отбрасывание или стараться обработать максимально возможное количество?
Что должна предпринять другая сторона, если начнет получать ответы с задержкой более 250 миллисекунд? Пересоздать соединение? Подождать в течении заданного тайм-аута? Выдать сообщение о недоступности вызываемой стороны?
Что если вызывающая сторона пошлет запрос версии 1.0 и получит ответ версии 1.1? А если получит HTML вместо XML? А если MP3 вместо XML?
Что произойдет при отсутствии связи между сторонами?

И вот ответы на такие и им подобные вопросы и есть проектирование пустого пространства.

Автор оригинала - Michael Nygard

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!

40. Производительность важна!

2009-12-08T16:32:32Z

(В оригинале It's all about performance)

Представьте себе автомобиль. Просторный, комфортабельный, с очень низким расходом, дешевый и перерабатываемый на 98%. Хотите себе такой? А если окажется, что он не ездит быстрее чем 10 км/ч? Все еще его хотите? Вот на таком простом примере можно показать, что производительность столь же важна, как и любой другой критерий.

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

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

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

Производительность пользователей критична для сдачи проекта. Многие критерии, описанные в дизайне, лежат в этой плоскости, чаще всего это время реакции на ввод данных. Но время реакции – не единственный фактор. Столь же важны и интуитивность интерфейса, и количество действий для получения результата, одинаково сильно влияющие на производительность.

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

Производительность неинтерактивных компонент, «техническая» производительность, тоже важна. Как пример – «ночной» скрипт, запускаемый каждую ночь, не сможет работать, если для его работы будет требоваться более 24-х часов. Производительность может быть очень важна, например, в системе восстановления после катастрофы. Насколько быстро будет возможно полное восстановление системы после полного выхода из строя одной из ее частей?

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

Автор оригинала - Craig L Russell

Перевод мой. Если вы решите использовать его полностью или частично, не забудьте указать ссылку на мой живой журнал!