Читать онлайн «Дефрагментация мозга. Софтостроение изнутри». Страница 38

</set>

<many-to-one name="EntityRegistry" class="Domain.Core.EntityRegistry" unique="true">

<column name="NI_ENTITY_REGISTRY" not-null="false" />

</many-to-one>

<property name="Name" access="property">

<column name="NAME" not-null="false" />

</property>

<property name="Granularity" access="property">

<column name="GRANULARITY" not-null="true" />

</property>

<property name="FromDate" access="property">

<column name="FROM_DATE" not-null="true" />

</property>

<property name="ToDate" access="property">

<column name="TO_DATE" not-null="true" />

</property>

<property name="Closed" access="property" type="YesNo">

<column name="CLOSED" not-null="true" />

</property>

<property name="CreatedBy" access="property">

<column name="CREATED_BY" not-null="false" />

</property>

<property name="CreatedDate" access="property" type="timestamp">

<column name="CREATED_DATE" not-null="false" />

</property>

<property name="LastModifiedBy" access="property">

<column name="LAST_MODIFIED_BY" not-null="false" />

</property>

<property name="LastModifiedDate" access="property" type="timestamp">

<column name="LAST_MODIFIED_DATE" not-null="false" />

</property>

</class>

Генерируемые для слоя веб-служб C#-файлы предназначены для создания двух сборок: собственно служб и интерфейсов к ним, используемых клиентами.

Рис. 25. Классы, реализующие службы доступа к объектам домена

Рис. 26. Класс службы сохранения объектов

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

Рис. 27. Перечисляемый тип слоя веб-служб

Рис. 28. Классы вызова специфицированных методов

Рис. 29. Классы вызова веб-служб, касающихся «финансового года»

Рис. 30. Класс адаптера для работы с объектом «Финансовый год»

Рис. 31. Класс адаптера для работы с коллекцией объектов «Финансовый год»

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

Пример работы с DTO

CurrencyDTO curr1 = new CurrencyDTO();

curr1.Code = "RUR";

curr1.Name = "Currency 1";

UnitOfWorkDTO uow = new UnitOfWorkDTO();

uow.Save(curr1);

PersistenceRequest prq1 = new PersistenceRequest();

prq1.UnitOfWork = uow;

PersistenceResponse prr1 = client.Post<PersistenceResponse>("/Persistence", prq1);

Assert.IsFalse(prr1.CommitResult.HasError, prr1.CommitResult.Message);

Пример работы с адаптерами

Currency curr1 = new Currency();

curr1.Code = "RUR";

curr1.Name = "Currency 1";

CommitResult cr1 = curr1.Save();

Assert.IsFalse(cr1.HasError, cr1.Message);

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

Извлечение списка финансовых годов, отфильтрованного по названию

FiscalYearCollection years = FiscalYearCollection.GetByQuery(

"from FiscalYear where Name like: name order by Name",

new ServicesQueryParams()

AddParam("name", txtYearName.Text)

);

dgvYears.DataSource = years;

Извлечение списка учётных периодов заданного года

PeriodCollection periods = PeriodCollection.GetByQuery(

"from Period where FiscalYear.Id =:yearId order by FromDate",

new ServicesQueryParams()

AddParam("yearId", CurrentYear.Id),

0, 1000);

dgvPeriods.DataSource = periods;

Запускаем клиентское приложение, предварительно запустив сервер веб-служб, и видим на экране примерно такую картинку, как на рис. 32.

Рис. 32. Форма отображения финансовых годов и учётных периодов

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

Одним из способов обхода этой проблемы является описанная технология программной фабрики, несомненно далёкая от совершенства и ограниченная в наборе целевых платформ.

Какова же эффективность?

Если рассмотреть метрики относительно небольшого проекта, то 40 прикладных сущностей в модели, состоящей примерно из 600 строк XML-описаний, порождают:

• около 3 тысяч строк SQL-скриптов для каждой из целевых СУБД;

• порядка 10 тысяч строк домена;

• 1200 строк XML для проекций классов на реляционные структуры (таблицы);

• около 17 тысяч строк веб-служб и интерфейсов.

Таким образом, соотношение числа строк мета-кода описания модели к коду его реализации на конкретных архитектурах и платформах составляет около 600 к 30 тысячам или 1 к 50.

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

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

Этот рассказ я написал более 10 лет назад, летом 2001 года, в поездках на пригородном поезде между Парижем и Moulin-Galant, где размещался филиал IBM, и поначалу сомневался в необходимости его включения в книгу. Но, просмотрев старый текст, с некоторым удивлением я обнаружил, что если заменить аббревиатуры в названиях технологий на «новые и прогрессивные», то суть повествования останется прежней. Изменится ли что-нибудь ещё через 10 лет, покажет время.

Что такое «баг» знают, наверное, все программисты. Кто не знает, поясню: «баг» (от англ. bug – жучок) – это «жучок-вредитель» в программе, то есть ошибка, аномалия, сбой. По-французски это интернациональное словечко произносится примерно как «бёг», но буква «ё» произносится ближе к звуку «о». Особенностью французской, как, собственно, и любой другой программной индустрии – громкое слово, несколько облагораживающее нашу всемирную «багодельню», является одно из национальных состояний французской души, характеризующее этакого сангвиника после распитого с друзьями бокала вина, галантного и совсем не торопящегося жить. Разумеется, сангвиник считает, что все продукты его труда велики и прекрасны, как вид на ночной Париж с Монмартрского холма или пыльный гобелен над кроватью Наполеона в замке Фонтенбло.

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

Итак, некоторое время я находился в счастливом неведении относительно общего состояния дел. Прежде всего пришлось оценить качество кода. То, что единые соглашения отсутствовали, а Java-подобный стиль не очень хорош в программах на С++ не являлось большим недостатком – лучше такой стиль, чем никакой, тем более что кода на Java в системе было много. Прежние авторы, видимо, не смогли выразить себя в объектно-ориентированным подходе, а до структурного программирования и функциональной декомпозиции не опустились. Если первое не сразу бросалось в глаза наличием достаточного числа классов с пустыми конструкторами, то второе резало глаз обилием возвратов из разных мест одной функции и очень похожими кусками кода в одноимённых перегруженных функциях, написанных методом копирования текста через буфер обмена, «copy-paste». При виде некоторых фрагментов кроме чисто русских эмоциональных выражений из меня периодически вылезало французское «что за бордель», вызвавшее похвалу моего коллеги, отмечавшего, что я делаю успехи в освоении языка.

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