Помоги проекту - поделись книгой:
Явление зависит от условий наблюдения. Сущность от этих условий не зависит.
Применительно к разработке программных систем. Вы описываете какой-то отдельный прецедент в том виде, в котором наблюдаете. Или, скорее всего, со слов участников. Например, «оплата в кассу». Пока расчёты наличные, вы наблюдаете перемещение монет и купюр из кошелька покупателя в кассу продавца. И считаете, что движение денег – это физическое перемещение монет. В один прекрасный день возникнет необходимость принимать к оплате безналичные средства, например карты. Возникают проблемы с прежней постановкой: ничего физически не перемещается. Имеем уже два прецедента: «оплата в кассу наличными» и «оплата в кассу безналичными». Послезавтра возникнет новый способ оплаты – в кредит, но операцию покупки проводят все в той же кассе. Потом с учётом скидок. Потом с учётом истории покупок по «клубной» карте и так далее.
Подобно уточняющим геоцентрическую модель эпициклам, на диаграмму накручиваются всё новые прецеденты. Видимо, поэтому в RUP рекомендуют не увлекаться наворачиванием прецедентов друг на друга (
Альтернатив, к сожалению, немного. Об основной – создании собственных предметно-ориентированных языков, мета-языков – уже сказано, и не раз, в том числе в рамках описаний конкретных систем. Далеко не факт, что для этого будет нужен UML хоть в каком-то виде.
Отрасль же в очередной раз оказалась в интересном положении, когда «лучше такой UML, чем никакой». Слишком часто формулировка «лучше плохой, чем никакой» стала широко применяться, что настораживает. Но прогресс, развивающийся по законам бизнеса, неотвратим, даже если слово «прогресс», при наличии на то оснований, заключать в кавычки.
Из положительных моментов UML и поддерживающих его сред необходимо отметить, что в ситуации, когда задача складывается, как мозаика, из обрывочных сведений представителей заказчика, прецеденты помогут хоть как-то формализовать и зафиксировать неиссякаемый поток противоречивых требований. Неважно, что мозаика может, скорее всего, не сложиться в стройную картинку, но при отсутствии экспертизы в предметной области риски недопонимания и недооценки снижаются. Наиболее проработанная часть UML – диаграмма классов – при определённых усилиях и дисциплине программистов, конечно, поможет вам автоматизировать генерацию части рутинного кода приложения.
Большой интерес представляют так называемые «двусторонние» инструменты (
Для тиражируемых продуктов и ориентированного на специализации проектного софтостроения наиболее интересен подход с разработкой собственных языков, где необходимость использования UML неочевидна. Остаются, по большому счёту, заказные проекты без видимых перспектив повторных внедрений, где само слово «моделирование» может вызвать реакцию «пиши код, мы тут проектируем только снизу-вверх».
Когда старая школа молода
Изменения происходят столь быстро, что приходится записывать в ряды старой школы системы с приложениями на последних версиях автономного Visual Basic 6, безвозвратно растворившегося в бурлящей пучине. NET. Теперь, спустя немногим более десяти лет, когда начинают всплывать проблемы с поддержкой из-за отсутствия специалистов, принимаются решения о переделке систем в новой технологии с минимальными изменениями функциональной полезности или вовсе без оной. Тут-то и могут вскрыться интересные подробности.
В одной крупной электрической компании имелась база данных, собирающая эксплуатационную и прочую информацию за несколько лет от разнообразных датчиков и устройств в распределительной сети национального масштаба. Некоторые параметры отличались очень коротким интервалом замеров – «каждые N секунд». В итоге размер хранилища составляет около 3 терабайт информации за несколько фиксированных лет эксплуатации.
В общем, такой размер не является маленьким и для промышленных СУБД, требуя дополнительных усилий в проектировании, реализации, настройке и поддержке. Но пикантность ситуации состояла в том, что база данных была организована в виде двоичных файлов собственного формата.
Признаюсь, последний раз я видел такой подход в далёком 1994 году, когда мы переводили паспортные столы Санкт-Петербурга с подобных плоских файлов на прогрессивный по тем временам и, что важнее, открытый формат DBF под Clipper и FoxPro для MS-DOS и Novell-серверов. С оговорками перехода от
В долговременной памяти всплыли воспоминания случаев необходимости ручного декодирования форматов. К великому счастью, программисты системы не занимались тогда «эволюционной» разработкой, а знали область, в которой работают, и добросовестно поддерживали проектную документацию в актуальном состоянии. Кроме возможности прочитать собственно об устройстве системы, все описания форматов двоичных файлов также были на месте. Возникший было тёмный призрак индустриальной археологии растворился в лучах взошедшего солнца.
Поскольку в нашу задачу входило предпроектное обследование, начались интересные опыты с технологиями новыми. Начали с прототипа конвертера, извлекающего данные из старых форматов и распределяющего их по таблицам промышленной СУБД, в качестве которой выступал SQL Server. Логично было бы написать такой прототип на C++ или другом языке с возможностями прямого доступа к памяти на уровне битов, но ввиду планируемой общей разработки исключительно на C# необходимо было оценить соответствующую программу в ипостаси распаковщика байтов.
Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. А ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked(). В итоге код достаточно простого алгоритма пестрел вот такими вставками, которые, на минуточку, суть рекомендуемые практики. Нас настигла расплата за автоматическое управление памятью.
Convert. ToUInt32 ("00110000", 2 ); unchecked((ushort) 0xC0);
Вторым пунктом была собственно база данных. На логическом уровне структура для тестируемого случая никаких сложностей не представляла: одна узкая длинная таблица, связанная с несколькими короткими справочниками, практически «звезда», но в режиме постоянного добавления пачек новых записей. Трудность представлял собой уровень физический. Втиснуть число-признак, кодируемое тремя битами, в те же три бита на уровне СУБД стандартные средства не позволят. Минимальный размер – байт. Использовать нестандартные битовые поля в принципе можно, но тогда мы лишимся поддержки ссылочной и прочей целостности, возможности использовать SQL для выборок без переупаковки значений в битовые структуры и фактически будем использовать СУБД в качестве продвинутого аналога файлового хранилища с улучшенными функциями администрирования.
Поскольку целью было упрощение работы с пользовательскими запросами, то лишать их доступа к данным посредством прямого и понятного человеку SQL было решительно невозможно. При использовании минимальных по размеру стандартных типов данных прогнозируемый размер базы данных без учёта дополнительных индексов превысил 6 терабайт, то есть минимум удвоился по сравнению с двоичными файлами. Сжатие данных несколько скрасило ситуацию, полученные 4,5 терабайта выглядели уже неплохо. За всё надо платить, в том числе за стандартность доступа и представления данных.
Третьим пунктом была загрузка данных из C#-приложения в базу данных. Поскольку интенсивность вставки из прибывающих от датчиков текстовых файлов составляла почти 400 тысяч записей каждые 10 минут, то, разумеется, приложение должно было справляться с этой задачей за меньшее время. Оптимальной, как и следовало ожидать, оказалась пакетная загрузка, игнорирующая ограничения целостности РСУБД. Такова обычная цена компромисса.
Что имеем по итогам более чем 10-летнего развития технологий? Появилась возможность стандартизировать хранение и доступ к большому массиву данных, используя вполне обычное серверное оборудование корпоративного класса и 64-разрядную промышленную СУБД. Возникла необходимость переделывать программное обеспечение из-за утраты поддержки среды разработки поставщиком и соответствующих компетенций на рынке труда.
Но я совсем не уверен, что ещё через 10 лет новые подрядчики, вынужденные в очередной раз переписывать систему, найдут документацию в том же полном виде, в котором нашли её мы. Если вообще найдут хоть что-то, кроме кода, остатков презентаций и наших отчётов.«Оптисток», или распределённый анализ данных
Название «Оптисток» придумал уже позже кто-то из маркетинговой команды. Поль, руководитель проекта и ответственный за функционал, был первое время недоволен, так как предыдущая версия продукта называлась «Оскар». Поэтому корневой директорий системы так и живёт до сих пор под названием Oscar2.
Организация процесса получилась близкой к подходу MSF, но с учётом относительно небольшого масштаба. Из рабочих групп оставалось, с одной стороны, только управление продуктом, совмещённое с управлением проектом, где кроме Поля были задействованы ключевые пользователи и представитель директората. С другой – была объединённая группа архитектуры и разработки за моей ответственностью и основным участием вкупе с координацией привлекаемых к проекту специалистов по SAP, корпоративному хранилищу данных и графике. Спираль процессов потребовала всего полторы фазы с одним прототипом.
С оговорками, я работаю в такой организации со студенческих времён и считаю её наиболее эффективной и комфортной для разработки продукта или заказного проекта. Опыт Microsoft показывает хорошие возможности масштабирования процесса. Но мы ещё вернёмся к этому вопросу.
Если применить к «Оптистоку» действующие классификации, то это система класса SFA (Sales Forces Automation – автоматизация продаж на выезде), предназначенная для выстраивания каналов сбыта, ориентированных на конкретного клиента. Рынок – автомобильные компоненты, запчасти и тому подобное. С другой стороны, система занимается аналитической обработкой данных и относится к BI. Типовое использование проходит по следующему сценарию.
Приходит торговый агент компании к клиенту со своим ноутбуком, запускает программу, выбирает номенклатуру, параметры поиска и ограничения, задаёт целевые ориентиры, например, увеличение продаж по данной продуктовой линии на 5 % при складской политике «запас на 7 недель», выбирает географию продаж клиента и запускает расчёт. В итоге получается прогноз-анализ на основе оценки:
• продаж компании в выбранной географии. Например, данные отгрузки по стране клиента;
• парка автомобилей выбранного сегмента рынка, также с учётом географии. Например, вся Голландия или только 75-й департамент Франции.
После чего клиенту предлагается пополнить склад некоторым количеством товаров на базе этих расчётов.
Архитектура подобных систем, можно сказать, типовая. Проектируем специализированное хранилище, ищем в корпоративной среде источники нужной информации, организуем регулярное обновление данных, предоставляем пользователям интерфейс для доступа к данным: непосредственно к хранилищу или к так называемым витринам (
В случае стационарных рабочих мест этим можно ограничиться. Но специфика ситуации накладывала ограничения на решение.
Предполагалось нетипично большое для аналитического приложения количество пользователей, в потенциале – вся «пехота продажников» вместе с их непосредственными командирами. Как правило, круг пользователей аналитической БД – десяток специалистов в рабочей группе, а для другой группы организуется новая БД, таким образом распределяется нагрузка, создаваемая тяжёлыми запросами пользователей.
Пользователи должны были иметь возможность работать «в поле», то есть при отсутствии соединения с корпоративной сетью. В связи с их количеством, это требование хоть и усложняло реализацию, накручивая новое звено, но помогало решать вопросы нагрузки децентрализацией обработки.
Как и в любой транснациональной корпорации, необходимо поддержать многоязычный интерфейс в приложении и непосредственно в данных.
Работа в крупной компании имеет свои особенности. Например, директор информационных систем уровня филиала может и не знать, чем принципиально отличается MS Access от SQL Server. Но показать лицензионную чистоту использования движка Access ему необходимо.
Если с серверной СУБД выбор без особенных затруднений пал на SQL Server, то рабочие места обладали неприятной особенностью: пользователи были лишены прав локального администратора, соответственно, возможности по установке компонентов системного уровня у них отсутствовали. Встраиваемая в приложение редакция SQL Server Compact 2005 в тот момент не могла быть развёрнута простым копированием. Общего с полноценным SQL Server, даже в его минимальной экспресс-версии, у неё было немного, за исключением названия. По сути, тот же Access, даже местами менее функциональный за счёт отсутствия поддержки временных таблиц, но с проблемами использования вне. NET. На рассмотрение и обход раскиданных граблей в других встраиваемых СУБД времени не было.
С автономным приложением выбор был более очевидным. Стандартной версией. NET на рабочих местах была 1.1, что для 2007 года выглядело устаревшим. Собственно, NET был нужен для приложения SAP и, в своё время, накатывая на корпоративные компьютеры обновление фреймворка на уровне пакета (
Если изобразить получившуюся архитектуру, то получится картинка, представленная на рис. 11.
Построив распределённую архитектуру, мы сталкиваемся с двумя основными проблемами:
• поддержка данных в актуальном состоянии;
• обработка данных относительно слабым, по сравнению с сервером, компьютером пользователя.Первая проблема была решена односторонней синхронизацией локальных данных с соответствующей их частью в хранилище. Поясню подробнее, каждый пользователь привязан к своей клиентской базе, определяемой географией продаж. Соответственно, торговому агенту с клиентами в Италии нет никакого смысла хранить данные о продажах в Великобритании. Поэтому локальная база данных была намного меньше хранилища и гарантированно не превышала двух гигабайт, которыми ограничен движок Access.
Однако передача таких объёмов данных по узким каналам, равно как и вставка в таблицы локального движка миллионов записей, потребовали дополнительной оптимизации. Веб-служба синхронизации была дополнительно нагружена сжатием данных, добавлены функции пакетной передачи, например, по 500 тысяч записей. Вставка в транзакции даже на ADO-технологии позволила довести скорость до 10–20 тысяч записей в секунду, что было достаточным.
Вторая проблема вызывала тревогу у работавших по соседству консультантов, поскольку имевшееся у них в эксплуатации приложение с БД Access размером всего 1 гигабайт проводило за расчётами долгие ночные часы. Но я был априори уверен, что из этого движка вполне можно выжать необходимую скорость, если не впадать в деструктивный снобизм якобы «ненастоящей СУБД», а подходить к вопросу так же серьёзно, как к обработке на порядок-два больших объёмов на полноценном SQL Server.
Для отладки SQL пришлось в короткий срок соорудить инструмент, подобный Query Analyser, но работавший через ADO с БД Access. В получившем название ADO SQL Tools (MS Access Query Analyzer) и происходила основная разработка расчётов. Время исполнения наиболее тяжёлых пакетов запросов удалось довести до 20–30 секунд на обычном пользовательском ПК или ноутбуке с одноядерным процессором и 1 гигабайтом ОЗУ.
Немало времени было уделено интерфейсу пользователя. Зная, что основная работа по обучению ляжет на его плечи, Поль постарался упростить видимый функционал, внеся немало предложений и уточнений в спецификацию. Кроме того, внешний вид приложения, «шкурка» [116] , должен был соответствовать корпоративной цветовой гамме, для чего в проект был привлечён профессиональный график. По одёжке встречают.
Для обеспечения процесса на площадке заказчика пришлось организовывать минимальный набор из трех изолированных сред: разработки, тестирования-приёмки и эксплуатации. С точки зрения 2012 года мощность сервера вызывает улыбку, лишь недавно ему добавили памяти, доведя объём ОЗУ до 4 гигабайт. Но распределённая обработка данных вкупе с использованием множественной обработки на SQL позволила обойтись столь скромными ресурсами. Добавлю, что корпорация дважды представляла систему на международной автомобильной выставке EquipAuto в 2007 и 2009 годах. Ролик с соответствующим видео и сейчас можно найти на веб-сайте. Неплохой бонус к успешно внедрённому продукту, сделанному при удачной организации процесса и мотивации основных участников.
Архитектура сокрытия проблем
В 2008 году крупный разработчик ERP-системы для розничной торговли оказался в числе наших клиентов. Что же хотела компания с 25-летней историей, двумя сотнями сотрудников и множеством клиентов в Европе и Северной Америке, среди которых такие бренды, как Naf Naf, Vieux Campers, Tally Weijl, Guess, от небольшой программистской фирмы, вчерашнего «стартапа»?
Новая версия системы «по всем правилам архитектуры», подобно каменному цветку, не выходила. Сроки затягивались, приёмки переносились, инвесторы нервничали. Не знаю, кому пришла в голову идея, но фирма решила попробовать в деле так называемую «программную фабрику» (
Проведённый Марком, нашим консультантом, уже самый первый аудит во время командировки в Монпелье принёс очень интересную информацию к размышлению. Предыдущая версия была реализована в классической клиент-серверной технологии в среде Microsoft. То есть SQL Server, «толстый клиент» или веб-клиент под ASP.Net с разделяемой на уровне сборок логикой. Все работало прекрасно до некоторого времени. А время, поскольку клиенты крупные, подошло быстро, за несколько лет. База данных разрослась, время отклика как интерактивной работы, так и пакетов увеличилось, производительность продолжала понемногу деградировать. Например, обработка консолидациирезультатов торговли за сутки стала превышать эти самые сутки.
Программисты даром времени не теряли и упомянутую консолидацию переписывали три раза. Сначала на SQL, но с курсорами, получив ещё худший результат. Потом попытались избавиться от курсоров, но всё равно не смогли достигнуть требуемой производительности. Потом в команде каким-то образом появились специалисты, сказавшие: «Это не объектный подход!» Они переписали всю обработку на C#, окончательно похоронив производительность модуля.
База данных у клиентов – порядка одного терабайта, с примерно 500 миллионами строк в самой большой таблице, соответствующей истории за несколько лет. В версии-«бабушке» использовались технологии «старой школы» вроде архивации, благодаря чему она как-то справлялась с объёмами, хотя бы и за счёт вывода данных из оперативного контура. Но смена СУБД на более мощную из «большой тройки» и более производительное «железо», видимо, произвела на разработчиков обманчивое впечатление, что всё решится как-нибудь само.
Физическая архитектура хранения, секционирование таблиц, оптимизация индексов и запросов по выборочной статистике – эти вопросы всерьёз не рассматривались, база данных тихо кряхтела одним файлом, правда, на мощном 16-ядерном сервере с 32 гигабайтами памяти и быстрым дисковым массивом.
Разработка между тем шла дальше. Новый толстый клиент работал через слой WCF с сервером приложения. Ведь каждому «специалисту» известно, что если данные в СУБД обрабатываются медленно, то необходимо их оттуда загодя вытаскивать, кэшировать и обрабатывать на сервере приложений. Вдруг, так быстрее получится?
Однажды я наблюдал, правда, уже в другом продукте, как обрабатывали таким образом матрицу прав доступа. Две сотни пользователей, десять миллионов объектов и voila – списки размером порядка 100 миллионов элементов сидят в памяти сервера приложения, где со скрипом тормозов обрабатываются запросами LINQ. Выдавать из СУБД информацию, уже прошедшую необходимые фильтры доступа, почему-то оказалось сложнее.
Вот под это развитие и было решено использовать программную фабрику, чтобы генерировать рутинный код отображения таблиц на объекты, объектов, на их посредников (
Для опытной разработки нам был предложен относительно новый модуль прогнозирования продаж. В ходе реализации большая часть обработки там все-таки была написана на SQL. Поэтому, несмотря на отсутствие администрирования базы данных и несоответствующую архитектуру хранения, удалось выжать что-то близкое к возможному максимуму. Например, расчёт части прогноза выполнялся несколько секунд. Что оказалось быстрее, чем пропуск результатов через все слои и загрузка отображающих форм WPF, закодированных со всеми «лучшими практиками».
Можно ли, будучи в здравом уме, представить себе, чтобы обработка данных шла быстрее их передачи между слоями системы и отображения? Для этого надо серьёзно постараться в освоении «паттернов», нагромоздить кучу вроде бы правильного, но бессмысленного кода с высокой цикломатической сложностью, глубинами иерархий и связностью классов. Ситуацию не спасала автоматическая генерация кода большей части этого Ада Паттернов по сравнительно простой модели с несколькими десятками сущностей.
Упомянутую проблему консолидации нами было предложено решить с помощью кубов OLAP. Действительно, после такой переработки, процедура стала идти вместо суток несколько часов, причём, что в MOLAP [117] , что в ROLAP [118] вариантах. Что, собственно, означает: при правильной организации физического хранения и грамотном SQL-коде как минимум тех же результатов можно было бы добиться, не выходя за пределы реляционной БД. Например, наше пожелание создать в определённой таблице кластерный индекс не встретило понимания и было потеряно в глубинах архитектурного буйства и организационных процедур.
Дальше наступил ожидаемый поворот. Прежняя консолидация использовалась многими модулями в реляционной форме, и переписывать её на работу с OLAP никто в здравом уме не собирался. Поэтому из кубов OLAP информация перекачивалась обратно в исходную реляционную БД, в таблицы наследуемой структуры. Тем не менее новая, странного вида цепочка процессов РСУБД – OLAP куб – РСУБД всё равно выполнялась быстрее, чем все три варианта консолидации, ранее написанные местными умельцами.
Спустя почти год, мы благополучно закрыли проект и, утерев пот со лба, передали модуль на сопровождение заказчику. К тому времени ситуация дошла до попыток внедрения в фирме – продуктовом разработчике – «гибких» экстремальных методик. При наличии штата экспертов предметной области и 25-летнего опыта создания функциональных моделей это означало полный разрыв проектирования с производством.
Через небольшое время фирма была поглощена холдингом Cegid – крупнейшим во Франции поставщиком собственных и приобретённых специализированных отраслевых ERP-решений. Уже имея свои лоскутки по розничной торговле, они просто купили фирму со всеми долгами, потому что сотни крупных клиентов – это не шутка, а серьёзный актив, которому они отныне будут предлагать и свои решения.
Очередной урок, «кейс», экспериментаторам с единственно правильными архитектурами, любителям городить новые слои, чтобы спрятать за ними свою некомпетентность в области СУБД. Не исключаю, конечно, что для некоторых менеджеров, получивших выгоду от поглощения, этот прецедент мог быть и позитивным.
Один из «Технических Дней Microsoft» (TechDays) в 2011 году был целиком посвящён специализации DBA (DataBase Administrator). А выступающий на сцене ведущий эксперт не постеснялся напрямую высказать призыв: «Последние годы я вижу тотальное падение компетенции в области баз данных. DBA, проснитесь!»
Code revision, или Коза кричала
Ревизия программного кода всякий раз напоминает мне эпизод из фильма Г. Данелии «Осенний марафон». Главный герой, преподаватель университета Андрей Бузыкин сидит у своей бывшей сокурсницы Варвары, помогая ей с переводом художественного произведения. Время перевалило за полночь, происходит примерно такой диалог.
– Скажи, Бузыкин, может, я бездарная?
– Не-е-е. .
– Но ты же всё повычеркивал!
– Не всё. . Но вот это, например, я не мог оставить: «Коза кричала нечеловеческим голосом».
Мой коллега, обладатель диплома историка, переквалифицировавшийся в консультанты по BI, как-то посетовал, что он плохой программист. Будучи несколько удивлённым, я успокоил его тем, что в BI программирования как такового немного и критичные куски кода всегда могут помочь написать коллеги соответствующей специализации, стоит обратиться к ним по внутренней рассылке. Хуже, когда вполне программистский коллектив умудряется годами работать без системы контроля версий исходников, и тогда в коде половину объёма составляют закомментированные куски многолетней давности. Выбросить их жалко, вдруг пригодятся. Но и контроль версий с архивацией не спасает от цифровой пыли десятилетий. В подобных залежах порой можно обнаружить настоящие образцы софтостроительных антипрактик.
Например, одна ERP-система много лет назад переносилась из файл-серверной архитектуры в среду клиент-серверной СУБД. Вполне ожидаемо в базе данных обнаруживается таблица типа «мегасправочник», хранящая все ссылки вида «ключ-значение». Структура состоит из трех колонок: код справочника, код значения и само значение. В прежней архитектуре ссылочная целостность поддерживалась приложением, теперь же стандартным образом приспособить для этой цели транзакционную СУБД невозможно, потребуется написать достаточно длинный линейный триггер.
Такой универсализм стал причиной использования мегасправочника одновременно для хранения внутренних счётчиков нумерации записей: текущая величина хранилась в строковом поле колонки «Значение» в формате «префикс; текущий номер». Приложение считывает текущее значение счётчика, анализирует строку, выделяя префикс и величину, переводит величину из строки в целое, увеличивает его на 1, формирует новое значение строки и снова записывает всё это обратно в базу данных.
Кроме перечисленных манипуляций со строкой, вначале делается попытка заблокировать запись через соответствующую опцию SQL-запроса. Мысль правильная, но, к сожалению, блокировка делается вне контекста транзакции, то есть снимается сразу после окончания выполнения запроса. На вопрос: «У вас конфликтов нарушения первичного ключа не было?» был дан самый оригинальный ответ за всю мою практику: «Они нам мешали делать каскадные обновления в связанных таблицах, и мы их удалили, оставив просто индексы».
В другом случае на форме Delphi-приложения имелась группа из двух опций (радиокнопок) для взаимоисключающего выбора. Кнопки были подписаны как «Объём ограничен» и «Объём неограничен». Вроде бы ничего особенного. Но открываем форму и обнаруживаем, что кнопка с надписью «Объём ограничен » поименована программистом как «КнопкаОб Не ограничен». И, разумеется, наоборот. Ошибся человек, бывает…
К счастью, в коде формы есть только одно место, где значения кнопок используются. Видимо, во избежание путаницы процедура оформлена следующим образом:
var ОбъёмТакиОграничен: boolean;
…
if КнопкаОбНеограничен. Выбрана then
ОбъёмТакиОграничен:= true
else
ОбъёмТакиОграничен:= false;
…
ВызовКакойТоФункции(ОбъёмТакиОграничен);Дальше ревизия коснулась SQL-кода. Программист пытался выбрать следующий элемент списка, обрабатывая только первую запись из пришедшего по запросу набора. При этом сортировку он делал совсем по другой колонке, нежели порядковый номер в списке. В итоге выбиралось что угодно, но не следующий элемент.
Не буду утомлять вас другими примерами, надеюсь, вы просто поверите в их многочисленность и оригинальность. Мне хотелось лишь донести простую мысль, что ревизия кода, несомненно, весьма полезная процедура, но как минимум при двух условиях:
• эта процедура регулярная и запускается с момента написания самых первых тысяч строк;
• процедуру проводят специалисты, имеющие представление о системе в целом. Потому что отловить бесполезную цепочку условных переходов может и компилятор, а вот как отсутствие контекста транзакции в обработке повлияет на результат, определит только опытный программист.Дж. Фокс [2] выводит из своего опыта проектной работы в IBM важную мысль, что большой ошибкой является привлечение к процессу внутреннего тестирования и обеспечения качества посредственных программистов. По его мнению, компетентность специалиста в этом процессе должна быть не ниже архитектора соответствующей подсистемы. Действительно, ведь оба работают примерно на одном уровне, просто один занят анализом, а другой – синтезом. Качество кода во многом зависит от степени повторного использования, поэтому приведу простой и доступный способ проверки того, не занимается ли ваша команда программистов копированием готовых кусков вместо их факторизации. Для этого регулярно делайте сжатый архив исходников, например zip с обычным коэффициентом компрессии, и оценивайте динамику роста его размера относительно количества строк. Если размер архива растёт медленнее, чем количество строк, это означает рост размера кода за счёт его копирования.
Наживулька или гибкость?
Приходишь в отечественную компанию, смотришь, как у нее устроено IT, и видишь, что люди просто упали с дуба.
М. Донской, из интервью
Не все гигагерцы и гигабайты расходуются впустую. Кризис в софтостроении, о котором говорят уже более 30 лет, продолжается. В ответ на усложняющиеся требования к программным системам и неадекватные им методологии (технологии), особенно в части моделирования и проектирования, индустрия выставила свое решение. Оно состоит в достижении максимальной гибкости средств программирования и минимизации ошибок кодирования. Проще говоря, если мы не можем или не успеваем (что в итоге приводит к одному и тому же результату) достаточно хорошо спроектировать систему, значит, надо дать возможность быстро и с минимальными затратами её изменять на этапе кодирования. Но принцип для заказчика остался прежним: «Быстро, качественно, дёшево – выбери два критерия из трёх».
Поднимать тему так называемой гибкой (
Причина возникновения экстремальных методик, сосредоточенных на фазе кодирования, не случайна. Американский специалист по методологиям софтостроения Кэпер Джонс в своей книге[23] приводит весьма удручающие статистические данные, например:
• среди проектов с объёмом кода от 1 до 10 миллиона строк только 13 % завершаются в срок, а около 60 % свёртываются без результата;
• в проектах от 100 тысяч до 1 миллиона строк эти показатели выглядят лучше (примерно 25 % и 45 %), но признать их удовлетворительными никак нельзя;
• в проектах примерно от 100 тысяч строк на кодирование уходит около 20 % всего времени, и эта доля снижается с ростом сложности, тогда как обнаружение и исправление ошибок требует от 35 % времени с тенденцией к увеличению.
В любом софтостроительном процессе, будь то заказной проект или продукт для рынка, всегда можно выделить 4 основные стадии:
• анализ, чтобы понять «что делать»;
• проектирование, чтобы определить и запланировать «как делать»;
• разработка, чтобы собственно сделать;
• стабилизация, чтобы зафиксировать результат предыдущих этапов.
Если стадии, органично совпадающие с концептуальным, логическим и физическим дизайном системы, расположить иерархически без обратных связей, то получим классическую схему «водопад», исторически считающуюся первой методологией в софтостроении.
«Водопад» также соответствует разработке «сверху-вниз» в структурном программировании: выделяем самые общие функции системы, проводим их декомпозицию на подфункции, а те, в свою очередь, на подподфункции и так далее, пока не упрёмся в элементарные операции.
Что же не так в схеме? С увеличением сложности реализуемой системы анализ и следующее за ним проектирование начинают занимать всё больше времени. Постепенно обнаруживаются новые детали и подробности, изменяются требования к системе, возникают новые сопутствующие задачи, расширяющие периметр. Приходится, не отдавая проектную документацию в разработку, возвращаться к анализу. Возникает риск зацикливания процесса без конечного выхода какого-либо программного обеспечения вообще.
Из сказанного вовсе не следует, что методология плоха. Просто она имеет свои границы применения, широта которых напрямую зависит не только от опыта аналитиков и проектировщиков, но и от новизны моделируемой предметной области. В достаточно консервативных банковских или промышленных приложениях «водопад» может подойти и для комплексной системы. Если же, например, возникает принципиально новый рынок, то найти опытных подрядчиков проблематично, а бизнес-направление заказчика находится в постоянной реорганизации, поэтому стадия анализа, занимающая больше 3–4 недель, рискует быть малопродуктивной. И не только стадия анализа, но и весь проект в целом. Тут впору подумать над временной автоматизацией в рамках офисного пакета и скриптовых сред вместо комплексного решения.
Очень важно отделить редкую ситуацию « бизнес меняется еженедельно » от гораздо более распространённой « представления команды разработчиков о бизнесе меняются еженедельно ». Если вам говорят о якобы часто изменяющихся требованиях, всегда уточняйте, о чём, собственно, идёт речь.
Но если проблема зацикливания на требованиях может быть успешно решена выбором подрядчиков, уже имевших опыт в построении систем данного типа, то другая, гораздо более значимая проблема несовпадения взглядов заказчика и подрядчика на казалось бы одни и те же вещи стабильно проявляется с ростом проекта. Даже если принять во внимание, что только 20 % требований специфичны для заказчика, тогда как 80 % исходят непосредственно от предметной области инвариантно среде и контексту, то эти 20 % способны угробить весь проект.
Для снижения рисков такого рода в конце 1980-х годов была предложена спиральная модель софтостроения.
Необходимо отличать спиральную модель от итеративной . Спиральная модель сходится в точку «система готова», итеративная модель в общем случае не сходится, но обеспечивает реализацию всё новых и новых требований.
Рис. 15. Спиральная модель с двумя витками
Ключевой особенностью спиральной технологии является
Спиральная модель не навязывает присутствие всех стадий на каждом витке. Вполне может статься, что первый же прототип будет удачным, а функциональная и техническая архитектуры соответствуют требованиям. Тогда финальные витки будут фактически состоять только из разработки и стабилизации.
Слабым звеном в спиральной методологии является определение длительности очередного витка, его стадий и соответствующее выработанному плану управление ресурсами. Пока анализ не выдал концептуальные модели, проектировщики и ведущие программисты ограничены техническими требованиями, тогда как рядовые программисты просто ожидают спецификации. Но неудачно сократив фазу анализа или проектирования на первом витке, тем самым можно увеличить их общее количество, рискуя выйти за рамки первоначальной оценки сроков и бюджета.
Тотальный анализ и проектирование вырождают спираль в водопад, тогда как формальный подход, «для галочки», выдающий бесполезные для программистов спецификации, превращает спираль в бесконечный цикл, прерываемый управленческим решением. Поиск компромисса в такой ситуации – трудная задача многокритериального выбора, в большой степени зависящая от опыта и здравого смысла руководителей рабочих групп и проекта в целом.
Таким образом, из научной плоскости мы переходим в область экспертных оценок. Поэтому слово «методология» справедливо вызывает у многих негативное отношение. Правильнее было бы говорить о технологии ведения со-фтостроительных проектов, но исторически появившийся термин так просто из обращения не выкинуть. Да и надо ли?
Создатели итерационных методологий, также называющихся гибкими (
Ключевой особенностью гибкой методики является наличие мифологического титана – владельца продукта (
В итоге мы получаем знакомую софтостроительную схему «снизу-вверх», появившуюся на свет гораздо раньше «водопада», с его упорядочивающей моделью «сверху-вниз». То есть мы не знаем точно, что хотим получить в целом, но знаем отдельные функции, реализовав которые, мы, возможно, придём к решению.
С точки зрения проектирования такой подход даже хуже обсуждавшихся прецедентов в UML. Прецеденты использования, «кейсы», хоть как-то формализуются, накапливаются и обобщаются на стадии, формально отсутствующей в гибкой разработке. Поэтому новое требование-прецедент, поступившее на вход, «обобщается» с прежними уже на стадии разработки, приводя к необходимости серьёзной реструктуризации (рефакторинга) кода программ и подпорок из тестов.
Не буду заниматься критикой, её можно без труда найти даже в энциклопедических статьях. Поговорим лучше о некоторых позитивных моментах, которые вносит гибкая методология.
Для программистов позитив, к сожалению, изрядно разбавлен издержками производственного процесса. Методология, по сути, направлена на увеличение времени работы с клавиатурой и не располагает к размышлениям. Пиши код! Поэтому для стимуляции персонала процесс окружен религиозной атрибутикой, манипуляциями, иносказаниями и метафорами. С другой стороны, требования к уровню программиста ограничиваются знанием конкретных технологий кодирования, стандартных фреймворков, «умением разбираться в чужом коде» и «умением работать в команде», уже упоминавшимся в словаре для начинающего соискателя. Способность решать олимпиадные задачки здесь от вас не требуется. Скорее, наоборот, будет помехой.
Позитив для заказчика в том, что, осознавая свою несхожесть с мифологическим титаном мысли, он может достаточно быстро увидеть сформулированные требования и сценарии в реализации, отлитыми, разумеется, не в бетоне, а в гипсе, и на практике понять их противоречивость и неполноту. После чего он может переформулировать существующие и добавлять новые требования с учётом уже набитых шишек. Тем не менее с ростом сложности системы возрастает и риск увеличения стоимости внесения изменений. И если проект выходит за рамки бюджета, то «козлом отпущения» становится именно владелец продукта.
Другой позитив для компании-заказчика состоит в непосредственной близости выполняемой подрядчиком работы. Зачастую «гибкие» команды работают на площадке компании и доступны в любой рабочий момент. Если заинтересованному лицу не хватает информации, он может просто подойти и посмотреть на месте, поговорить с исполнителем и тем самым восстановить расстроившееся было душевное равновесие.
Ничего не напоминает? Всего 15–20 лет назад эти же подрядчики сидели на тех же площадках, но назывались «отделами АСУ» и входили в штат фирмы. Да, теперь сторонние программисты обходятся вдвое-втрое дороже прежних сотрудников, зато в любой момент можно устроить имитацию конкурсного отбора исполнителя, а при необходимости быстро свернуть непрофильную деятельность, не испытывая законодательных и профсоюзных затруднений с сокращением персонала.
Позитив для подрядчика состоит в том, что «гибкая» разработка позволяет вовлечь в проект как можно больше разработчиков с менее высокими требованиями к квалификации. Это позволяет содержать больше сотрудников в штате, включая оффшорные команды. Будучи поставленным перед выбором между небольшой программистской фирмой с квалифицированным персоналом и софтверхаузом-«тысячником», крупный заказчик в общем случае склонится ко второму варианту.
Как вы заметили, я начал с «водопада» и завершил «гибкой разработкой». Хотя адепты обоих подходов испытывают друг к другу сложные чувства, не бросилось ли вам в глаза их разительное сходство? Обе методологии зацикливаются с увеличением сложности проекта. Только «водопад» замыкается на тотальном анализе и проектировании, а гибкая методика «уходит в себя» на разработке и стабилизации, что, в общем, даже не скрывается, а рисуется на слайдах презентаций. Из этого следует вывод, что успешно выполненный в «водопадной» схеме проект может быть также в большинстве случаев выполнен в «гибкой» разработке. И наоборот, если не касаться вопроса людских ресурсов. Дело в масштабе.
Труднее формально определить пороговую сложность системы, за которой начинаются проблемы. Я обозначил бы её как систему, которую даже один опытный аналитик способен охватить формальными моделями за относительно короткий срок, исчисляемый несколькими неделями. Например, заказной, то есть нетиражный, пакет для расчёта зарплаты, подсистема формирования и массовой рассылки счетов клиентам или система складского учёта в компаниях среднего и крупного масштаба.
Как происходит зацикливание даже в простых случаях? Программисты классифицируют коров и столы по признаку наличия четырёх ножек, после чего всю энергию тратят на то, чтобы написать интерсепторы, аспекты, применяют мощные инструменты рефакторинга кода для того, чтобы
Конечно, это просто шутка, в которой немало правды. В реальности же наиболее распространённым явлением становится частичное дублирование структур и функциональности отдельных подсистем, реализуемых разными командами и владельцами. Поскольку общего взгляда на систему нет.
Борьба с зацикливанием с обеих сторон нередко принимает причудливые формы.
Совсем недавно мне выдалось консультировать по сугубо техническим вопросам одну скрам [120] -команду. Проект был заказан крупным автопроизводителем и касался разработки бортовой системы мониторинга и управления периферийным оборудованием. Функциональные спецификации составили вместе толстую пачку листов формата А4, напечатанных с двух сторон, думаю, в общей сложности не менее 2 тысяч страниц. Понятно, что никто из программистов в здравом уме не стал читать документацию целиком, а взяли несколько функций, под которые и начали строить реализацию. После четырёх месяцев работы выяснилось, что архитектура эволюционным путём не выстраивается, хотя заказчик регулярно видел разные красивые экраны с заглушками и симуляцией приходящих от устройств прерываний. Разумеется, и я не стал читать все эти тысячи страниц, ограничившись весьма интересным документом, содержащим иерархию функций, то есть фактически глоссарий функциональной декомпозиции системы. Из документа следовало, что архитектура, состоящая из набора служб, доступных на общей шине (здравствуй, CORBA), охватывала несколько верхних уровней иерархии. Однако такая перестановка означала переделку большей части системы, тогда как регламент не разрешал увеличить время очередной итерации до минимально необходимых 2–3 месяцев, а бюджет и ресурсы не позволяли начать параллельную стройку. В итоге команда осталась в прежней архитектуре, осознавая на собственной шкуре, что затраты на добавление новых функций растут.
Совсем свежий пример: настоящее время, крупная корпорация – строится внутренняя система управления предприятием. Официально написаны 3,5 тысячи страниц функциональных спецификаций, полтора десятка программистов в том же «скраме» уже приступили к реализации отдельных частей. Через год-полтора будет ясно, получилось ли что-нибудь в итоге.
Эти два примера вполне соответствуют тенденциям взаимного перекладывания ответственности на сложных проектах. Заказчик осознаёт, что реализовать спецификации своими силами невозможно, прежде всего потому, что при таком объёме они тем не менее неполные и неизбежно содержат противоречия. Подрядчику же в принципе наплевать на спецификации, он будет крутить итерации, честно реализуя заявленный функционал и отрабатывая бюджет. Получился коровник на подпорках с покосившимися заборами и дырявой крышей вместо современного агрокомплекса? Извините, всё по спецификации, каждые две-три недели вы видели расцвеченные фотографии разных участков возводимого сооружения.
Синтез «водопада» сложной системы, итоги проектирования которого подаются на вход «гибкой» производственной машины кодирования и стабилизации – что может быть бессмысленнее и беспощаднее?
Кроме частных примеров относительно крупных заказов, современная тенденция – огромное число некритичных проектов, программ и систем-пристроек к основной КИС. Масштаб проектов небольшой (сотни тысяч строк кода), заказчик точно не знает, что хочет получить в итоге, а подрядчик не имеет опыта в данной предметной области, если вообще имеет хоть в какой-то, и поэтому не может ему объяснить, что кактусы за полярным кругом не растут. Для такой ситуации привлечение команд с имеющими требуемый опыт квалифицированными специалистами и технологиями предметно-ориентированных языков или разработки по моделям маловероятна, поэтому пусть уж лучше итеративная методология «наживульки», чем никакая, как оно зачастую бывало в эпоху штатных отделов АСУ.Тесты и практика продуктового софтостроения
Привожу комментарий Максима Крамаренко, руководителя компании Trackstudio, выпускающей одноимённый продукт для управления задачами в софтостроении.
У нас тотальные модульные тесты, что называется, «не пошли». Сложилось впечатление, что их хорошо использовать для продуктов, которые реализуют какой-то стандарт или спецификацию (СУБД, веб-сервер), но для тиражируемого веб-приложения это смертельно. Причины:
1. При изменении спецификаций затраты времени на приведение в актуальное состояния тестов могут быть куда больше, чем на собственно код. Скажем, если пользователи захотят поменять синтаксис SQL в СУБД и писать SEARCH вместо SELECT, то это одно изменение продукта в одном месте приведёт к переписыванию почти всех тестов. Если для СУБД такие пожелания пользователей – редкость, то для менее стандартных программ – обычное дело.
2. Сбои, которые могут выловить тесты (повторяемый сбой в модуле, ранее уже исправлявшийся), – довольно редкое дело. Гораздо чаще сбои возникают в интеграции разных технологий, которые сложно автоматически протестировать. Например, при работе под таким-то браузером при таких-то настройках вот этот JavaScript работает неправильно.
3. Наличие модульных тестов сильно затрудняет масштабный рефакторинг. Если у нашего приложения есть какой-то внешний API, то все, что ниже, мы можем менять быстро и без особых проблем. Но если для этого низкоуровневого кода есть тесты, то их придётся основательно переделывать. (Прим. автора: при этом функциональные тесты, работающие с API, переделывать не требуется.)
4. Если не напрягаться с выпуском раз в 2 недели, то возможность быстро что-то протестировать не так уж и важна. Мы себя совершенно нормально чувствуем с испытанием бета-версии в течение 2–3 месяцев, зачем чаще?
5. Одни из наших конкурентов широко используют agile-методы и TDD [121] , но что-то оно им не очень помогает писать безошибочный код. Мы сравнивали количество найденных проблем в течение месяца-двух после major release, у нас показатели лучше в разы, если не на порядок. Частый выпуск версий просто не позволяет им довести код до ума и провоцирует исправление старых и серьёзных проблем методом написания «залепени». (Прим. автора: исправление ошибок, добавляющее новые проблемы.)
6. Я совсем не уверен, что пользователи хотят получать новую версию раз в 2 недели. TrackStudio 3.5 вышла примерно через полгода, после TrackStudio 3.2, и мы получили много негативных откликов, что такие частые релизы заставляют их обновлять локальную документацию и задерживают их собственные процессы на несколько месяцев. Многие пользователи совершенно спокойно живут без обновлений несколько лет. Если они купили продукт – значит, он делает то, что они хотят. Если чего-то не делает – они все равно уже нашли workaround (обходное решение), им всё равно.
7. Для корпоративного софта пользователи хотят длительного периода поддержки, пара лет, минимум. Если мы выпускаем продукт раз в 2 недели и находится серьёзная ошибка в версии годичной давности, то нам её нужно будет исправить примерно в 40 ветках. Конечно, править 40 веток кода никто не будет, пользователям сообщат, что ошибка будет исправлена в следующей версии, многие пользователи перейти на неё не смогут (см. п.6) к большой радости конкурентов с предложениями типа competitive upgrade offer.
Максим затронул важную тему модульного тестирования, являющуюся краеугольным камнем всех гибких методик: если изначально неизвестно, что выстроится в итоге, дом или коровник, то подпорки у его стен должны быть в любом случае.
Излишне религиозная атмосфера превратила вполне здравую и работающую с 1970-х годов технологию модульных тестов в настоящий карго-культ. Подобно жителям островов Меланезии, старательно строящих соломенные аэропланы для привлечения сбрасывающих груз транспортных самолётов, адепты 100 % покрытия кода модульными тестами считают, что это обеспечит успех проекту.
Разработка модульных тестов – это тоже разработка. Для 100 % покрытия потребуется примерно столько же времени, сколько и на основную работу. А может, и больше, смотря как подойти к делу. По моим наблюдениям, соотношение объёмов рабочего и тестирующего кода примерно 1 к 2.
В отличие от тестов функциональных, завязанных на интерфейсы подсистем, модульные тесты требуют переработки одновременно с рефакторингом рабочего кода. Это увеличивает время на внесение изменений и ограничивает их масштаб, приучая разработчика минимизировать реструктуризацию , заменяя её надстройкой, быстро трансформирующей архитектуру в Ад Паттернов.
Модульные тесты тоже бывают сложными, а значит, с высокой вероятностью могут содержать ошибки. Тогда возникает дилемма: оставить всё как есть или перейти к мета-тестированию, то есть создавать тест для теста.
Наконец, модульный тест – это самый нижний уровень проверок. Прохождение серии модульных тестов вовсе не гарантирует, что пройдут функциональные тесты.
Практические выводы. Соизмеряйте затраты на создание и поддержу автоматизированных модульных тестов с бюджетом проекта и располагаемым временем. Тем более плохо фанатично навязывать разработку «от тестов», умалчивая о названных особенностях и не учитывая другие возможности. Например, код, генерируемый по моделям, вообще не требует модульных тестов.
Говорящие изменения в MSF и выключатель
Мне с давних пор импонирует подход, описанный в MSF [122] . Прежде всего масштабируемостью, относительной логичностью, разумными ограничениями на совмещение ролей в проекте. Но целью написания этих строк вовсе не является продвижение технологий известной всем корпорации, думаю, и без меня для этих целей найдутся хорошо оплачиваемые консультанты.
Интерес представляет следующий факт: в своей текущей редакции MSF 4.0 была разделена на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
CMMI, или Capability Maturity Model Integration, – модель зрелости процессов организации вообще и софтостроения в частности. Ключевое слово здесь именно «зрелость», описываемая в CMMI несколькими уровнями организации: от хаоса до системы качества.
Соответственно, одно из нынешних направлений MSF предназначено для достижения зрелости процессов софтостроения или дальнейшего улучшения процессов уже более-менее зрелых организаций. А второе… для гибкой разработки.
В завершение темы было бы непростительно не вспомнить о производственной системе Toyota, которую почему-то считают основой того же скрама. Ключевой особенностью системы в Тойоте является принцип «дзидока» (
Поделиться книгой: