Записки автоматизатора. Профессиональная исповедь

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

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

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

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

Финишная кривая

Что такое «программа заработала»: когда начинать внедрение?

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

Однако по сей день однозначного ответа на вопрос, что же такое работающая программа, на мой взгляд, не получено и вряд ли когда-нибудь будет получено. То, что во всех больших программах всегда содержатся ошибки, общеизвестно. Хотя неизвестно, что такое ошибка (этот вопрос долго и нудно приходится обсуждать с разработчиком при каждом составлении договора, а потом не менее долго и не менее нудно доказывать ему, что предъявленные результаты работы системы говорят об ошибке, и в тысячный раз выслушивать бред типа «Это не ошибка, раз вы не можете ее повторить…»).

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

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

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

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

Итак, равнение на Гейтса, и – вперед!