Поскольку мы, разработчики программного обеспечения, также неизбежно являемся потребителями программных приложений других лиц, мы, несомненно, под влиянием создания нашего собственного программного обеспечения используемое нами программное обеспечение. Например, на наше мнение о том, что делает эффективный интерфейс для пользователей, влияет наш опыт «на другой стороне» с использованием чужого программного интерфейса. Это особенно верно для веб- и мобильных разработок, поскольку веб-приложения и мобильные приложения стали широко распространенными в нашей жизни.
Мы склонны принимать идиомы и стили, которые нам нравятся, и избегать идиом и стилей, которые нам не нравятся. Степень этого влияния может широко варьироваться в зависимости от типа программного обеспечения, которое мы разрабатываем, от типа программного обеспечения, которое мы используем в качестве потребителя (чем они больше похожи, тем сильнее влияние). Есть моменты, когда влияние может быть более подсознательным, и другие моменты, когда влияние программного обеспечения других может быть очевидным. В этой статье я описываю недавний опыт работы с онлайн-сайтом, который напомнил мне о некоторых важных методах разработки программного обеспечения, которые следует учитывать при создании программного обеспечения (особенно веб-приложений).
Недавно я создавал фотокнигу на популярном веб-сайте, посвященном фотографии. Я начал с загрузки многочисленных фотографий для книги. Веб-приложение сообщило, что все фотографии, кроме одной, были успешно загружены. Он сообщил, что ему не удалось загрузить одну фотографию, и рекомендовал мне проверить подключение к Интернету. После проверки моего интернет-соединения я попытался загрузить одну фотографию еще несколько раз, но безуспешно. Я попытался изменить имя файла и изменить его местоположение, но все равно безуспешно. Я мог загрузить другие фотографии после этих неудач, но все еще не мог загрузить одну конкретную фотографию.
Я решил поработать над фотокнигой с загруженными фотографиями и потратил пару часов на то, чтобы расположить фотографии так, как я хотел. Однако, когда я попытался сохранить свой проект фотокниги, приложение не позволило мне сохранить, потому что оно сообщило, что не может сохранить, пока не завершит загрузку фотографии, которую он не смог загрузить. Я нажал на ссылку, чтобы сохранить проект несколько раз без успеха. Я не мог удалить ссылку на оскорбительную фотографию, и даже опция Сохранить как не позволила мне сохранить, потому что приложение считало, что фотография все еще загружается. В конце концов я сдался и закрыл браузер, зная, что моя двухчасовая работа была потеряна.
Когда я внимательно посмотрел на характеристики проблемной фотографии, я заметил, что ее размер равен 1 МБ (1024 КБ). Я использовал некоторое программное обеспечение для работы с изображениями, чтобы внести в него небольшие изменения, которые повлияли на его размер (сделал его немного больше), и он загрузился без происшествий. Я должен был начать все сначала, но в тот момент я смог (снова) разместить фотографии там, где я хотел, и сохранить проект по своему желанию.
Как потребитель этого программного обеспечения, я усвоил несколько уроков. Одним из уроков является необходимость частого явного сохранения при использовании этого приложения, потому что оно не имеет неявной функции сохранения и потому что сохранение проекта кажется единственным способом выяснить, что программное обеспечение находится в несогласованном состоянии, в котором нет дальнейшая работа над проектом будет сохранена. Я также научился избегать редкого случая попытки загрузить изображение размером точно 1 МБ в это приложение.
Мне напомнили о еще более важных уроках как разработчика программного обеспечения. Во-первых, мне напомнили о важности модульного тестирования, особенно граничных условий. Я предполагаю, что код, используемый этим приложением, выглядел примерно так: псевдокод:
if (imageSize < 1024000)
{
// upload as-is
}
else if (imageSize > 1024000)
{
// compress and then upload
}
В моем умозрительном псевдокоде, показанном выше, случай с изображением, которое точно составляет 1024000 байт, приводит к изображению, которое явно не загружено. Это простая ошибка, особенно если вы спешите, и если проверка кода не выполняется или срочно отправляется. Эффективные модульные тесты идеально подходят для устранения этого типа ошибок, а модульные тесты, которые в этом случае тестируют граничные условия, такие как 1024000, просты в реализации. Зачастую, просто написание модульного теста для проверки этого граничного условия заставит разработчика осознать ошибку своего пути.
Быть раздраженным и разочарованным потребителем этого программного обеспечения также напомнило мне о важности планирования « несчастных путей » в программном обеспечении, которое я разрабатываю. Использование этого программного обеспечения для создания фотокниг в этом случае было бы менее утомительным, если бы был реализован один из нескольких вариантов. Если бы приложение поддерживало функцию автосохранения, которая сообщала о невозможности сохранения, я бы знал, что то, над чем я работаю, нельзя сохранить. Blogger , который я использовал для этого блога, имеет такую функцию, и когда он сообщает мне, что не может сохранить, я знаю, что нужно прекратить добавлять новый контент в свое сообщение, пока он не сможет сохранить, и у меня есть возможность скопировать и вставить то, что у меня есть. набрал в файле на моем локальном жестком диске.
Другим вариантом, который мог бы спасти меня от большого разочарования, была бы функция «Сохранить как», которая позволила мне сохранить свой проект как другой проект. Я понимаю, что пишется программное обеспечение, которое не позволяет мне сохранять данные, когда оно думает, что оно находится в несогласованном состоянии (оно думает, что все еще пытается сохранить), но оно все равно должно сохранять его как другой проект. Я видел это разрешенным в нескольких настольных приложениях, которые считают, что загруженный в данный момент документ поврежден или несовместим, но в любом случае позволяют сохранить этот документ как отдельный документ (без перезаписи предыдущего документа).
Мое разочарование по поводу программного обеспечения для создания онлайн-фотоальбомов напомнило мне о важности учета опыта пользователей при написании программного обеспечения. Мы можем написать все чистое, читаемое и обслуживаемое программное обеспечение, которое мы хотим, но если оно обеспечивает плохой пользовательский опыт, эти усилия будут напрасными. Этот опыт также стал хорошим напоминанием о важности тщательного тестирования, особенно « несчастливых путей » и граничных условий.