Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

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

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

Работа в крупной компании имеет свои особенности. Например, директор информационных систем уровня филиала может и не знать, чем принципиально отличается MS Access от SQL Server. Но показать лицензионную чистоту использования движка Access ему необходимо.

Если с серверной СУБД выбор без особенных затруднений пал на SQL Server, то рабочие места обладали неприятной особенностью: пользователи были лишены прав локального администратора, соответственно, возможности по установке компонентов системного уровня у них отсутствовали. Встраиваемая в приложение редакция SQL Server Compact 2005 в тот момент не могла быть развёрнута простым копированием. Общего с полноценным SQL Server, даже в его минимальной экспресс-версии, у неё было немного, за исключением названия. По сути, тот же Access, даже местами менее функциональный за счёт отсутствия поддержки временных таблиц, но с проблемами использования вне. NET. На рассмотрение и обход раскиданных граблей в других встраиваемых СУБД времени не было.

С автономным приложением выбор был более очевидным. Стандартной версией. NET на рабочих местах была 1.1, что для 2007 года выглядело устаревшим. Собственно, NET был нужен для приложения SAP и, в своё время, накатывая на корпоративные компьютеры обновление фреймворка на уровне пакета ( service pack 1 ), предприятие столкнулось с проблемами функционирования основного приложения. Поэтому предлагать службе эксплуатации устанавливать. NET 2 было невежливо, мягко говоря. А при анонсированном. NET 3 ещё и неразумно. Так в проекте возникла последняя версия Delphi для Win32, позволяющая строить приложения, развёртываемые простым копированием исполняемых файлов без необходимости установки системных компонентов. Проблемы локализации и автоматического обновления версий уже решались в рамках этой среды и не вызывали вопросов.

Если изобразить получившуюся архитектуру, то получится картинка, представленная на рис. 11.

Построив распределённую архитектуру, мы сталкиваемся с двумя основными проблемами:

• поддержка данных в актуальном состоянии;

• обработка данных относительно слабым, по сравнению с сервером, компьютером пользователя.

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

Рис. 11.Архитектура «Оптисток»

Однако передача таких объёмов данных по узким каналам, равно как и вставка в таблицы локального движка миллионов записей, потребовали дополнительной оптимизации. Веб-служба синхронизации была дополнительно нагружена сжатием данных, добавлены функции пакетной передачи, например, по 500 тысяч записей. Вставка в транзакции даже на ADO-технологии позволила довести скорость до 10–20 тысяч записей в секунду, что было достаточным.

Вторая проблема вызывала тревогу у работавших по соседству консультантов, поскольку имевшееся у них в эксплуатации приложение с БД Access размером всего 1 гигабайт проводило за расчётами долгие ночные часы. Но я был априори уверен, что из этого движка вполне можно выжать необходимую скорость, если не впадать в деструктивный снобизм якобы «ненастоящей СУБД», а подходить к вопросу так же серьёзно, как к обработке на порядок-два больших объёмов на полноценном SQL Server.

Для отладки SQL пришлось в короткий срок соорудить инструмент, подобный Query Analyser, но работавший через ADO с БД Access. В получившем название ADO SQL Tools (MS Access Query Analyzer) и происходила основная разработка расчётов. Время исполнения наиболее тяжёлых пакетов запросов удалось довести до 20–30 секунд на обычном пользовательском ПК или ноутбуке с одноядерным процессором и 1 гигабайтом ОЗУ.

Немало времени было уделено интерфейсу пользователя. Зная, что основная работа по обучению ляжет на его плечи, Поль постарался упростить видимый функционал, внеся немало предложений и уточнений в спецификацию. Кроме того, внешний вид приложения, «шкурка» [116], должен был соответствовать корпоративной цветовой гамме, для чего в проект был привлечён профессиональный график. По одёжке встречают.

Рис. 12.Внешний вид клиентского приложения «Оптисток»

Для обеспечения процесса на площадке заказчика пришлось организовывать минимальный набор из трех изолированных сред: разработки, тестирования-приёмки и эксплуатации. С точки зрения 2012 года мощность сервера вызывает улыбку, лишь недавно ему добавили памяти, доведя объём ОЗУ до 4 гигабайт. Но распределённая обработка данных вкупе с использованием множественной обработки на SQL позволила обойтись столь скромными ресурсами.

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

В 2008 году крупный разработчик ERP-системы для розничной торговли оказался в числе наших клиентов. Что же хотела компания с 25-летней историей, двумя сотнями сотрудников и множеством клиентов в Европе и Северной Америке, среди которых такие бренды, как Naf Naf, Vieux Campers, Tally Weijl, Guess, от небольшой программистской фирмы, вчерашнего «стартапа»?

Новая версия системы «по всем правилам архитектуры», подобно каменному цветку, не выходила. Сроки затягивались, приёмки переносились, инвесторы нервничали. Не знаю, кому пришла в голову идея, но фирма решила попробовать в деле так называемую «программную фабрику» ( software factory ). То есть генерировать немалую часть кода и компонентов системы из мета-описаний. Предшествующие внутренние попытки домен-ориентированной разработки на базе. NET, NHibernate и всевозможных лучших практик не приносили результата.