Как сделать приложение, которое будет нравиться пользователям

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

Предисловие

К сожалению, как и везде, по-настоящему хорошие и удобные программы можно встретить довольно редко, что лично меня, как программиста, обычно очень расстраивает. Поэтому я решил написать эту статью в надежде, что хотя бы среди читателей Хабрахабра, которые занимаются разработкой программного обеспечения, качество их приложений вырастет. Я не рассматриваю создание софта с точки зрения получения коммерческой выгоды, я в этом не очень силён :). Поэтому, возможно, некоторые озвученные здесь советы могут оказаться вредными в применении к коммерческому софту. Тем не менее, если вы разрабатываете Open Source или бесплатный софт, то озвученные советы могут вам помочь в улучшении качества своих продуктов и улучшения собственной квалификации как программиста.

Характеристики «хорошей» программы:

1. Приложение решает какие-то вполне конкретные задачи и проблемы пользователя, причём позволяет достичь большей эффективности, чем решение тех же проблем и задач без этой программы
2. Простота установки — у пользователя должно быть минимум препятствий в установке вашего приложения, программа не должна зависеть ни от каких сторонних библиотек / утилит, которые не идут в комплекте
3. Простой, отзывчивый и быстро работающий интерфейс — пользователи очень не любят, когда программы «зависают», еле-еле прогружают новые окна и так далее. Они имеют на это право: сегодняшние компьютеры обладают поистине впечатляющими вычислительными ресурсами и позволяют, при правильном проектировании приложения, полностью исключить любые «тормоза» графического интерфейса программы даже при использовании сложных визуальных эффектов
4. Корректность работы — программа должна выполнять точно те действия, которые от них ожидает пользователь, не больше и не меньше! Если какую-то операцию не удаётся завершить, то программа должна постараться человеческим языком объяснить причину возникновения проблемы и способы её устранения, без необходимости лазить в документацию
5. Высокая скорость работы программы — это относится ко всему: она должна загружаться быстро, быстро выполнять свои обязанности и не должно сопротивляться своему закрытию (как делают некоторые приложения вроде uTorrent, хотя как раз uTorrent делает это по достаточно веским причинам)

Примеры

Примеров «хороших» программ можно привести массу. Я много лет назад был сильно впечатлён программой «Иероглиф», которая, помимо безупречной работы, могла, к примеру, переключать язык своего интерфейса «на лету» (не уверен, что она запустится под Windows Vista / 7, но под более старыми Windows она работает). Такая, казалось бы, мелочь (для непосвященного :)), избавляет пользователя от необходимости совершать лишние действия, пусть и путём усложения самой программы. Для гарантии выполнения поставленной задачи, редактирования русского текста, Иероглиф даже имел возможность использовать собственный механизм рендеринга шрифтов, чтобы полностью исключить проблемы с «кракозябрами», которые до сих пор иногда преследуют пользователей Windows.

Из программ под Mac OS X, мне очень нравится TextMate: в противоположность современным очень тяжелым IDE и текстовым редакторам вроде Komodo, Eclipse, NetBeans и др., TextMate обладает нужной функциональностью и легкостью расширения, при этом занимает немного места (10 Мб в дистрибутиве), очень быстро загружается и не требует много системных ресурсов.

Из чисто Linux приложений, наверное, можно назвать хорошей оконную среду Enlightenment — она тоже исповедует минимализм и простоту работы.

Подходы к разработке

Совершенно очевидно, что написать приложение, которое работает плохо, легко. Если вы — программист (а иначе зачем вы читаете эту статью :)?), то прекрасно об этом знаете, поскольку сами писали много таких программ, и пишете каждый день. И я тоже их пишу, потому что деваться некуда, особенно если программы пишутся «для себя», не хочется на них тратить времени больше, чем требуется для получения результата. Тем не менее, если вы пишете программу не для себя, а для других пользователей, то как подходы к разработке, так и требования к качеству тоже должны быть другими:

1. В самом начале разработки, если перед вами стоит выбор, к примеру, использовать или нет какую-либо «модную» библиотеку / фреймворк / парадигму, постарайтесь понять, насколько она вам нужна и насколько полно вы собираетесь использовать её возможности, а также постарайтесь оценить её влияние на размер приложения, скорость его загрузки и удобство установки. Практика показывает, что для небольших программ использование крупных фреймворков или каких-либо сугубо закрытых технологий не оправдывает себя в применении к удобству для пользователя. (в качестве примера могу привести не так давно публиковавшуюся на Хабре программу CodeCraft, которая, при весе в пару мегабайт (из которых бóльшую часть занимает фоновая картинка :)) требует под самой популярной ОС Windows XP самостоятельного скачивания и установки фреймворков общим весом более 100 Мб, а для написания своих роботов — опять же самостоятельной установки VisualStudio и как минимум Microsoft Word / OpenOffice для прочтения инструкции))
2. Если ваше приложение содержит графический интерфейс, то постарайтесь хотя бы мельком познакомиться с GUI-гайдлайнами для соответствующей ОС или DE. Если вы разрабатываете web-приложение, то постарайтесь не заменять стандартные элементы управления на свои собственные, не используйте нестандартные шрифты, а также старайтесь не злоупотреблять возможностями, которые доступны не во всех браузерах. Следование устоявшимся стандартам сделает общение пользователей с программами более легким и «интуитивно понятным»
3. Чтобы обеспечить отзывчивость интерфейса, постарайтесь не совершать ресурсоёмких операций в обработчиках событий, особенно кликов мышью и изменений размеров окна. В обработчиках событий должен быть только минимальный код, который будет запускать те же самые операции в фоне, чтобы в главной нити (main thread) приложения, которое осуществляет обработку всех событий, не возникало больших очередей, иначе пользователю будет казаться, что программа «зависла». Очень хорошим примером игнорирования этой рекомендации является Проводник в старых версиях Windows при работе с сетью: он часто использовал блокирующие вызовы в нити обработки событий, что приводило к хорошо известным вам последствиям :). Если же вы пишете веб-приложение, то постарайтесь вообще не выполнять ресурсоёмких операций на клиенте, по крайней мере продолжительное время, поскольку в Javascript до сих пор нет единого стандарта для создания многопоточности, и весь код исполняется в однопоточном режиме, что также может вызывать существенную задержку в обработке событий
4. Не забывайте про ту цель, которая поставлена при написании приложения — программа должна выполнять именно то, что задумано изначально, и никак иначе! Помимо этого, имейте ввиду, что программа не должна давать некорректные результаты при корректных начальных данных. Я имею ввиду, что в случае, если для решения какой-либо подзадачи есть несколько способов, то выбирайте тот, который будет давать правильный ответ при любых исходных данных, даже если для этого придется пожертвовать производительностью (согласитесь, если не требовать от программы корректности её работы, то можно и функцию вычисления корня написать как double sqrt(double x) { return 0.0; } — это будет самая быстрая функция для вычисления корня числа, но толку от неё никакого :))
5. Несмотря на то, что хорошая программа должна быстро работать, это не означает, что нужно оптимизировать программу с самого начала, до её написания или прямо в процессе — как говорил Дональд Кнут, «Premature optimization is the root of all evil» ( en.wikipedia.org/wiki/Program_optimization#Quotes ). Тем не менее, не забывайте, что ваше приложение скорее всего вы тестируете на более мощном железе, чем у того человека, который будет вашу программу использовать, и соответственно при малейших «тормозах» на вашей машине постарайтесь выяснить, в чём дело, и ускорить соответствующий кусок. Также бывает полезно пробовать «скармливать» своему приложению объемы данных, которые существенно превышают те объемы, которые в среднем ожидаются от пользователя — чтобы убедиться в том, что приложение нигде не «зависает» и не «тормозит» даже при превышении ожидаемого объема данных на порядки (пользователь, скорее всего, иногда захочет использовать своё железо «на полную катушку», и ваше приложение должно давать возможность это сделать, если оно занимается какого-либо рода обработкой данных)
6. Если вы пишете web-приложение, то постарайтесь сделать так, чтобы даже пользователи с узким или нестабильным каналом могли им пользоваться без особых неудобств, и им не приходилось ждать по 5 минут для того, чтобы просто посмотреть список документов и их содержимое (да, это камень в огород Google Docs!). Мы все с вами когда-то пользовались dial-up для выхода в интернет, а лично у меня не так давно был канал 64 кбит/сек, причём я живу я совсем не в глубинке
7. Ну и наконец, не забывайте о тщательном тестировании тех релизов (да и промежуточных версий тоже) своих продуктов в самых различных ситуациях. Хуже программы, которая «тормозит» только программа, которая при этом ещё и нестабильно работает!

Пожалуй, на первый раз всё, хотя я затронул лишь малую часть тех проблем, которые обычно возникают при разработке программных продуктов, я всё же надеюсь, что вы всё же нашли для себя нечто полезное в этой статье, и что мы скоро увидим больше качественных программ и веб-сервисов, причём на русском языке, написанных нашими, отечественными программистами :)!

Литература

Не могу не упомянуть несколько книг, которые я считаю либо обязательными для прочтения, либо, по крайней мере, очень полезными и помогающими лучше научиться писать программы

1. Брайн Керниган, Деннис Ритчи «ANSI C» — руководство по языку C, очень толковое, помогает не только изучить язык C, но и учит программированию (на любом языке)
2. Брайан Керниган, Роб Пайк «Практика программирования» (The Practice of Programming) — книга, которой всего 10 лет (по сравнению с предыдущей книгой, первая версия которой вышла в 1978 году), описывает не только программирование на языке C, но и содержит примеры на C++, AWK, Perl, Java, и затрагивает практически все области программирования в сугубо практическом аспекте, в применении к решению реальных задач
3. Marc J. Rochkind «Advanced UNIX programming» (в русской версии переведена как просто «Программирование под UNIX») — отличнейшая книга, которая очень подробно рассказывает о программировании под UNIX, а также содержит огромное количество общих рекомендаций по написанию приложений, которые, как мне кажется, представляют не меньшую ценность, чем описание системных вызовов различных версий UNIX и UNIX-like систем и связанных с ними подводных камней