Траблы-грабли-бумс!

Личный опыт не всегда может использоваться в качестве критерия истинности.

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

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

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

– Любую систему придется изменять на всех этапах ее жизненного цикла.

– Любые обещания, что что-то не будет меняться, а уж тем более расти в объеме, никогда не выполняются.

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

– Если одна и та же информация хранится в двух местах системы, то через неделю эксплуатации в этих местах будет разная информация.

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

Я совсем не считаю, что свод правил проектирования вечен и неизменен, но если вы хотите какое-то из этих правил нарушить, то сначала поймите, почему оно появилось и какие суперпреимущества вам дает его отмена.

Еще одна очевидность, про которую забывают разработчики: удобство и скорость разработки, безусловно, важны, но все-таки система в итоге оценивается по ее потребительским свойствам. Если есть выбор, написать семь процедур или одну, но в последнем случае скорость отклика системы изменится с 0,5 с на 5 с, то писать надо семь процедур.

Впрочем, уверен, что этот раздел написал без толку. Похоже, это тоже одно из вечных правил.

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

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

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

Никакой. НИКАКОЙ! НИКАКОЙ!!! Только циферки, которые однозначно определяют объект, и никакого другого смысла. Этому учили еще до появления классических работ Дейта и Кодда.

Но все-таки в каждом проекте у кого-нибудь начинает зудеть и чесаться.

«А давайте первая цифра кода у нас будет номером цеха, который выпускает изделие, вторая – номером отдела, который занимается продажей…» И что произойдет, когда у вас появится десятый цех или отдел? А когда изделие начнут в двух цехах собирать, какую цифру ставить? И как перевести производство из одного цеха в другой? Менять код изделия или запрещать перевод производства?

Да, а еще в код иногда засовывают буквы. А буква «А» есть как в русском алфавите, так и в латинском. И – увы! – для системы это РАЗНЫЕ буквы (хотя и не всегда можно это объяснить пользователю). Это создает много радости при ручном вводе новых идентификаторов и еще больше радости, если справочники и транзакции приходится загружать из другой системы. – Д. К.

«А давайте включим в id товара код группы и подгруппы…» А что вы будете делать, когда потребуется поменять код группы или подгруппы? Лопатить всю базу, разыскивая нужный id, и заменять его на другой? «А мы ничего не будем делать. Все равно в 90 % случаях группа и подгруппа будет верной». Вы этой мыслью с главбухом поделитесь. Ему очень понравится правильный расчет НДС с вероятностью 0,9. И не исключено, что на одного плохого проектировщика станет меньше.

«А давайте у нас id накладной и будет ее номером». Не давайте. Когда система встанет, накладные будут выписывать вручную, а потом в систему нужно будет ввести именно те номера, которые оказались на бумажных накладных, даже если это одинаковые номера. И накладные поставщиков неплохо завести в систему под теми номерами, под которыми они нам выданы.

И выучите, наконец, зазубрите, напишите на мониторе, сделайте татуировку на лбу: вводя любое информационное поле для любого объекта, можно ошибиться или передумать. Поэтому идентификационный код всегда—всегда!!! – должен генерироваться автоматически и не иметь никакой информационной нагрузки.

Суббота, десять вечера. Из продовольственного магазина, в котором внедряется пилотный проект складской системы, звонит кладовщик. Едва не плача, он сообщает, что принял товар на склад, а секции его выдать не может, поскольку товар пропал. А если его срочно не продать, то он протухнет.

Приезжаю. Пытаюсь найти товар на складских карточках. Действительно, найти не получается. А приходная накладная есть. В ней все правильно. Смотрю отчет по товародвижению – в нем все на месте. Проверяю суммарные остатки по складу – накладная учтена. То есть товар на складе есть, а вот найти его нельзя. Правда, на этом складе уже восемь тысяч карточек, так что визуально товар не обнаружить, если даже он есть. Уточняю, что делал кладовщик.

– Это новый товар. Я его сначала завел по бумажной накладной в справочник номенклатуры, потом ввел саму накладную. А потом посмотрел на сам товар и понял, что это тефтели, а не котлеты, как написано в накладной.

– И как ты поступил?

– Исправил запись в справочнике номенклатуры. А в накладной все изменилось само.

– Кажется, я понял, – отвечаю я, подумав. – Смотри, – и набираю в строке поиска «котле». Экран прокручивается, и на нем подсвечивается строчка «Тефтели». За спиной раздается восхищенное «Ой», но я в это время уже представляю, что я сделаю с разработчиками в понедельник.

Но воскресенье, предшествующее встрече, их спасает. Я не только никому ничего не пытаюсь оторвать, я даже могу разговаривать, используя только слова литературного русского языка:

– Вы что, название товара записываете на складской карточке?

– Мы только первые пять символов записываем, чтобы поиск шел быстрее.

Тут я становлюсь даже ласковым:

– А что вы делаете, если складские карточки уже созданы, а я наименование в номенклатурном справочнике поменяю?

– Кажется, ничего не делаем.

– То есть если я завел на склад «котлеты», а потом исправил в справочнике номенклатуры название на «тефтели», то что я увижу на карточке?

– «Тефтели».

– А искать мне что нужно?

– «Котлеты»… Наверное, это не совсем правильно…

– Не совсем правильно?

– Согласен, это совсем неправильно. Мы к следующему обновлению переделаем…

Я начал именно с примера, чтобы не пугать читателя высоконаучными словами. Но в приведенном случае были нарушены принципы проектирования баз данных, описанные в классических работах 1970-х годов. Таблица базы «Складские карточки» не находится в третьей нормальной форме. Про это уже столько понаписано, что мне и добавить нечего. Появление новых СУБД и новых способов поддержания зависимостей в базе данных совершенно ничего не меняет: грабли продолжают работать даже при использовании триггеров и джобов (заданий, запускаемых автоматически в определенные моменты суток или через определенные временные интервалы).

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

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

Вы задумывались, что произойдет, если джоб, который стартует каждые 15 минут, в среднем работает два часа? А что будет, если выполнение триггера займет две минуты? В обоих случаях последствия могут быть разнообразными, но всегда неприятными и, что еще хуже, непредсказуемыми.

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

Если в системе появляются элементы документооборота, то документы (проекты договоров, заявки на материальное снабжение, предложения по изменению справочников и т. п.), созданные или исправленные одним пользователем, необходимо отправлять на согласование другим пользователям. Стадию прохождения документа по цепочке обычно называют статусом документа. Цепочки таких согласований бывают достаточно длинными. Естественно, встает вопрос, кто должен увидеть и кто обработать документ, находящийся в соответствующем статусе.

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

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

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

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

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

При заведении нового пользователя в систему его права должны быть пусты. Только после задания роли у пользователя появляются права в соответствии с этой ролью.

Права, контрольные механизмы и прочие средства информационной безопасности (ИБ) – отдельная история при разработке и внедрении всех систем. Мало того что требования ИБ не принято закладывать при разработке систем (иначе откуда тогда столько систем, хранящих пароль на доступ к базе данных в виде незашифрованного текстового файла?), так даже и те средства, которые в системах все-таки реализованы, при внедрении систем не настраиваются почти никогда (наверное, на это уже не хватает сил после борьбы с функциональностью). Например, из десятка компаний, в которых мне пришлось побывать за год, на половине администраторскими правами в приложении были наделены все пользователи, и практически на всех пользователей в базе данных присутствовали учетные записи с паролями «по умолчанию». И если настраивать межсетевые экраны уже многие научились, то добыча любой информации изнутри локальной сети – до сих пор задача, с которой может справиться любой, кто умеет давить на кнопки.

При этом компании достаточно серьезно говорят о конфиденциальности… Вон она, эта конфиденциальность, – висит в открытом доступе. – Д. К.

Права по разным ролям у одного пользователя должны объединяться, а не интерферировать способом, неизвестным даже самому разработчику. А это тоже бывает достаточно часто

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

А ведь с помощью таких дырок можно безнаказанно ломать и финансовые документы. Если некто хочет ликвидировать накладную о выдаче товара себе, любимому, или своему любимому контрагенту, можно не трогать саму накладную, а удалить контрагента этой накладной или заменить его на другого. То есть «всего-навсего» изменить справочник контрагентов. При отсутствии протоколирования действий администратора системы все можно провернуть еще проще: некто прописывает логин нового пользователя системы с правами изменять накладные, входит под этим логином в систему, удаляет накладную, потом снова заходит с правами администратора и удаляет «засвеченный» логин.

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

Формат XML придумали для того, чтобы обмениваться информацией между разнородными системами, и в этом смысле его значение сложно переоценить. Но он хорош именно для обмена данными. Использовать этот формат для хранения больших объемов информации, предназначенной для постоянного использования, переработки и изменения, не следует. Для этого существуют базы данных и системы управления ими. Но вот незадача: чтобы манипулировать информацией в таблицах базы данных с разными полями, нужно писать разные процедуры, а в XML все можно делать ровно одной.

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

И все работает, пока такие записи нужны поштучно. Не так много времени требуется и для того, чтобы вывести пару десятков таких записей на экран. Но вот бизнес-заказчик просит отчет, который требует перелопачивания всех таких записей в базе. Процедуру для отчета написать получается, но работает она уже часами. Оно и понятно: все средства СУБД, заточенные для выбора нужной информации (например, индексирование), теперь применить нельзя, ибо нужно залезать в каждую запись, расшифровывать нотацию XML и только затем выяснять, нужна ли она для обработки.

Нетленные универсальные грабли

Еще одни вечные грабли – попытка вместо решения конкретной задачи создать универсальное решение. Эти грабли бывают программистскими (сооружается, например конструктор форм или генератор отчетов) или консультантскими (сооружается «универсальный модуль управления процессами» или еще какой-нибудь «модуль управления понятиями»). Результат можно наблюдать во многих тиражных системах – каждая содержит по четыре-пять различных генераторов отчетов (причем на практике все равно отчеты либо программируются, либо получаются специализированными средствами напрямую из базы данных) и «модуль управления бизнесом» (при ближайшем рассмотрении – еще один генератор отчетов). – Д. К.

При следующей просьбе бизнес-заказчика обработка информации в отчете усложняется. Процедура снова пишется, но через полчаса после ее запуска сервер приложений падает, всхлипнув напоследок: «Out of memory»

Описываемые грабли имеют небольшой размер, поэтому бьют не по лбу, а гораздо ниже. Но бьют гораздо чаще остальных. Это единственные грабли, на которые при мне наступили более ста раз.

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

Рисуете вы накладную, записываете в ней цену 1 рубль 5 копеек, то есть 1,05, а Excel сам догадывается, что вы имели в виду 1 мая, что и записывает в ячейку. Вы ему кричите: «Я хотел ввести число!» – и он соглашается: «Число, так число», – и вы с изумлением обнаруживаете в ячейке 39569.00…

Пока вы вводили данные руками сами, все было не очень страшно: попили валокордина, установили у ячейки правильный формат и ввели то, что хотели.

Гораздо веселее, когда в Excel выплюнула отчет информационная система, а программист, который писал этот отчет, не знал, что надо описать форматы ячеек, в которые выводил информацию, или поленился это сделать. Потому что теперь мест в таблице, где стоит то 3 марта, то 31 декабря, может оказаться несколько тысяч.

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

Как следствие, меняться табличной информацией лучше все-таки в старом добром формате DBF или в новомодном XML, которые даже Excel будет понимать правильно.