Центр Практичных Программ

Программист программисту враг?

Программист программисту враг?
А.Седельников

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

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

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

Однако когда потенциальный пользователь программы сам является программистом, на этот принцип машут рукой, мол, сам все поймет. Этим страдают практически все современные средства разработки и технологии (ODBC, BDE, ADO, ATL, VCL, COM и т.д.).

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

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

Еще один пример "скрытности" того же FoxPro - сообщение "File is in use" ("Файл используется"), с успехом кочующее из одной версии в другую. Мало того, что понятие "используется" не совсем понятно и однозначно, так еще и имя файла тщательно скрывается, не дай бог, программист поймет, в чем же дело!

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

Вот еще один пример из личного опыта - сообщение операционной системы на попытку регистрации ActiveX компонента Formula1. К этому моменту сам компонент был уже переписан в системный каталог, однако программа регистрации RegSvr32 упорно не хотела его регистрировать.

Как видите, сообщение не дает никакой информации и даже намеков на то, в чем же собственно заключается проблема. Поэтому ее решение заняло у меня целый день. Ключом к разгадке оказалась одна единственная строчка, найденная в глубине файла справки этого компонента, говорящая о том, что для его работы необходимо наличие еще двух файлов - mfcans32.dll и oc30.dll. Насколько бы изменилась ситуация, если бы исходное сообщение содержало строчку типа "Для регистрации компонента требуются файлы mfcans32.dll и oc30.dll"!

Ну а это "сообщение" Visual Basic'а уже стало знаменитым

:

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

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

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

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

Вернуться к списку статей
Предложения, замечания, дополненияtoader@mail.ru