Разумеется, у каждой архитектуры есть свои преимущества и недостатки. Если подходить к вопросу проектирования объективно, то выбор в каждом конкретном случае вполне рационален. Но я вспоминаю, например, что в начале профессиональной деятельности нам хотелось просто попробовать «сделать трёхзвенку» своими руками, невзирая на то, что экономическая целесообразность такого выбора была не совсем очевидна как по затратам на разработку, так и по стоимости владения системой в будущем.
Сегодня доля специалистов, имеющих опыт в системном проектировании, в общем потоке становится всё меньше. Поэтому декомпозиция и выбор архитектуры часто проводится по принципу «прочитали статью, у этих парней получилось, сделаем и мы так же». Огород из нескольких физических уровней насаждается не потому, что это действительно надо, а потому, что очередной гуру написал об этом в своём блоге. Или потому, что нет другого опыта и мотивации его приобрести: чему научили ремесленника, тому и быть.
В итоге между экраном конечных пользователей и запрашиваемыми ими данными образуется толстая прослойка, которая на 80 % занята совершенно пустой работой по перекачиванию исходной информации из одного формата представления в другой. Регулярные восстановления долговременных объектов, бесконечные сериализации и десериализации, передача и преобразование XML, дёрганье за веб-службы… С учётом, например, обновления области экрана по изменению каких-то данных в другой его части эти мытарства умножаются в разы. Растёт время отклика системы. Пользователь нервничает и справедливо обвиняет в этом программистов.
В такой ситуации нет ничего необычного, потому что практика управления «по кейсам»[95], то есть прецедентам, является широко распространённой в среде менеджеров среднего звена. Критичность основной массы проектов в ИТ снижается, соответственно, большая часть решений переходит из технической плоскости в управленческую. Эта тенденция будет только усиливаться.
Любопытно, что в русском языке слово «менеджер» имеет весьма точный, но основательно подзабытый в эпоху советской России перевод «приказчик». Магическая сила слов! Получил бы популярность клон игры «Монополия», если бы его в конце 1980-х годов назвали «Приказчик»? Теперь сравните пару «менеджер проекта» и «тестировщик» против другой: «приказчик» и «инженер-испытатель»…
Кто не хочет – ищет причины, кто хочет – средства. Ищите возможности сократить путь информации от источника к пользователю и обратно. В конце концов, архитектура служит для эффективной реализации системы, а не освоения бюджета и вовлечения в команду очередных выпускников курсов переквалификации. Подход разработки «по модели», о котором мы ещё поговорим, позволяет генерировать многие слои без участия программистов.
История нескольких #ifdef
640 килобайт памяти должно хватить каждому.
Перелом начала 1990-х годов в России вынудил целые коллективы квалифицированных системно мыслящих людей переходить из специализированных учреждений НИОКР непосредственно на уцелевшие производства, эмигрировать или начинать собственный бизнес. Не мудрено, что в такой ситуации уровень технической культуры в отделе программирования торгово-производственной компьютерной фирмы «Ниеншанц» был достаточным и для софтостроительных проектов. Разумеется, не последняя роль в создании атмосферы и соответствующего интеллектуального уровня принадлежала основателям компании, пришедшим в бизнес из научной среды: Виктору Ярутову, Дмитрию Разгуляеву, Егору Макарову – выпускникам физического факультета ЛГУ[96].
Таким образом, уже в начале – середине 1990-х на предприятии существовала собственная комплексная информационная система Seller 2, выполненная в трёхзвенной архитектуре с технологией если и не совсем «умного», то и не вполне толстого клиента. Хотя разработчики ещё не знали термина
В следующей главе речь пойдёт о разработке тиражной КИС в «Ниеншанце». Разумеется, возникла она не на пустом месте. Чтобы самому не пересказывать предысторию появления нового продукта в виде предшествующих версий, я обратился непосредственно к участникам, своим бывшим коллегам. С небольшими поправками текст публикуется с их согласия.
То, что рассказывают ведущие программисты Дмитрий Цуранов (ДЦ), Сергей Быков (СБ) и Игорь Паньшин (ИП), кандидат технических наук, участвовавший в разработке на стадии платформы VAX[97], вначале было весьма близко к современным понятиям «эволюционный дизайн» и «гибкие методики». Но потом приходит осознание и понимание.
Начало