Что опасно доверять программисту?

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

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

Итак, программисты — это гаранты отлаженной работы целых заводов, боги Интернета! Так что же им нельзя доверить? Да и возможно ли это? Возьмем пример.

— Валерочка! Быстренько откорректируй программу, чтоб при анализе очередного работника проверялась дата поступления. После обеда нужен результат. — Антон Павлович, только завтра к концу смены. — Брось все! Занимайся только датами! Завтра к обеду крайний срок! — Понял…

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

Вот я и навесил на уши читателю пару килограмм лапши. Почему лапши? Ситуация, надо сказать, недопустимая. По многим причинам. Разложим их по полочкам.

1. Отладочная печать — это бич программистов. Он не щадит никого, даже асов, скорее, особенно асов. Оставить ее в программе — легко. Главное — основная задача выполнена, новые команды программы проверены и протестированы, причем с помощью этой самой отладочной печати, а убрать ее просто забыли.

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

3. Программисту нельзя касаться программы перед отгулом, отпуском или командировкой.

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

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

Я внес описанную ситуацию в разряд недопустимых. К сожалению, они имеют место, и всегда случаются как нельзя некстати. Главный вывод — следующий: нельзя допускать программиста до эксплуатации собственных разработок, хотя авторы к этому очень рвутся. Я — не исключение. Помню, как я менял работающие варианты программ, несмотря на официальную политику начальника. Доступ? А кто его проконтролирует?

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

Рассмотрим пример.

В связи с увольнением сотрудника мне было поручено сопровождать его тему — расчет зарплаты. Программа была написана давно, но не передавалась расчетчикам. Слишком сложная технология. Доработка из в года в год откладывалась и в конце концов потеряла актуальность. На подходе была новая система управления предприятием, в которой зарплата также присутствовала. Я тратил полдня (чаще полночи) на запуск и расчет модулей, созданных еще на старой технике. Вначале было интересно. Я ухватил суть и за четыре месяца не сделал ни одной ошибки. В голове созрел план совершенствования отдельных кусков для ускорения работы. Но реализовать его я не успел, благодаря текучке. Это оказалось положительным моментом. То, что я задумал, облегчило бы работу чисто внешне. А на глубинном уровне могли накопиться погрешности. Ряд команд обращался непосредственно к ядру старых систем, а новые их интерпретировали не так.

На пятый месяц я почувствовал себя настолько уверенно, что расслабился. Машинально запуская программы, я думал о новшествах. В результате одна небольшая операция была опущена, и пятьдесят человек неправильно рассчитались. К счастью, пятьдесят — не так много, и мы спешно выкрутились, написав дополнительную ветку. Зарплату институт получил вовремя. Какой вывод я хочу сделать? Программисту, особенно продвинутому, опасно поручать операторскую работу. У него психология мышления совершенно другая. Решить сложную проблему, спастись от аварии — пока мозги заняты, все идет нормально, и даже с блеском. Но скучное выполнение серийных заданий — не для него. Тут нужно методичное следование технологии, не больше.

Еще одна ситуация. Программист сдает работу. Все проверил на отладочной базе данных и подключился к реальной. Программа работает. Начальник доволен, пользователи не звонят. Работа движется. Программисту выдают следующее задание. Необходимое время на проработку, консультации с заказчиками, все ясно! Можно начинать. С утра с телефоном начальника происходит что-то непонятное. Звонят со всех отделов и жалуются, что программа сошла с ума, выдает полный абсурд. Начальник собирает срочное совещание. На нем выясняется, что программист забыл отключиться от реальной базы данных и производил отладку прямо на ней. Естественно, многие данные были запорчены.

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

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

Интересно, есть ли хоть где-то такая «идеальная» система работы? Боюсь, что чаще программист, администратор и тестировщик объединяются в одном лице. Однако разъединить это лицо никогда не поздно.

Есть такое выражение: «Не боги горшки обжигают». Если программисты — и есть боги, то их дело разработать технологию обжига, а обжечь могут и другие.

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