97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф

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

type Velocity_In_Knots is new Float range 0.0.. 500.00;

type Distance_In_Nautical_Miles is new Float range 0.0.. 3000.00;

Velocity: Velocity_In_Knots;

Distance: Distance_In_Nautical_Miles;

Some_Number: Float;

Some_Number:= Distance + Velocity; — Компилятор отловит здесь ошибочное использование типов.

Разработчики приложений, сбои в которых менее критичны, также могут выиграть от более широкого применения предметно-ориентированной типизации. Предметно-ориентированные типы можно использовать вместо имеющихся в языках программирования и библиотеках базовых типов данных, таких как строки и числа с плавающей запятой. В Java, C++, Python и других современных языках абстрактный тип данных известен как class. Применение таких классов, как Velocity_In_Knots (скорость в узлах) и Distance_In_Nautical_Miles (расстояние в морских милях) значительно повышает качество кода:

• Такой код легче читать, поскольку он выражает понятия предметной области, а не просто описывает строки (String) или действительные числа (Float).

• Такой код легче тестировать, потому что он инкапсулирует поведение, которое легко проверить.

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

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

Мораль: начинайте пробовать предметно-ориентированные типы с целью повышения качества разрабатываемых программ.

Предотвращайте появление ошибок

Жиль Колборн

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

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

Допустим, пользователь должен ввести дату в определенном диапазоне. Чем позволять ему ввести любую дату, не лучше ли предоставить средство вроде списка или календаря, которое покажет только допустимые даты? Это исключит всякую возможность ввода даты за пределами разрешенного диапазона.

Другая распространенная проблема — ошибки форматирования. Например, если пользователь видит текстовое поле для даты и вводит однозначно трактуемую дату «29 июля 2012», неправильно будет забраковать ее только потому, что данные имеют не тот формат, который предпочитаете вы (например, «ММ/ДД/ГГГГ»). Еще хуже отклонить дату «29/07/2012» только из-за лишних пробелов; такие проблемы пользователям сложнее всего осознать, ведь им кажется, что дата имеет верный формат.

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

Другой способ избежать ошибки форматирования — предложить пользователю подсказку, например, с помощью метки в поле ввода, которая показывает нужный формат («ДД/ММ/ГГГГ»). Другой способ подсказать — разделить поле на три части по два, два и четыре символа.

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

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

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

Какова бы ни была причина ошибки, совершенной пользователем, система должна ошибки прощать. Этому можно содействовать, обеспечив возможность многоуровневой отмены (undo) всех выполненных операций — в особенности тех, которые могут удалить или изменить данные пользователя.

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

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

Профессиональный программист

Роберт Мартин (Дядюшка Боб)

Кого можно считать профессиональным программистом?

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

• Профессионал сам отвечает за свою карьеру. Чтение и обучение — ваша ответственность. Быть в курсе последних достижений отрасли и технологий — ваша ответственность. Слишком часто программисты считают, что обучать их — задача работодателя. Извините, это совершенно неверно. Как вы думаете, врачи тоже так считают? А юристы? Нет, они учатся в свое свободное время и на собственные средства. Они проводят значительную часть свободного времени, изучая журналы и решения суда. Они поддерживают свой профессиональный уровень. Так должны поступать и мы. Отношения между вами и работодателем хорошо описаны в вашем контракте. Если коротко, работодатель обещает вам платить, а вы обещаете хорошо работать.

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