Статьи

Уроки разработки программного обеспечения, извлеченные из опыта потребителей

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

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

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

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

Когда я внимательно посмотрел на характеристики проблемной фотографии, я заметил, что ее размер равен 1 МБ (1024 КБ). Я использовал некоторое программное обеспечение для работы с изображениями, чтобы внести в него небольшие изменения, которые повлияли на его размер (сделал его немного больше), и он загрузился без происшествий. Я должен был начать все сначала, но в тот момент я смог (снова) разместить фотографии там, где я хотел, и сохранить проект по своему желанию.

Как потребитель этого программного обеспечения, я усвоил несколько уроков. Одним из уроков является необходимость частого явного сохранения при использовании этого приложения, потому что оно не имеет неявной функции сохранения и потому что сохранение проекта кажется единственным способом выяснить, что программное обеспечение находится в несогласованном состоянии, в котором нет дальнейшая работа над проектом будет сохранена. Я также научился избегать редкого случая попытки загрузить изображение размером точно 1 МБ в это приложение.

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

1
2
3
4
5
6
7
8
if (imageSize < 1024000)
{
   // upload as-is
}
else if (imageSize > 1024000)
{
   // compress and then upload
}

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

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

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

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