Czy nadal warto uczyć się programowania GUI na pulpicie? [Zamknięte]

18

Przez ostatnie kilka lat wszystkie poważne projekty, nad którymi pracowałem, były oparte na sieci Web lub miały nie graficzny interfejs użytkownika (usługi, skrypty wiersza poleceń itp.). W razie potrzeby mogę złożyć aplikację WinForms lub zrobić prosty WPF, ale nigdy tak naprawdę nie zagłębiłem się w niektóre interfejsy API niższego poziomu, takie jak MFC lub QT.

Rozumiem, że zależy to od sytuacji, ale ogólnie czy nadal warto poświęcić trochę czasu, aby dobrze nauczyć się programowania pulpitu, czy też aplikacje przenoszą się do Internetu i urządzeń mobilnych w takim tempie, że ta wiedza jest mniej istotna? Czy spodziewasz się także, że programiści, z którymi współpracujesz, będą posiadać wiedzę na temat GUI na komputer?

learning education gui aubreyrhodes
źródło
5
Tworzenie aplikacji komputerowych jest świetne, ale na miłość Knutha nie zawracaj sobie głowy MFC. Wszystko, czego potrzebujesz do 95% zadań aplikacji komputerowej Windows, to WinForms lub WPF / XAML. Pozostałe 5% miejsc pracy, których nie chcesz mieć.
Adam Crossland,
1
@Adam: +1 za „Pozostałe 5% zleceń, których nie chcesz mieć”. - Tak prawdziwe. :)
Tabele Bobby

Odpowiedzi:

38

Powiedziałbym, że tak. Podczas tworzenia programu istnieje pewien efekt wahadła. Najpierw wszystko działało bezpośrednio na komputerze. Potem, kiedy komputer stał się wystarczająco potężny, aby uruchamiać wiele programów, otrzymały komputery mainframe z głupimi terminalami. Ale głupie terminale są naprawdę do bani pod względem użyteczności, więc gdy tylko komputery stały się wystarczająco mocne, aby umieścić rozsądną ilość sprzętu w systemie wielkości terminala, otrzymaliśmy komputery osobiste i wszystko działało bezpośrednio na komputerze.

Potem wynaleźli World Wide Web, a my wróciliśmy do mainframe (serwer) i głupiego terminala (przeglądarki). Ale głupie terminale wciąż są do bani pod względem użyteczności, a ludzie zaczynają ponownie uczyć się lekcji sprzed 30 lat i znów odchodzimy od tego. Wiele naprawdę gorących prac rozwojowych dotyczy aplikacji komputerowych (lub mobilnych), które działają lokalnie, ale mogą łączyć się z Internetem w określonych celach w celu zwiększenia ich funkcjonalności.

Mason Wheeler
źródło
5
+1 za wskazanie, że trendy te przebiegają cyklicznie. Widziałem jednak przypadek, w którym aplikacja terminalu została przepisana jako aplikacja komputerowa, a użytkownicy mogli pracować bardziej wydajnie z aplikacją terminalową.
Larry Coleman
2
Różnica w stosunku do przeglądarek polega na tym, że w rzeczywistości mogą one uruchamiać kod w systemie lokalnym, a zdolność ta rośnie z każdą generacją przeglądarki. Konsekwencją tego jest to, że różnica w użyteczności między aplikacjami komputerowymi a aplikacjami internetowymi nie jest tak duża. Dla wielu osób (w tym mnie) Gmail jest bardziej użyteczny niż perspektywy. Wahadło za każdym razem kołysze się coraz mniej i zatrzyma się w połowie, a aplikacje będą mieszanką części lokalnych i chmurowych, niezależnie od technologii bazowej.
Joeri Sebrechts
13
+1, nienawidzę, gdy ludzie zaczynają twierdzić, że komputer nie działa, to jest śmieszne.
dr Hannibal Lecter
1
@Joeri: Większość terminali zawsze może zrobić co najmniej kilka bitów i kawałków lokalnie. Przygnębiająca liczba skryptów JavaScript, które widziałem, robi rzeczy, które IBM 3270 (na przykład) mógł zrobić także lokalnie.
Jerry Coffin,
1
@Jeri Sebrichts - gdy Gmail pozwala mi przeciągać i upuszczać wiadomości e-mail w zadaniach lub elementach kalendarza, mogę się z tobą zgodzić, ale do tego czasu jest o wiele mniej funkcji.
JeffO
11

Nawet jeśli nigdy nie planujesz tworzenia pulpitu, sugeruję, abyś miał wystarczająco dużo doświadczenia, abyś miał świadomą opinię na temat tego, kiedy lepiej jest użyć rozwiązania komputerowego na kliencie internetowym.

Rachunek
źródło
+1: Zakładając, że „pulpit nie działa” i aplikacje do wygłupiania są przeciwieństwem twórców czysto desktopowych, którzy mówią „to nigdy nie byłoby dobre jako aplikacja internetowa”. Wybierz, z czym chcesz pracować, ale poznaj drugiego na tyle, aby poznać jego prawdziwe zalety / pułapki.
Steven Evers,
8

Tak, ale nie tak, jak myślisz.

Programowanie GUI nie jest trudniejsze ani nie wymaga specjalistycznych umiejętności poza znajomością interfejsu programowania GUI. Podłączanie przycisków, okien i kontrolek nie jest strasznie trudne i jest dość łatwe w nowoczesnych środowiskach programistycznych w porównaniu do wczesnych dni z takimi rzeczami jak MFC. Programowanie za pomocą GUI jest dość łatwe do nauczenia się, kiedy jest wymagane.

Jednak chociaż podłączanie przycisków i pól tekstowych jest dość łatwe, wiedza o tym, kiedy i gdzie umieścić przyciski, i zaprojektowanie GUI do użycia przez ludzi jest bardzo trudne. Jest to bardzo cenna i ważna umiejętność do posiadania. Jednak zasady projektowania mające zastosowanie do interfejsów natywnych w stosunku do sieci są bardzo podobne.

Dowiedz się, jak projektować dobre interfejsy użytkownika, które są skuteczne i nie dezorientują użytkowników, a zapoznasz się z ich programowaniem za darmo.

whatsisname
źródło
2
Szczególnie w tych dniach User Experience odpowiada za projektowanie oprogramowania. Architektura już nie rządzi.
rwong
5

To naprawdę będzie zależeć od twojej sytuacji. Niedawno pracowałem dla firmy z listy Fortune 500, która miała kilka projektów konwersji aplikacji internetowych z powrotem na aplikacje komputerowe (SmartClient / Click-Once). W ich szczególnych okolicznościach miało to wiele sensu i wyeliminowało szereg problemów związanych z użytecznością, na które cierpiały ich istniejące aplikacje.

Jeśli jesteś pracownikiem zatrudnionym w pełnym wymiarze godzin, a Twoja firma na ogół nie projektuje aplikacji komputerowych, prawdopodobnie nie ma sensu w pełni dostosowywać się do WinForm lub WPF. Jeśli jednak jesteś konsultantem i chcesz zaoferować klientom inną usługę, nie może to zaszkodzić.

Walter
źródło
4

Hmm, oprócz GMail, Stack-Exchange i bankowości domowej mojego banku, używam oprogramowania non-web przez cały dzień. Wraz z pojawieniem się smartfonów i tabletów aplikacje internetowe są dla mnie jeszcze mniej atrakcyjne (korzystam z mojego klienta Facebooka na smartfony). To po stronie użytkownika.

Deweloper: w ciągu ostatnich 10 lat pracowałem prawie wyłącznie nad oprogramowaniem innym niż internetowe (a moja kariera obejmowała wiele bardzo różnych domen, ponieważ pracowałem jako konsultant oprogramowania) i nie widzę żadnego przyszłego trendu internetowego w mojej pracy.

Tak, nadal jest to konieczność uczenia się graficznych środowisk graficznych.

Wizard79
źródło
2
Wow, nie korzystasz z wyszukiwarki internetowej?
JBRWilkinson,
1
@JBRWilkinson: nie, polegam na Gusherze. Poważnie, na pewno korzystam z Google przez cały dzień, ale tak naprawdę to nie zastępuje żadnego narzędzia komputerowego ani aplikacji.
Wizard79
2

Oczywiście „to zależy” - ale myślę, że twoje doświadczenie jest typowe. Rzadko musiałem tworzyć grubego klienta dla dowolnej aplikacji, którą napisałem. Chyba że istnieje konkretny powód, dla którego klient musi działać na pulpicie (problemy z łącznością lub gra 3D itp.) - Uważam, że twórcy i administratorom łatwiej jest utrzymać jedną „instancję” aplikacji. Jeśli mają umiejętność projektowania aplikacji internetowych, ogólnie powinni przejść OK.

Właściwie myślę, że ważniejsze jest, aby gruby programista klienta nauczył się programowania aplikacji internetowych - dziedziczenie bezpaństwowości HTTP sprawia, że ​​trudniej jest zapanować nad rozwojem aplikacji (a przynajmniej trzeba trochę więcej myśleć niż tylko klapsa) kontrolki na panelu).

Nie zapomnij - masz takie technologie, jak Silverlight i Adobe Flex / AIR, które mogą przekraczać granicę między aplikacją komputerową / internetową.

Watson
źródło
+1 za trudniejsze tworzenie stron internetowych. Zaczynałem jako programista i musiałem zająć się tworzeniem stron internetowych w pracy. Jest zdecydowanie bardziej złożony (oczywiście zakłada to porównywalne zadania, co nie jest łatwe).
Tabele Bobby
@Guzica - tak, spotkałem podobne podejście dobrych deweloperów, z którymi współpracowałem, którzy byli zablokowani przy tworzeniu aplikacji komputerowych. Kiedy już spróbują sprawić, że zmiana nie będzie dla nich tak łatwa, jak się początkowo wydawało. Nie wiem, czy jest to jakaś wrodzona złożoność programowania aplikacji internetowych, to po prostu inny sposób programowania, a wiele podstawowych założeń dotyczących tego, co może zrobić system, musi się zmienić (oprócz uczenia się nowych frameworków).
Watson,
Zawsze trudniej jest robić rzeczy z bardziej ograniczonymi narzędziami, co nie czyni go „bardziej złożonym”. To sprawia, że ​​jest to bardziej kłopotliwe.
Sam
0

Według zespołu IE9:

Nie powinno być różnicy między aplikacjami natywnymi a aplikacjami internetowymi. Rozpoczyna się przyspieszenie sprzętowe, szybkie JS i przypinanie strony

Myślę, że to bezpieczny zakład, że technologie te będą się razem zbliżać. Jeśli jesteś programistą Java, nie ma bardzo różnicy między tworzeniem aplikacji komputerowych a aplikacjami internetowymi (za pomocą GWT). Nie jest nierozsądne oczekiwać, że coraz więcej „programistycznych” platform programistycznych będzie mogło atakować silnik przeglądarki. Nie jest również nierozsądne oczekiwać, że coraz więcej aplikacji komputerowych będzie mieć model dystrybucji podobny do sieci (automatyczne aktualizowanie w tle, wykonanie w trybie piaskownicy, takie jak chrome).

Joeri Sebrechts
źródło
3
To jest całkowita BS. Pracuję nad aplikacją do pomiaru opóźnień, która musi być zlokalizowana lokalnie, aby mierzyć i wyświetlać w czasie rzeczywistym opóźnienia w dostarczaniu danych rynkowych. Tego rodzaju rzeczy NIGDY nie zostaną przeniesione do chmury.
Tim
To całkowita BS, ponieważ zauważyłeś absurdalnie niejasną potrzebę aplikacji lokalnej?
Mike M.,
@Tim: masz rację, że niektóre aplikacje zawsze będą lokalne. Prawdą jest również to, że inne aplikacje nigdy nie mogą być lokalne (np. Google Translate). Jednak uruchamianie lokalne nie oznacza, że ​​nie pochodzi z chmury. Chrome działa lokalnie, ale jest aplikacją chmurową (masz niewielką kontrolę nad tym, jaka to „wersja”). Podejmowane są próby powiązania wykonania natywnego kodu z platformami przeglądarki (Google NaCl) oraz próby powiązania języków internetowych z natywnymi aplikacjami (Adobe Air).
Joeri Sebrechts,
1
@Mike M - to nie jest absurdalnie niejasne. W poprzedniej pracy pracowałem nad oprogramowaniem pokładowym marynarki wojennej. Te też prawdopodobnie nie będą w chmurze. Domeny, w których pracuję, prawdopodobnie nie migrują - muszą być lokalne ze względu na opóźnienia i interfejs sprzętowy. Sieć jest ładna, ale niektórzy z nas nadal bez powodu pracują w natywnej aplikacji.
Tim
@ Tim Chodzi mi o to, że znalazłeś scenariusz, który nie wytrzyma. Autor zdaje sobie z tego sprawę, kiedy mówi NAJBARDZIEJ. Wymyśliłeś kontrapunkt i to świetnie. W żadnym wypadku nie udowodniłeś, że cała sprawa nie ma podstaw. Oczywiście będą chwile, kiedy będzie musiał być lokalny z wielu powodów. Ale w zdecydowanej większości wrzuć jakiś kabel światłowodowy, a co 1200 mil można przekroczyć w 10 milisekund? Jako użytkownik nie mam nic przeciwko, aby każda z moich aplikacji komputerowych ładowała formularz o 10 milisekund dłużej.
Mike M.,