Архи-тектура

Легким движением руки…

- Господи, что это за дура?
- Это не дура, это лошадь!
Олег Куваев, «Подарочки»

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

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

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

Доска почета

Есть ли реальные примеры хорошей архитектуры? Конечно, есть: UNIX. Прелесть UNIX в том, что эта ОС представляет собой некоторый базис, основу, на которую можно навешать одно, другое и третье, и все эти нововведения не будут противоречить друг другу, если все сделать правильно. Ведь многие, ставшие сегодня привычными элементы UNIX были добавлены в систему не сразу. Тем не менее, они прекрасно интегрировались и воспринимаются сегодня как неотъемлемая часть операционной системы. Различные модули (даже со смежной функциональностью) друг другу не мешают. Они как бы ортогональны. Есть модуль А, есть модуль Б, и оба нормально работают. Более того, зачастую модуль Б можно удалить, и система этого не заметит. Конечно, часть функциональности мы потеряем, однако ничего фатального не произойдет. Создать архитектуру, которая позволяла бы работать на минимальном количестве модулей, не просто. Но создателям UNIX, по большому счету, это удалось.

Не следует думать, что модульность - обязательное условие хорошей архитектуры. Многое зависит от задачи. Построение модульной архитектуры зачастую ведет к дополнительным накладным расходам, но очень часто они незначительны по сравнению с возможной выгодой от правильно спроектированного приложения. Разумеется, сразу оценить эту выгоду трудно. Ведь правильный внутренний дизайн не может сам по себе обеспечить популярность продукта, прямой корреляции тут нет. Если взять тот же UNIX и посмотреть на рынок серверных операционных систем, можно заметить, что UNIX вовсе не является монополистом. Доля его довольно велика, но законодателем мод UNIX назвать трудно. Несмотря на то, что его архитектура на порядки лучше архитектуры конкурентов. В чем тут дело?

Что нам стоит?..

Steve Jobs: We’re better than you are. We have better stuff!
Bill Gates: You don’t realize, Steve … that doesn’t matter!
Диалог из фильма «Pirates of Silicon Valley» ¹

Не секрет, что на Windows программировать просто. Точнее, поначалу программировать просто, сложности вылезают потом. То есть возникает некоторое противоречие. Если реализовать несложную программу на Windows можно без серьезных трудовых затрат, то качественные серверные приложения на Windows программировать нельзя.

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

То же самое можно сказать и о пользователях UNIX. Средний уровень системного администратора на UNIX гораздо выше, чем средний уровень его коллеги, работающего с Windows. Обусловлено это опять же кажущейся простотой Windows и некоторой недружелюбностью UNIX. Иными словами, происходит некий естественный отбор. Многие системные администраторы не хотят тратить время на изучение особенностей операционной системы, предпочитая использовать готовые решения. Они выбирают Windows. Возможно, это прозвучит слишком резко, но их трудно назвать профессионалами (что совершенно не исключает того, что среди сисадминов Windows NT и ее производных есть настоящие профессионалы). И эти люди точно не умеют делать архитектуру. Ни на каком уровне.

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

Популярность Windows как серверной системы во многом обусловлена тем, что простые проблемы на ней решаются простыми методами. Тем не менее, для критических приложений до сих пор основной серверной ОС является UNIX. Другими словами, существует довольно широкий класс задач, для которого недостатки архитектуры Windows некритичны. И ее достоинства - легкость в управлении, интуитивно понятный интерфейс и так далее - перевешивают все структурные недостатки. Разумеется, в успехе Windows как серверной системы в большой степени «виновны» маркетологи Microsoft, однако следует признать, что сам продукт вполне отвечает потребностям рынка и завоевал бы свою долю на рынке (пусть и более скромную) и без корпоративной мощи Microsoft.

В поисках идеала

Идеальна ли архитектура UNIX? Нет. Можно ли ее улучшить? Наверное, но потребности в этом пока нет. Вопросами построения идеальной архитектуры обычно задаются те, кто занимается академическими исследованиями. Собственно, Linux - одна из последних попыток изменить UNIX, в какой-то степени может считаться именно академической забавой. Ведь первоначально Linux был не более чем студенческим опытом, не предназначавшимся для реального использования.

Почему академические разработки мало применяются в реальном программировании? Стоимость широкого внедрения реальной системы довольно высока. Иногда система может стать популярной за счет каких-то глубинных процессов, но это редкость. Linux очень помогло движение Open Source. Кроме того, на свободном рынке невозможна ситуация, когда всех потребителей устраивает один-единственный продукт. Другими словами, свято место пусто не бывает, и, не будь Linux, появилось бы что-нибудь другое.

Хорошей иллюстрацией последнего положения может служить пример с продажами игрушки Dendy. Когда на прилавках появилась 16-битная приставка, продажи устаревшей 8-битной версии выросли. Парадокс объясняется просто. Если раньше покупателей волновал вопрос, нужно ли покупать Dendy, то с появлением альтернативы формулировка изменилась на «какую именно Dendy нужно покупать».

Похожая ситуация и с операционными системами. В какой-то момент Windows всех задавила - говорить о таких системах, как Solaris на рабочей станции, смешно. И начало появляться нечто новое. Linux.

Дело - труба

I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility.
Edsger W. Dijkstra ²

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

Здесь, с одной стороны, требуется значительно меньше ресурсов для создания базисной части системы. С другой - уж очень специфична среда, в которой эта система работает. То есть стандартную операционку даже в очень урезанном виде влепить сюда довольно сложно. Даже Windows CE, которая нормально себя чувствует в КПК, все-таки не рассчитана на его уровень энергопотребления, особенности интерфейса КПК или, того хуже, смартфона, на те процессоры, которые до последнего времени ставили в телефоны, и так далее. Наследственность ей мешает. Ее базисная функциональность шире той, которая требуется в данном конкретном случае. Это не значит, что Windows CE неуспешна. Скорее всего, она задавит-таки PalmOS и займет лидирующее место на рынке. Но станет ли она единственной альтернативой, как это произошло на рынке офисных пакетов? Абсолютно неочевидно.

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

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

Попробуем другую аналогию. Возьмем, к примеру, Java. По-хорошему академический проект, правильно сделанный язык программирования. Не без недостатков, но весьма приличная разработка. Однако когда дело доходит до практики… К примеру, Java в телефоне… Как известно, можно запустить приложение Java и заняться своими делами. И все работает согласно стандарту. Но выясняется одна неприятная тонкость. Приложение-то работает, а вот вытащить его на поверхность крайне тяжело. Если попробовать снова запустить это приложение, то запустится еще один экземпляр. Приложение работает, в соответствии с ожиданиями поглощает ресурсы, а толку от этого чуть.

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

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

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

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

У Java есть еще один недостаток. Была версия 1.1., появляется версия 2. И все красиво и довольно хорошо прописано, однако наследственности по отношению к первым версиям у второй версии относительно мало. О чем это говорит? О том, что в Sun изначально неправильно позиционировали Java как средство написания определенных систем и неправильно спроектировали окружение Java. Язык языком, а то, что версии библиотек снизу вверх плохо совместимы, добавляет много мороки разработчикам. Короче, многие программы приходится переписывать.

Сейчас чем-то подобным пытается заниматься Microsoft. Мирный переход на .Net - это, по большому счету, революция, сравнимая с появлением OLE. Ведь у того же COM+ с COM общего не очень много - на сто процентов совпадают, пожалуй, только три буквы в названии. Радикальная смена архитектуры операционной системы для прикладных программистов означает, что как минимум часть программистов должна остаться на поддержке старых версий под новую среду, а другая - должна, во-первых, переписать уже имеющийся код под новую ОС, во-вторых, добавить новой функциональности. А ведь программистам нужно время, что свыкнуться с изменившимися правилами игры. То есть встряска для программистских коллективов получается нешуточная.

Переменные окружения

The tools we are trying to use and the language of notation we are using to express or record our thoughts are the major factors determining what we can think or express at all!
Edsger W. Dijkstra ³

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

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

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

Острая нехватка Росси и Ле Корбюзье

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

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

Связано ли это с академическими исследованиями? Еще как связано. Мне в свое время очень помогла по-иному взглянуть на архитектуру компьютерных систем такая вещь, как формальная теория языков программирования. Теория, которая даже в компиляторах используется крайне мало. Такая академическая, не очень приближенная к жизни разработка. Некоторые ее следствия используются в компиляторах, но таких - кот наплакал. А вот некоторые теоретические аспекты позволяют посмотреть на проектирование чуть шире, иначе, хотя они и не имеют прямого выхода в программирование. Но дают некий культурный базис, необходимый для построения правильных систем.

Научный подход

We see a thriving software industry
that largely ignores research, and a research community
that writes papers rather than software.
Rob Pike, Bell Labs ⁴

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

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

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

Кстати, этот стиль мышления крайне полезен. По моим внутренним ощущениям, лучшие профессионалы во многих областях учились на самом деле на физических, математических и т. п. факультетах. Там, где формируется определенный стиль мышления, позволяющий впоследствии освоить чуть ли не любую профессию и преуспеть в ней, оттеснив людей, которые обучались чему-то более похожему пять лет в институте. Мы видим, что многие успешные бизнесмены, политики, продюсеры изначально получили именно естественное образование. Гуманитариев (даже если включить в их круг экономистов) среди них мало.

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

Заключение

Любая система, зависящая от человеческой надежности, ненадежна.
Второй закон ненадежности Джилба

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