क्या GUI प्रोग्रामर दूसरों पर अनुचित लाभ उठाते हैं?


23

प्रबंधकों और ग्राहकों के लिए यह सराहना करना आसान है कि वे क्या देख सकते हैं।

मैंने कई GUI डेवलपर्स देखे हैं, जो डिजाइन सिद्धांतों या अन्य प्रोग्रामिंग मुहावरों के न्यूनतम ज्ञान के साथ औसत प्रोग्रामर हैं। हालांकि, इन कमियों को अक्सर किसी का ध्यान नहीं जाता है, विशेष रूप से प्रबंधन और ग्राहकों द्वारा, यदि प्रोग्रामर एक प्रभावशाली दिखने वाला यूजर इंटरफेस बना सकता है। इतना है कि कई जीयूआई डेवलपर्स मुझे पता है कि बुरा, अचूक कोड लिखने की कीमत पर जीयूआई को सुशोभित करने में घंटों खर्च करते हैं।

दूसरी ओर, मध्य स्तरीय प्रोग्रामर जो एपीआई या व्यावसायिक कार्यक्षमता या डेटाबेस कोड (एसक्यूएल आदि) विकसित करते हैं, वे नुकसान में हैं क्योंकि प्रदर्शन के लिए कुछ भी ठोस नहीं है। शायद एक कोड समीक्षक या एक वास्तुकार कोड की लालित्य, अच्छी डिजाइन, स्केलेबिलिटी आदि की सराहना कर सकता है लेकिन इसका मतलब बाहरी दुनिया के लिए कुछ भी नहीं है। आपका कोड बिना ब्रेक के वर्षों तक चल सकता है, बनाए रखने में बहुत आसान हो सकता है और अच्छा प्रदर्शन हो सकता है, फिर भी यह 'वाह' को कभी नहीं हटाता है जो कि एक चालाक दिखने वाला जीयूआई करता है।

मेरी राय में, इस के लिए एक कोरोलरी है (और मैं इसके लिए भारी रूप से निराश होने जा रहा हूं, मुझे पता है) कि जीयूआई प्रोग्रामर के लिए अच्छा साफ कोड लिखने के लिए प्रेरणा कम है।

संपादित करें : मुझे यहाँ स्पष्ट करना चाहिए कि GUI प्रोग्रामर द्वारा, मेरा मतलब पूर्ण-विकसित वेब / GUI डिज़ाइनर नहीं है, बल्कि फ्रंट-एंड प्रोग्रामर जैसे, जावा-स्विंग प्रोग्रामर।

क्या बाकी समुदाय सहमत हैं?


6
फोंट, लेबल, रंग और सब कुछ घूमने के लिए 'मूर्खतापूर्ण' उपयोगकर्ता अनुरोध के माध्यम से किसे भुगतना पड़ता है? आप अच्छे को बुरे के साथ लेते हैं।
जेएफओ

@ जेफ ओ: बहुत सच। किसी उपयोगकर्ता ने कभी भी मेरी पसंद की आलोचना नहीं की है कि डेटा संरचना के लिए कितनी मेमोरी आवंटित की जाए या किसी डेटाबेस टेबल के कौन से कॉलम को इंडेक्स किया जाए।
dan04

2
लेआउट के साथ काम करना (चाहे स्विंग, जीडब्ल्यूटी, एचटीएमएल, सीएसएस।) ऐसी यातना है कि इसके साथ सौदा नहीं करना एक फायदा है ...
उरी

@ dan04: वरिष्ठ वैज्ञानिक उपयोगकर्ताओं के साथ काम करने की कोशिश करें। वे बदसूरत यूआई का उपयोग करने के लिए खुश हैं और डेटाबेस संरचनाओं पर लड़ते हुए उम्र बिताएंगे (आमतौर पर कुछ पुरानी अनिर्णायक क्रॉफ्ट रखने की कोशिश में क्योंकि उनकी पुरानी स्क्रिप्ट इसका उपयोग करती हैं)। जीआर…
डोनल फेलो

एक बैसिस्ट और बाकी बैंड के बीच अंतर की तरह बिट। वे पृष्ठभूमि में बहुत सारे आयात कार्य करते हैं लेकिन अन्य बासवादियों को छोड़कर कोई भी नोटिस नहीं करता है।
गॉर्डन

जवाबों:


21

मुझे लगता है कि मैं आपकी बात देख रहा हूं, लेकिन मुझे संदेह है कि विचार करने के लिए एक विपरीत मुद्दा भी है।

अनिवार्य रूप से, मेरा मानना ​​है कि आप सुझाव दे रहे हैं, क्योंकि यूआई अंतिम उपयोगकर्ताओं के 'फेस' में 'एलिमेंट' का तत्व है, यूआई डेवलपर्स ऐप की गहरी परतों में काम करने वाले टीम के सदस्यों की तुलना में अधिक दृश्यता का आनंद लेते हैं।

निश्चित रूप से मैं सहमत हूं कि उच्च दृश्यता हो सकती है। उदाहरण के लिए, UI तत्वों पर काम करने वाले डेवलपर्स अंत उपयोगकर्ताओं के साथ अधिक बार बातचीत कर सकते हैं (यकीनन, अच्छे कारणों के लिए, क्योंकि वे मानव / कंप्यूटर इंटरैक्शन पहलू पर ध्यान केंद्रित करते हैं)।

फिर भी, मुझे लगता है कि समस्या होने पर भी उच्च दृश्यता खेल में आती है। उदाहरण के लिए, अंत उपयोगकर्ताओं को 'GUI मुद्दे' के रूप में समस्याओं की रिपोर्ट करने की बहुत संभावना है, भले ही वे न हों।

यह सभी धारणा के लिए उबाल हो सकता है, और एक परिपक्व संगठन को विभिन्न टीम के सदस्यों के मूल्यों, गुणों और कमजोरियों को स्वतंत्र रूप से पहचानने में सक्षम होना चाहिए कि वे ऐप की किस परत से काम करते हैं। एक परिपक्व संगठन 'यूआई डेवलपर' और 'बिजनेस लेयर डेवलपर' जैसे भेदों से भी आगे निकल सकता है, यह पहचान कर कि वे सभी टीम सदस्य वैसे भी हैं, शायद अलग-अलग विशेषज्ञता के साथ, लेकिन हमेशा विशेषज्ञता के उन क्षेत्रों में एक-दूसरे को शिक्षित करने की कोशिश कर रहे हैं।


1
और ऐसा नहीं है कि ज्यादातर कंपनियां यह देखने के लिए एक उपयोगकर्ता सर्वेक्षण लेती हैं कि सबसे अच्छा प्रोग्रामर कौन है।
जेएफओ

1
+1। मैं GUI पर काम करता हूं, और जब भी कोई 'समस्या' होती है, तो यह मेरे इनबॉक्स में आ जाती है। इसके बाद मुझ पर यह साबित करने के लिए कि समस्या का स्रोत नीचे से आता है। जीयूआई प्रोग्रामर्स को उन खूबसूरत एपीआई की 'शुद्धता' को भी ध्यान में रखना होगा, जिसमें उपयोगकर्ता की आवश्यकताओं की अराजकता होगी।
बेन्जोल

10

ऐसे व्यक्ति के लिए जो प्रोग्रामर के साथ कोई व्यवहार नहीं करता है, मैं विश्वास के साथ कह सकता हूं कि वे इस तरह के सामान पर विश्वास करेंगे। वे पृष्ठभूमि में जाने वाले काम की मात्रा को नहीं जानते हैं, वे सभी देखते हैं बटन / टेक्स्टबॉक्स / मेनू / [जीयूआई तत्व डालें] का एक गुच्छा है और बटन शुरू होने पर इसे पूरा करने के लिए गति। इसलिए शुरू में, GUI लोगों को अधिक पसंद किया जाता है।

यदि व्यक्ति प्रोग्रामर के साथ व्यवहार करता है , तो यह थोड़ा अलग है। जैसा कि आपने कहा था कि यदि वे इसे मापनीय, आसान बनाए रखना चाहते हैं, तो एक एल्गोरिथ्म को फिर से लिखना, जिससे कि यह अधिक समझ में आता है, या किसी अन्य रखरखाव प्रकार का कार्य हो सकता है। इस तरह का व्यक्ति सभी प्रोग्रामर को समान रूप से देखता होगा।

बीच में यह निर्भर करता है कि आपका क्या करना है। गति तब यहां महत्वपूर्ण कारक बन जाती है। यदि आप रिकॉर्डिंग से पहले और बाद में दिखा सकते हैं कि किसी फॉर्म को संसाधित होने और संग्रहीत करने में कितना समय लगता है और इसमें सुधार होता है, तो आप बराबर हैं। यदि आप 100 ग्राहकों से लोड के तहत ऐप दिखा सकते हैं और उन्हें सर्वर को पिघलाने के लिए दिखा सकते हैं, और फिर उन्हें अपना संस्करण दिखा सकते हैं जहां सब कुछ ठीक है, आपके बराबर। आदि।


संक्षेप में, यह व्यक्ति पर निर्भर करता है और आपका क्या कर रहा है।


8
किसी ऐसे व्यक्ति के रूप में, जिसने पिछले 5 साल बिताए हैं या इसलिए इन्फ्रास्ट्रक्चर सामान (एसआईपी स्टैक) पर काम कर रहा है, +1 - ज्यादातर लोग नहीं जानते कि आप क्या कर रहे हैं, और विशेष रूप से दिखाई देने वाली कोई चीज नहीं है, जो काम नहीं कर रही है। आप अपनी पाइपलाइन के बारे में कितना सोचते हैं ... जब तक यह टूट नहीं जाता?
फ्रैंक शियरर

6

मेरी कंपनी में "यूआई विशेषज्ञ" के रूप में (सभी यूआई विकास के प्रभारी, न केवल डिजाइन), मुझे लगता है कि आप कहानी के कुछ हिस्से को याद कर रहे होंगे। जबकि मैं UI का प्रभारी व्यक्ति हूं, मैं बैक-एंड पर भी काम करता हूं, डेटाबेस पर, आदि। मैं यह सब करता हूं (हम एक छोटी टीम हैं)। [C # और ASP.Net WebForms विकास]

सबसे पहले, हाँ गैर-तकनीकी लोगों के लिए GUI डेवलपर के काम की सराहना करना बहुत आसान है क्योंकि लोगों के सामने यही है। गैर-तकनीकी लोगों के लिए, जीयूआई अनुप्रयोग है । दोष यह है कि कुछ गलत होने पर GUI को भी दोषी ठहराया जाता है।

दूसरा, फ्रंट-एंड को विकसित करना मेरे लिए बैक-एंड की तुलना में कहीं अधिक चुनौतीपूर्ण रहा है (अस्पष्ट / जटिल एल्गोरिथम एक तरफ)। वहाँ बहुत अधिक के खिलाफ की रक्षा करने के लिए है, यह स्टेटलेस है (हमारे ऐप वेब पर हैं), ब्राउज़र लगातार व्यवहार नहीं करते हैं (जावास्क्रिप्ट लाइब्रेरी एक गॉडसेंड थे), आदि। मैं उम्मीद कर रहा हूं कि इस जटिलता के अधिकांश के कारण मेरे पास ढांचा है (ASP.Net WebForms) के साथ काम करना और भविष्य में सभी मुश्किल चीजें एक मुद्दा नहीं होंगी।

कुल मिलाकर, मुझे बैक-एंड मुद्दों की तुलना में UI समस्याओं को हल करने में बहुत अधिक कठिनाई हुई है।


5

मुझे दो कारणों से GUI के विकास से नफरत है,

  1. मैं ग्राफिक रूप से कलात्मक से अधिक तार्किक हूं और मेरा यूआई हमेशा परिणामस्वरूप होता है।
  2. जैसा कि यूआई तर्क पर आधारित नहीं है, यूनिट टेस्ट किसी भी अर्थ के साथ लिखना असंभव है

दिन के अंत में, हालांकि, मुझे लगता है कि मेरे कोड को अंत उपयोगकर्ता द्वारा बेहतर सराहना की जाएगी (जैसा कि विरोध किया गया है, शायद एक परियोजना प्रायोजक के लिए), उस औसत दर्जे के डेवलपर की तुलना में, जो यूआई में एक विशेषज्ञ है, क्योंकि यह आम तौर पर काम करता है ।


4

To (हो सकता है) @ TheLQ के उत्तर पर थोड़ा विस्तार करें, मुझे लगता है कि यह "दर्शक" पर भी निर्भर करता है।

मुझे कुछ ऊपरी स्तर के प्रबंधकों / पर्यवेक्षकों के साथ कुछ अनुभव हुआ है जिनके पास प्रोग्रामिंग पृष्ठभूमि नहीं है। कुछ लोग मानते हैं कि वे कार्यक्रम नहीं करते हैं, लेकिन समझते हैं कि क्रोम और हबकैप इंजन और चेसिस के समान ही महत्वपूर्ण हैं।

और मेरे पास कुछ ऊपरी स्तर के प्रबंधकों / पर्यवेक्षकों के साथ अनुभव है जो UI सिज़ल के अलावा किसी भी मैट्रिक्स के बारे में परवाह नहीं करते हैं। यह भी बताते हुए कि अधिक यूआई उन्मुख डेवलपर्स जहां महत्वपूर्ण हैं।

IMHO, हम सभी जानते हैं कि आप एक turd और एक तेज, विश्वसनीय अभी तक बदसूरत एप्लिकेशन पॉलिश नहीं कर सकते एक app है कि दोनों अच्छा लग रहा है और कार्यों से भी बदतर होगा। यह सब देखने वाले की नज़र में है और एक हद तक, आपके पास वह शक्ति है (आप चाहे जो भी करें) आपको अपनी इच्छानुसार प्रकाश में दिखना है, जो आपके लिए समान गुणों की सराहना करते हैं।

संपादित करें: मैं जोड़ सकता हूं, कोई है जो निचले स्तर की वस्तुओं पर काम करने में अधिक सहज महसूस करता है, जब मैं यूआई टीम की तरह समान रूप से कड़ी मेहनत करता हूं तो मैं परेशान हो गया हूं और यह वह चमक है जो डेमो में प्रशंसित है और इस तथ्य से नहीं कि सिस्टम " बस काम किया ”। लेकिन जैसा मैंने कहा, मुझे पता है कि मेरे पर्यवेक्षक को पता है कि सभी क्षेत्रों में काम की जरूरत है।


3

मुझे लगता है कि वहाँ एक सामान्य अनुमान है कि यूआई डेवलपर्स "जूनियर" डेवलपर्स हैं। मैं केवल एक मामले के बारे में सोच सकता हूं, जहां मैं एक यूआई आदमी को वरिष्ठ माना जाता था।

उस ने कहा, मुझे लगता है कि यूआई हमारे ऐप्स के किसी भी हिस्से की तुलना में बहुत कठिन है। और मैं UX डिजाइन के बारे में बात नहीं कर रहा हूं, मैं कोडिंग के बारे में बात कर रहा हूं। सैकड़ों, या संभावित परिदृश्यों के लिए हमें कितने अन्य क्षेत्रों में कोड लगाना होगा जहां हमें दर्जनों के लिए खाते हैं? बस एक स्क्रीन का आकार बदलना कभी-कभी एक शाही दर्द बन सकता है जब आपको यह पता लगाने की आवश्यकता होती है कि कुछ दर्जन तत्वों के साथ क्या होने की आवश्यकता है। यह मुख्य रूप से सामने आता है जब आपके पास दिशानिर्देश होते हैं जो कहते हैं कि "हमें 800x600 का समर्थन करने की आवश्यकता है" और फिर यूएक्स डिजाइनर जो एचडी प्रस्तावों के अलावा कभी भी उपयोग नहीं करते हैं।

इसलिए, अगर उन्हें अधिक जोखिम के कारण अधिक अच्छाई मिलती है, तो वे शायद इसके लायक हैं। आमतौर पर, वे अच्छे प्राप्त अंत की तुलना में अधिक बार गलत प्राप्त करने वाले अंत पर होते हैं।


3

अक्सर लगता है कि GUI प्रोग्रामर प्रोग्रामर श्रृंखला के निचले भाग पर है। वी.एस. में एक बटन को ड्रैग और ड्रॉप करना कितना कठिन हो सकता है? क्या, यह कार्यक्रम करने के लिए आपको एक सप्ताह लगेगा? यह कुछ सलाखों को खींच रहा है। इसलिए मुझे यह देखकर आश्चर्य नहीं हुआ कि जीयूआई प्रोग्रामर, बटन ड्रैगर्स के रूप में वे हैं, भयानक कोड भी लिखना चाहिए।

जीयूआई प्रोग्रामिंग में कुछ अनूठी चुनौतियां हैं। डेटा लोड होने के दौरान GUI को सक्रिय रखने के लिए मल्टीथ्रेडिंग। इससे थ्रेड सुरक्षित और उचित कोड हो जाता है। प्रदर्शन बहुत महत्वपूर्ण है। कोई भी दो मिनट इंतजार करना पसंद करता है जब तक कि उन्हें फिर से आवेदन पर नियंत्रण नहीं मिलता। पुन: प्रयोज्य भी एक बड़ा मुद्दा बन जाता है। यदि आपको दस समान स्क्रीन लिखना है तो आप बेहतर तरीके से अपने कोड को बेहतर बनाएंगे। इससे बेहतर कोड होता है। और निश्चित रूप से एक अच्छा GUI बनाना अपने आप में एक चुनौती है।

लेकिन कुछ लोगों के लिए यह सिर्फ आपके ऐप के लिए एक बटन खींच रहा होगा। जैसे कुछ लोगों के लिए व्यावसायिक तर्क "संदेश को पार्स करने और डीबी में रखने" से अधिक कुछ नहीं है।


2

मुझे लगता है कि यह स्पष्ट है कि वे करते हैं। शायद शीर्ष पायदान देव घरों को छूट दी गई है, लेकिन अधिकांश अन्य नहीं हैं।

जब आपका प्रबंधक आपसे पूछता है कि आपने पिछले महीने में क्या किया है, तो एक अच्छा GUI दिखाना आसान है। एक कूल एपीआई दिखाना मुश्किल है। बहुत मुश्किल। एपीआई शीतलता केवल वास्तविक उपयोग के माध्यम से स्पष्ट है - इसे एक नज़र में सराहा नहीं जा सकता।


1

आप आंतरिक प्रणालियों में सभी प्रकार की हैकरी और शॉर्टकट से दूर हो सकते हैं। जीयूआई से निपटने के दौरान आपके पास वह स्वतंत्रता नहीं होती है। आपके आंतरिक एपि में असंगति हो सकती है और आप बस कोडर्स से इससे निपटने की अपेक्षा करते हैं क्योंकि इसे ठीक करना बहुत कठिन है। आप कोशिश नहीं कर सकते हैं और अपने ग्राहकों को एक ही काम करते हैं। तो कुछ अर्थों में, जिन लोगों को उपयोगकर्ता के दृश्य घटकों से निपटना पड़ता है, उन्हें वास्तव में उच्च स्तर का पालन करना पड़ता है।


1

मैं एक साधारण कारण के लिए हां कहने जा रहा हूं: आईफोन। हर कोई मैंने कभी भी यह सोचने के लिए बोला है कि यह चालाक इंटरफ़ेस के कारण शानदार है, लेकिन मैं केवल उस सभी संभव बनाने के लिए नीचे दिए गए काम की कल्पना कर सकता हूं।


1

यह दर्शकों पर निर्भर करता है। मैं बहुत सारे वित्तीय विश्लेषकों के साथ काम करता हूं और एक अच्छे gui डिज़ाइन के बारे में उनका विचार एक ऐसा क्षेत्र है जिसमें कई क्षेत्र हैं जैसा कि आप संभवतः एक फॉर्म पर जाम कर सकते हैं। गंभीरता से, मैं 75 की बात कर रहा हूं - 100. वे डेटा के दीवाने हैं जो हमेशा अधिक चाहते हैं। मैंने हाल ही में कुछ संग्रहीत प्रक्रियाओं पर प्रदर्शन में सुधार किया है जो लोड करने के लिए 45 सेकंड ले सकता है (समय सामान की शुरुआत के बाद से भारित औसत की गणना करें)। 30 सेकंड के लिए इसे नीचे मिला; मैं सोच रहा हूँ वाह, एक तिहाई समय काटो; यह मेरे फिर से शुरू पर एक लाइन आइटम होना चाहिए। किसी ने भी गौर नहीं किया। इस पर काम करना शुरू कर दिया और इसे 15-20 तक पहुंचा दिया। ध्यान देने योग्य परिवर्तन। सभी लोग बहुत खुश थे। मुझे अभी भी लगता है कि जीयूआई एक घृणा है और अगर हमने इस बेकार बकवास को निकाल लिया, तो यह 2 सेकंड में लोड हो जाएगा,

इसलिए यदि आप चाहते हैं कि उपयोगकर्ता वास्तव में आपसे प्यार करें, तो याद रखें कि सबसे अच्छा उपयोगकर्ता इंटरफ़ेस बिल्कुल भी इंटरफ़ेस नहीं है (काश मुझे याद हो कि यह किसने कहा था)। इन सभी डेटा को देखने के बाद, मेरे विश्लेषकों ने महसूस किया है कि वे सभी डेटा प्रविष्टि - डरावनी करने वाले हैं।


1

आवेदन के यूआई भागों का परीक्षण एक बुरा सपना है।

आस-पास का हर व्यक्ति एक सलाह देने या एक मांग निर्धारित करने के लिए सक्षम महसूस करता है कि आपको यह कैसे करना चाहिए।

सिस्टम ठीक से काम करने के बाद, बाद में भी अगर कोई व्यक्ति गलती से याद करता है, जो इसमें पुण्य को संकोच करता है, तो किसी को याद नहीं होगा कि किसने क्या किया।

लेकिन अगर कोई त्रुटि देखी जाएगी ( कुछ हमेशा होती है), तो दोषी ठहराए जाने वाले पहले व्यक्ति GUI प्रोग्रामर होंगे, उपयोगकर्ता ने कभी दूसरों को नहीं देखा था!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.