Записки автоматизатора. Профессиональная исповедь
Шрифт:
При каждом скачке в развитии вычислительной техники у разработчиков информационных систем возникает эйфория, связанная со снятием ограничений на объемы хранимой информации и скорости ее переработки. Но всякий раз выясняется, что, даже вооружившись современными высокопроизводительными серверами, все можно спроектировать настолько плохо, что работать это не будет. Или будет работать годами.
Формат XML придумали для того, чтобы обмениваться информацией между разнородными системами, и в этом смысле его значение сложно переоценить. Но он хорош именно для обмена данными.
И обрадованный этим разработчик, «вооруженный передовой технологией», создает в базе таблицы с ключом и одним очень длинным текстовым полем, куда запихивает информацию в XML.
И все работает, пока такие записи нужны поштучно. Не так много времени требуется и для того, чтобы вывести пару десятков таких записей на экран. Но вот бизнес-заказчик просит отчет, который требует перелопачивания всех таких записей в базе. Процедуру для отчета написать получается, но работает она уже часами. Оно и понятно: все средства СУБД, заточенные для выбора нужной информации (например, индексирование), теперь применить нельзя, ибо нужно залезать в каждую запись, расшифровывать нотацию XML и только затем выяснять, нужна ли она для обработки.
Еще одни вечные грабли – попытка вместо решения конкретной задачи создать универсальное решение. Эти грабли бывают программистскими (сооружается, например конструктор форм или генератор отчетов) или консультантскими (сооружается «универсальный модуль управления процессами» или еще какой-нибудь «модуль управления понятиями»). Результат можно наблюдать во многих тиражных системах – каждая содержит по четыре-пять различных генераторов отчетов (причем на практике все равно отчеты либо программируются, либо получаются специализированными средствами напрямую из базы данных) и «модуль управления бизнесом» (при ближайшем рассмотрении – еще один генератор отчетов). – Д. К.
При следующей просьбе бизнес-заказчика обработка информации в отчете усложняется. Процедура снова пишется, но через полчаса после ее запуска сервер приложений падает, всхлипнув напоследок: «Out of memory»
Описываемые грабли имеют небольшой размер, поэтому бьют не по лбу, а гораздо ниже. Но бьют гораздо чаще остальных. Это единственные грабли, на которые при мне наступили более ста раз.
Для работы с таблицами Excel штука очень удобная, но, к сожалению, обладающая зачатками интеллекта, который иногда применяет чрезвычайно не к месту. Например, если вы заранее явно не указали формат ячейки, в которую помещаете информацию, Excel сам догадывается, что вы имели в виду.
Рисуете вы накладную, записываете в ней цену 1 рубль 5 копеек, то есть 1,05, а Excel сам догадывается, что вы имели в виду 1 мая, что и записывает в ячейку. Вы ему кричите: «Я хотел ввести число!» – и он соглашается: «Число, так число», – и вы с изумлением обнаруживаете в ячейке 39569.00…
Пока вы вводили данные руками сами, все было не очень страшно:
Гораздо веселее, когда в Excel выплюнула отчет информационная система, а программист, который писал этот отчет, не знал, что надо описать форматы ячеек, в которые выводил информацию, или поленился это сделать. Потому что теперь мест в таблице, где стоит то 3 марта, то 31 декабря, может оказаться несколько тысяч.
Еще интереснее получается, когда вы пытаетесь с помощью таблиц в Excel выравнивать информацию в двух информационных системах: количество моментов, в которые этот технический гений сможет вам услужить, будет гораздо больше. И уже несколько программистов должны будут не забыть предварительно описать форматы.
Как следствие, меняться табличной информацией лучше все-таки в старом добром формате DBF или в новомодном XML, которые даже Excel будет понимать правильно.
Шизофреническая глава про абсолютно нормальных людей
Я до сих пор верю в людей. Но не следует распространять эту веру на пользователей информационной системы. И все эти нравоучительные «Поставь себя на его место» здесь совершенно не годятся. Я на месте любого юзера все равно буду понимать, что я хочу сделать, оценивать последствия своего поступка, контролировать свои действия. Наверное, каждый айтишник участвовал в таком диалоге:
– Андрей, у меня компьютер завис.
– А на какие кнопки ты нажимала?
– Откуда я знаю?
Сколько предупреждений и вопросов ни задавай перед выполнением критической для системы операции, как ни заставляй пользователя выбирать ответ не по умолчанию, отвечать сначала «Да», потом «Нет», он все равно сначала произведет все необходимые манипуляции и, только увидев сообщение «Все проводки за 2005 год успешно удалены», воскликнет: «Ах, что же я наделал!» Поэтому обычному пользователю вообще нельзя доверять выполнение критических операций. Их должен производить адекватный администратор информационной системы по письменной заявке руководителя соответствующего подразделения.
Кстати, это еще одна причина для грамотного разграничения доступа. Если мы не прячем информацию, это еще не означает, что мы готовы ее потерять. – Д. К.
Законы Мерфи никто не отменял, и если для уничтожения базы данных нужно нажать в правильной последовательности на двадцать семь клавиш, то клавиши будут нажаты.
В ИТ-подразделениях, которыми я руководил, с определенного момента неукоснительно соблюдалось правило: не проводить никаких критических операций в одиночку.
За компьютером в таких ситуациях обязательно сидят двое: один медленно набирает необходимые команды, а второй хватает его за руку, если, на его взгляд, команда сделает что-то не то. И перед нажатием на клавишу Enter или кликаньем в кнопку «Пуск» обязательно выдерживается пауза, чтобы оба могли прочесть набранный текст.
Но попробуй добиться такой аккуратности от пользователя.
– А-а-а-а! У вас тут все так по-дурацки расположено, что я все время промахиваюсь мышкой!