Стоит ли изучать разработку графического интерфейса для настольных компьютеров? [закрыто]

За последние пару лет все серьезные проекты, над которыми я работал, были либо веб-основаны, либо имели не графический интерфейс пользователя (службы, сценарии командной строки и т. Д.). Я могу собрать приложение WinForms или сделать несколько простых WPF, когда это необходимо, но я никогда не углублялся в некоторые API более низкого уровня, такие как MFC или QT.

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

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

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

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

Да, но не так, как вы думаете.

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

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

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

Это действительно будет зависеть от вашей ситуации. Недавно я работал в компании Fortune 500, у которой было несколько проектов по преобразованию веб-приложений обратно в настольные приложения (SmartClient / Click-Once). В их конкретных обстоятельствах это имело большой смысл и устранило некоторые проблемы с юзабилити, от которых пострадали их существующие приложения.

Если вы работаете полный рабочий день, и ваша компания обычно не разрабатывает настольные приложения, то, вероятно, не имеет никакого смысла полностью использовать Winforms или WPF. Однако, если вы являетесь консультантом и хотите предложить своим клиентам другую услугу, это не может повредить.

Хм, кроме GMail, Stack-Exchange и домашнего банкинга моего банка, я использую весь день не веб-программное обеспечение. Теперь, с появлением смартфонов и планшетов, веб-приложение стало для меня еще менее привлекательным (я использую свой смартфон на Facebook для клиента). Это на стороне пользователя.

Сторона разработчика: в последние 10 лет я работал почти только над не-сетевым программным обеспечением (и моя карьера охватила много очень разных областей, так как я работал консультантом по программному обеспечению), и я не вижу каких-либо будущих веб-тенденций в своей работе.

Так что да, это все еще необходимо для изучения настольных графических сред.

Конечно "это зависит" - но я думаю, что ваш опыт типичен. Мне редко приходилось создавать толстый клиент для любого приложения, которое я написал. Если нет конкретной причины, по которой клиент должен работать на рабочем столе (проблемы с подключением, 3D-игры и т. Д.), Я считаю, что разработчику и администраторам проще поддерживать один «экземпляр» приложения. Если у них есть навыки, необходимые для разработки веб-приложения, они должны нормально переходить в область настольных приложений.

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

Не забывайте - у вас есть такие технологии, как Silverlight и Adobe Flex / AIR, которые могут занимать границу между настольным компьютером и веб-приложением.

По словам команды IE9:

Не должно быть разрыва между нативными и веб-приложениями. HW ускорение, быстрый JS и закрепление сайта запускают его

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