उपभोक्ता टीमों में धीमी गति से प्रदर्शन को कैसे रोका जा सकता है?

Question

जब मैंने पहले पूछा कि धीमे सॉफ्टवेयर के लिए क्या जिम्मेदार है, तो मुझे मिले कुछ जवाबों से पता चलता है कि यह एक सामाजिक और प्रबंधन समस्या थी:

यह एक तकनीकी समस्या नहीं है, यह एक विपणन और प्रबंधन की समस्या है। .... आखिरकार, उपयोगकर्ता जो प्राप्त करने वाले हैं उसके लिए चश्मा लिखने के लिए उत्पाद प्रबंधक जिम्मेदार हैं। बहुत सी चीजें गलत हो सकती हैं: उत्पाद प्रबंधक कल्पना में बटन प्रतिक्रिया देने में विफल रहता है ... क्यूए लोग कल्पना के खिलाफ परीक्षण का एक औसत काम करते हैं ... यदि उत्पाद प्रबंधन और क्यूए कर्मचारी व्हील पर सो रहे हैं, तो हम प्रोग्रामर उसके लिए नहीं बना सकते। - बॉब मर्फी

लोग अच्छे आकार के ऐप पर काम करते हैं। जैसा कि वे काम करते हैं, प्रदर्शन की समस्याएं बग की तरह ही बढ़ती हैं। अंतर यह है - कीड़े "बुरे" हैं - वे रोते हैं "मुझे ढूंढो, और मुझे ठीक करो"। प्रदर्शन की समस्याएं बस वहां बैठती हैं और खराब हो जाती हैं। प्रोग्रामर अक्सर सोचते हैं "ठीक है, मेरे कोड में प्रदर्शन की समस्या नहीं होगी। बल्कि, प्रबंधन को मुझे एक नया / बड़ा / तेज मशीन खरीदने की आवश्यकता है।" तथ्य यह है, अगर डेवलपर्स समय-समय पर सिर्फ प्रदर्शन समस्याओं के लिए शिकार करते हैं ( जो वास्तव में बहुत आसान है ) तो वे बस उन्हें साफ कर सकते हैं। - माइक डनलवे

इसलिए, यदि यह एक सामाजिक समस्या है, तो अपने ग्राहकों को धीमे सॉफ्टवेयर की शिपिंग से बचने के लिए एक संगठन क्या सामाजिक व्यवस्था कर सकता है?

Comments

इसने मुझे जेफ एटवुड के एक हालिया ब्लॉगपोस्ट की याद दिला दी ।

— रहमू

टिप्पणीकार: यदि आपको सवाल पसंद है, तो उसे वोट दें। यदि आपके पास कोई उत्तर है, तो कृपया उसे उत्तर के रूप में छोड़ें , टिप्पणी नहीं। अन्यथा, कृपया केवल एक टिप्पणी छोड़ दें यदि आपको लगता है कि प्रश्न स्पष्ट या सुधार हुआ है, या यदि आपके पास संबंधित संसाधन के लिए लिंक है।

Answer 1

सही ढंग से लिखित और पूर्ण आवश्यकताओं के साथ, कीड़े और खराब प्रदर्शन के बीच अंतर जैसी कोई चीज नहीं है । क्योंकि आप प्रदर्शन को गैर-कार्यात्मक आवश्यकता के रूप में निर्दिष्ट करते हैं, इसलिए खराब प्रदर्शन किसी अन्य बग की तरह ही बग बन जाता है, और क्यूए द्वारा पकड़ा जाएगा और रिलीज से पहले डेवलपर्स द्वारा हल किया जाएगा।

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

एक और कारक है जो खराब प्रदर्शन को प्रभावित करता है: तथ्य यह है कि डेवलपर्स महंगे पीसी पर काम करते हैं जो अच्छा प्रदर्शन करते हैं । जब आप 8 जीबी रैम, एक उच्च अंत एसएसडी, नवीनतम ओएस आदि के साथ क्वाड-कोर पीसी पर वर्षों से काम कर रहे हैं, तो यह कल्पना करना बहुत मुश्किल है कि डुअल-कोर पीसी पर विंडोज एक्सपी पर आपका आवेदन कैसे चलेगा। 512 एमओ रैम और एक पुरानी हार्ड डिस्क 90% से भर गई और वर्षों तक डीफ़्रेग्मेंट नहीं हुई। दुर्भाग्य से, कुछ देशों में, अंतिम मामला वह है जिसे हम किसी ऐप के अधिकांश उपभोक्ताओं के लिए देखते हैं। डेवलपर पीसी और उपभोक्ता पीसी के बीच की खाई जितनी बड़ी होगी, किसी डेवलपर के लिए अपने ऐप के प्रदर्शन की देखभाल करना उतना ही जटिल होगा।

Comments

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

— RLH

मैं यह सुझाव नहीं दूंगा कि दैनिक आधार पर, चूंकि यह QA विभाग के समग्र प्रदर्शन को कम करेगा और धीमी मशीनों पर काम करने वाले कर्मचारियों को उदास करेगा। IMHO, आवश्यकताओं के रूप में प्रदर्शन मेट्रिक्स डालना पर्याप्त है, यदि सही तरीके से निर्दिष्ट किया गया है (यानी स्वचालित प्रदर्शन परीक्षण किस मशीन पर किया जाना चाहिए, किस लोड के साथ, औसत लेने के लिए कितनी बार, आदि)।

— बजे आर्सेनी मूरज़ेंको

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

— मत्तनाज

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

— मैट्नज़

यहाँ समस्या यह है, आप कभी भी "सही ढंग से लिखित और पूर्ण आवश्यकताएं" प्राप्त नहीं करते हैं। किसी भी आकार या जटिलता के आवेदन पर नहीं।

— कैफीक सेप

Answer 2

समस्या(?):

• ग्राहक (या अंतिम-उपयोगकर्ता) इसके बारे में शिकायत नहीं करता है (पर्याप्त)
• इस प्रकार परियोजना (/ उत्पाद) प्रबंधक इसे एक आवश्यकता नहीं मानता है
• इस प्रकार डेवलपर को इसे ठीक करने का समय नहीं मिलता है।

आपको शुरुआत में ग्राहकों को शिक्षित करना होगा। लेकिन अगर वे तेज, कम चमकदार फोन के बजाय आईफोन खरीदते हैं, तो डेवलपर्स को प्रदर्शन के बजाय लुक्स पर अपना समय बिताना सही होगा। संगठन समस्या नहीं है।

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

लेकिन आप सब कुछ नहीं कर सकते। यह सुविधाओं को अनुकूलित करना या जोड़ना है, और जो पैसे खर्च करते हैं वे तय करते हैं।

लेकिन कुछ अच्छी खबरें: मैंने देखा है कि SaaS / Cloud / Buzzword-Applications यहाँ बहुत मदद करते हैं। जब लोग कुछ समान वेब-अनुप्रयोगों के बीच चयन करते हैं और पहले 'आवश्यक' विशेषताओं की कृत्रिम सूची बनाने के बजाय लाइव परीक्षण करना चाहते हैं, तो वे अधिक तेज़ी से जवाबदेही से प्रभावित होते हैं, और इस प्रकार प्रदर्शन को अधिक ध्यान मिलेगा।

Comments

मुझे पता है कि बहुत अच्छी तरह से, बस टाइमिंग +1

— mKorbel

Answer 3

अफसोस की बात है कि मुझे सबसे बड़ा मुद्दा यह लगता है कि आप सब कुछ नहीं कर सकते। आपके पास एक जहाज की तारीख है, और आप जानते हैं कि यह धीमा है, लेकिन आपको बाजार में एक्स, वाई, जेड की विशेषताएं प्राप्त करने की आवश्यकता है।

आपके दिमाग में, धीमी गति से आप बाद में ठीक कर सकते हैं, लेकिन ऐप कम से कम काम करता है।

इसलिए, आप कार्यक्षमता और सौंदर्यशास्त्र के बारे में चिंता करते हैं (क्योंकि उपयोगकर्ता अक्सर सभी पर सौंदर्यशास्त्र पर ध्यान केंद्रित करते हैं)। अगली रिलीज आप प्रदर्शन को ठीक करेंगे।

लेकिन पीएम सिर्फ आपको फीचर्स की एक सूची देता है, और प्रदर्शन को ठीक करने का समय नहीं है।

और दुष्चक्र जारी है।

Comments

यह तभी तय हो जाता है जब पीएम आपको "बेहतर प्रदर्शन" नामक एक "सुविधा" प्रदान करते हैं!

— FrustratedWithFormsDesigner

जब तक पीएम प्रदर्शन में सुधार करना चाहते हैं, तब तक ऐसा करने का एकमात्र वास्तविक तरीका फिर से है :)

— जॉब

यहां मुख्य बात यह है कि अधिकांश उपभोक्ता अनुप्रयोगों के लिए, प्रदर्शन एक ऐसी सुविधा नहीं है जो सॉफ़्टवेयर बेचता है। यह ऐसा कुछ नहीं है जो "इस सॉफ्टवेयर की चीजें करता है" की सूची में चमकदार दिखता है। कंप्यूटर गेम इस सोच का एक चमकदार उदाहरण है। समय के साथ खेलों के लिए सिस्टम की आवश्यकताओं में लगातार वृद्धि हुई है, जिसका अर्थ है कि नए गेम उसी हार्डवेयर के साथ धीमे हैं जो आपने पहले किए थे, क्योंकि एक उच्च फ्रैमरेट उस बॉक्स को शेल्फ से दूर नहीं जा रहा है, लेकिन वास्तविक वातावरण वास्तविक समय में भग्न विस्तार के साथ प्रस्तुत किया गया है होगा ...

— मलाकी

+1 यहाँ है जहाँ यह वास्तव में अच्छे प्रदर्शन के साथ एक प्रतियोगी होने में मदद करता है। जब पीएम देखते हैं, तो वे डर जाते हैं, और आपसे इसके बारे में कुछ करने को कहते हैं।

— माइक डनलवे

@, सशर्त संभावना अधिक है, लेकिन पूर्णता कम है। मैं एक ऐप पर काम करता हूं जो विंडोज संस्करण के लिए 16-बिट सी प्रोग्राम के रूप में शुरू हुआ था "मेरे जन्म के बाद मुश्किल से"। फास्ट-फॉरवर्ड कि आज से और कई वर्षों और दर्जनों प्रोग्रामर बाद में आपको सी, सी ++, सी #, वीबीनेट और बहुत सारे एसक्यूएल विक्रेताओं का मिश्रण मिला है। F # में ऐप के कुछ प्रमुख भागों को रीक्रिएट करने से भयानक विचार नहीं आता ...

— Job

Answer 4

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

लोगों को पता होगा कि कैसे - और वे नहीं

वे सोच सकते हैं कि वे ऐसा करते हैं, लेकिन केवल StackOverFlow और इस मंच पर सभी प्रदर्शन-संबंधित प्रश्नों और उत्तरों के माध्यम से देखें। यह दर्दनाक है कि कितने प्रदर्शन के बारे में बहुत कम सामान्य ज्ञान दिखाते हैं।

यह सिर्फ बात करने के लिए कुछ नहीं है लोगों के बारे में जानने की जरूरत है क्या कर रही यह। केवल उस समय वे उस मोड में हैं जब वे क्लास ले रहे हैं, या किसी किताब या ब्लॉग से नई चीजें सीख रहे हैं।

तो जिस तरह से मैं इस समस्या को हल करने के बारे में सोच सकता हूं वह यह है कि प्रोग्रामिंग सिखाने वाले लोगों को पकड़ना है , और उन्हें यह सिखाना है कि यह कैसे करना है।

स्वर्ग जानता है, मैंने इन मंचों पर कोशिश की है, जैसे कि -

• मूल सुपर-सरल विधि
• एक 43x speedup - करना है कि अपने प्रोफाइलर साथ
• कारण क्यों, मतली विस्तार से

हर कोई यह कर सकता है। उन्हें बस वास्तव में ऐसा करने की जरूरत है ।

Answer 5

प्रदर्शन को एक आवश्यकता बनाएं।

Comments

+1: यह उतना ही सरल है। "फंक्शन X को Y मिलीसेकंड में पूरा होना चाहिए"।

डॉन; 'पर्यावरण को निर्दिष्ट करने के लिए मत भूलना जिसमें इसे चलाया जाएगा - उदाहरण के लिए, हमारे पास एक एनएफआर है जो कि 40ms विलंबता (यानी एक वान) के साथ नेटवर्क पर चलने पर एक मानक के लिए प्रदर्शन करेगा। यदि आप देवता ऐसा कुछ नहीं पेश करते हैं जो केवल सुपर कंप्यूटर पर ठीक प्रदर्शन करता है।

— gbjbaanb

Answer 6

कलाकार कोड लिखना कठिन है। इसके लिए थ्रेडिंग, एसिंक्रोनस इवेंट हैंडलिंग, कैशिंग और एसिम्प्टोटिक जटिलता जैसी अवधारणाओं की एक ठोस समझ की आवश्यकता होती है। जिन प्रोग्रामरों के साथ मैंने काम किया है, उनके समूहों को देखते हुए, किसी भी समूह का लगभग 20-40% उन अवधारणाओं को अच्छी तरह से समझ नहीं पाता है जो प्रदर्शन के विचारों को अपने दैनिक कार्य में शामिल करना चाहते हैं।

हालांकि, वे प्रोग्रामर स्पष्ट रूप से कंपनी के लिए अभी भी उपयोगी हैं, लेकिन वे प्रदर्शन के लिए महत्वपूर्ण नहीं माने जाने वाले कार्यों को सौंपा जाता है, इसलिए आप एक ब्लू रे प्लेयर के साथ समाप्त होते हैं, जो किसी भी फ्रेम को गिराए बिना नेटफ्लिक्स स्ट्रीम खेल सकते हैं, लेकिन इसमें 30-60 सेकंड लगते हैं मेनू आइटम खोलने के लिए जो आपकी कतार प्रदर्शित करता है।

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

Comments

इसके अलावा, यहां तक ​​कि महान प्रोग्रामर को प्रदर्शन समस्याओं में अंतर्दृष्टि प्राप्त करने के लिए महान इंस्ट्रूमेंटेशन और प्रोफाइलिंग टूल की आवश्यकता होती है। (प्रदर्शन विशेषताओं के साथ कई प्रोग्रामिंग प्रतिमान हैं जो स्टैक ट्रेस विश्लेषण को परिभाषित करते हैं।) ये उपकरण आमतौर पर ओपन-सोर्स शैली में लिनक्स प्लेटफार्मों के लिए उपलब्ध हैं, लेकिन मालिकाना और कस्टम प्लेटफार्मों में, इन उपकरणों को अक्सर कर्मचारियों से इनकार कर दिया जाता है।

— रवांग

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

— सेलेक

Answer 7

यदि प्रदर्शन एक आवश्यकता है, तो इसके लिए परीक्षण करें।

अन्यथा वैली एक अनंत लूप लिख सकती है और जल्दी छोड़ सकती है "इसमें कुछ समय लगता है।" वह दावा कर सकता है।

आपके सॉफ़्टवेयर स्वीकृति परीक्षण में विभिन्न ऑपरेशन प्रदर्शन विशेषताओं के लिए एक विस्तृत स्वीकृति परीक्षण होना चाहिए।

यदि आप ऐसा नहीं करते हैं तो आप उत्पाद के किसी भी प्रदर्शन को इंजीनियरिंग नहीं कर रहे हैं ।

प्रदर्शन (संसाधन खपत की तरह) को सब-सिस्टम के लिए बजट मिलना चाहिए। फिर उप-सिस्टम स्वीकृति परीक्षण उन्हें जांच सकते हैं।

फिर आप प्रदर्शन के लिए जल्दी और अक्सर परीक्षण कर सकते हैं। यहां तक ​​कि इकाई परीक्षण भी इसकी जांच कर सकते हैं।

इसलिए अब डेवलपर्स के पास इसे स्वीकार्यता मानदंड के रूप में है, और इसे सूट करने के लिए अपने दृष्टिकोण को व्यवस्थित कर सकते हैं।

जहाँ मैं अभी काम कर रहा हूँ, प्रदर्शन तनाव परीक्षण हमारे द्वारा ज्ञात किसी भी ग्राहक डेटा सेट से बड़ा है। यह नियमित रूप से उत्पाद के एक नए संस्करण को तोड़ता है। अच्छा परीक्षण।

Answer 8

मुझे 90 के दशक के मध्य में एक बार याद आया और मैं कुछ समय बिताने की कोशिश कर रहा था कि एक सहकर्मी ने मुझसे कहा, "यह पेंटियम पर चल रहा है, कौन परवाह करता है?" .... वह एक आंख खोलने वाला था। अफसोस की बात है, यह सिर्फ हिमशैल का टिप था, मैंने अपने पूरे करियर में उस दृष्टिकोण को सुना है - यद्यपि "पैंटियम" भाग समय के साथ बदल गया है।

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

Answer 9

लेकिन यह प्रोग्रामर के लिए क्यूए से एक पत्र नहीं लेना चाहिए, यह महसूस करने के लिए कि कीपर और प्रतिक्रिया के बीच 3 सेकंड का अंतराल अस्वीकार्य है

सहमत नहीं होना चाहिए। यह उससे अधिक होना चाहिए: एक प्रमाण जो लैग प्राप्त हुआ है वह अंतिम उपयोगकर्ताओं के लिए प्रासंगिक है ।

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

कार्यक्षमता परीक्षण में डेवलपर्स पर भरोसा गति बढ़ाने के लिए एक पासा को रोल करने के रूप में उत्पादक के रूप में होता है। ओह और यह उतना ही विश्वसनीय है जितना कि - "डेवलपर्स में आमतौर पर भयानक अंतर्ज्ञान होता है, जहां एक आवेदन में प्रदर्शन की समस्याएं वास्तव में होंगी" ( ब्रायन गोएत्ज़ )।

• मैं एक ऐसी परियोजना में रहा हूँ जहाँ लंगड़ा प्रबंधन ने एक बार अपने उज्ज्वल विपणन के लोगों का फैसला किया और स्मार्ट प्रोग्रामर ग्राहकों के प्रदर्शन की चिंताओं को संभालने के लिए पर्याप्त हैं। यह कितना बड़ा सबक था। रिजेक्टेड रिलीज, कचरा बिन में गए प्रयासों का आधा साल, और कंपनी ने लगभग एक रणनीतिक साझीदार खो दिया। अंत में, उन्होंने पेशेवरों (बेंचमार्किंग, सांख्यिकी, यूएक्स, निम्न स्तर के अनुकूलन, उस तरह के सामान) में विशेषज्ञों को आमंत्रित किया और पेशेवरों ने उस गड़बड़ को ठीक किया।

---

क्या सभी प्रोग्रामरों को अपना क्यूए करना चाहिए ताकि वे तुरंत इस तरह के मुद्दों को देखें?

तथ्य यह है कि यह संभव है इसका मतलब यह नहीं है कि यह जाने का रास्ता है। इसके विपरीत - मेरे अनुभव में यह प्रोग्रामर उत्पादकता पर खोने के सबसे विश्वसनीय तरीकों में से एक था । लगभग अंतहीन बैठकों के रूप में अच्छा है और उम्मीदवारों के साक्षात्कार से भी बेहतर है।

• एक पूर्व-परीक्षक के रूप में मैंने एक बार सोचा था कि यह विकास और क्यूए गतिविधियों को संयोजित करने के लिए समस्या नहीं होनी चाहिए। ऐसा लगता है कि नियमित देव परीक्षण और व्यवस्थित क्यूए के बीच अंतर ज्यादा मायने नहीं रखेगा। मुझे लगा कि सॉफ्टवेयर उद्योग में देव / क्यूए अलगाव केवल एक परंपरा है। बल्कि कठिन तरीके से सीखा कि यह ऐसा नहीं है। पृथक्करण ध्यान और उत्पादकता का विषय बन गया, और काफी गंभीर भी।

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

Comments

downvoter - क्या यह QA में और प्रदर्शन परीक्षण में देव टीम की जरूरतों को कवर करने वाले पेशेवर परीक्षकों के साथ काम करने के लिए हुआ था ? यदि नहीं, तो इसे एक कोशिश देने पर विचार करें

— gnat

Answer 10

मुझे लगता है कि आप पाएंगे कि 99% समय समस्या की गुंजाइश है। उदाहरण के लिए dvr के साथ। आपको लगता है कि यह आसान है, लेकिन तब TIVO या एक प्रतियोगी एक नई सुविधा का परिचय देता है जो अच्छी तरह से प्राप्त होती है। अगली बात आपको पता है कि एक नई सुविधा प्लेट पर है। यह मौजूदा उत्पाद के साथ असंगत हो भी सकता है और नहीं भी हो सकता है और हम उस मौजूदा उत्पाद को फिर से तैयार नहीं कर रहे हैं जो लंबे समय तक ले जाएगा। तो सुविधा में जाम हो जाता है और यह प्रदर्शन को बेकार कर देता है। निश्चित रूप से डेटा इंफ़र्मेशन प्राप्त करने के लिए है, लेकिन अगर उस जानकारी को प्राप्त करने के बारे में नहीं सोचा गया था, तो एक अच्छा मौका है इसे प्राप्त करना आसान नहीं होगा। तो अब आपके पास उस जानकारी को बनाने की एक जटिल प्रक्रिया है जो आप प्रोग्राम सूची के पास जाते हैं।

Answer 11

ऐसे डेवलपर्स को अनदेखा करना, जिनकी देखभाल नहीं होती है ...

मुझे लगता है कि कई बार कोड पर काम करने वाले डेवलपर्स के पास निरंतर आधार पर प्रदर्शन को मापने के लिए उपकरण नहीं होते हैं।

उदा। यदि आपके ऐप के लिए प्रतिक्रिया समय को मापना संभव है (जैसे कि इसका वेब आधारित अनुप्रयोग, या डेटाबेस पर सवाल करना, आदि) - क्या आपको वर्तमान में सूचनाएं मिल रही हैं (ईमेल, एसएमएस, जो भी हो) जो "शीर्ष 10" को सबसे खराब संकेत देते हैं। प्रदर्शन (या एक निर्धारित सीमा से अधिक) प्रतिक्रियाएं?

कई मामलों में, कई मामलों में - डेवलपर्स को यह जानकारी "वास्तविक-दुनिया" की तैनाती से नहीं मिल रही है और इसके परिणामस्वरूप आपके द्वारा देखी गई जानकारी को अनदेखा करना बहुत आसान है।

यदि फिर भी, हर दिन / कुछ घंटों में आपको एक ईमेल मिलता है जो इंगित करता है कि स्क्रीन "x" लोड होने में 13 सेकंड लेता है और यह निम्नलिखित क्वेरी क्वेरी चला रहा हैSELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN... तो आप बेहतर विश्वास करेंगे कि एक डेवलपर (और उम्मीद है) सभी फिक्सिंग पर होगा यह।

इस प्रकार, हालांकि मुझे लगता है कि सभी प्रोग्रामर पर विश्वास करने के लिए करना चाहते हैं कर प्रदर्शन ले गंभीरता से मुझे लगता है कि समस्या (ओं) के लिए दृश्यता की है कि कमी अक्सर दोषी है।

नोट: मुझे लगता है कि यह कुछ ऐसा है जो दोनों डेवलपर्स को एक्सेस करने का अनुरोध करना चाहिए (या यहां तक ​​कि इस तरह की सुविधा विकसित करना) और प्रबंधन को इस तरह के उपकरण प्रदान / वित्त पोषण करना चाहिए।

Answer 12

क्या आप बेहतर उदाहरणों के साथ आ सकते हैं जहां हम वास्तव में प्रोग्रामर पर दोष लगा सकते हैं? एक्लिप्स के अलावा, और एक टिप्पणीकार ने पहले ही बताया है कि यह प्लगइन्स है जो इसे करता है (प्रत्येक नए एक्लिप्स संस्करण की मेरी पहली स्थापना लाइटनिंग की तरह चलती है, लेकिन जब मैं इसे जोड़ने वाले अन्य टूल को धीमा करना शुरू करता हूं), तो आपके उदाहरण प्रोग्रामर नहीं हो सकते हैं कोड संबंधित लेकिन पर्यावरण संबंधी।

किसी कंप्यूटर पर प्रोग्राम को अलग-थलग करने और यह निर्धारित करने के दिन कि यह 'तेज़' है या 'धीमा' चला गया है। आपके द्वारा दिए गए अन्य उदाहरण उनके वातावरण पर निर्भर करते हैं - वर्तमान नेटवर्क की भीड़, चाहे बैक एंड सर्वर अतिभारित हो, बुरी तरह से कॉन्फ़िगर किए गए नेटवर्क कार्ड, एक दोषपूर्ण केबल, आपके आसपास के क्षेत्र में इसका उपयोग करने वाले अन्य लोगों की संख्या, या सैकड़ों अन्य चर। जैसे। हमारे होस्टिंग प्रदाता ने सर्वर गीगाबिट कनेक्शन के लिए अतिरिक्त शुल्क लिया, लेकिन अंततः हमने निर्धारित किया कि यह सब 10Mb पोर्ट के साथ एक प्राचीन फ़ायरवॉल डिवाइस के माध्यम से चला गया। ये समस्याएं चारों ओर घूमती हैं और इन्हें ढूंढना कठिन है।

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

Comments

मैंने जो उदाहरण दिए, वे सभी मामले थे, जहां प्रदर्शन पूरी तरह से स्थानीय वातावरण में खराब था - डीवीआर स्थानीय स्तर पर दर्ज कार्यक्रमों के मेनू को नेविगेट करता है। आइट्यून्स धीमी गति से स्थानीय डेटा ब्राउज़ कर रहा है, स्टोर को नहीं देख रहा है। यहां तक ​​कि "हवाई जहाज मोड" में - कोई भी नेटवर्क नहीं है - iPhone 3 जी तस्वीरों को प्रदर्शित करने में इतना समय लेता है कि कभी-कभी ओएस वॉचडॉग लॉन्च होने से पहले ही ऐप को मार देगा। ये सभी उन मामलों के उदाहरण हैं जहां प्रोग्रामर को पता था कि कोड लिखने पर वे किस हार्डवेयर को लक्षित कर रहे थे, और विशेष रूप से तब जब से प्रत्येक अपडेट के साथ खराब हो जाने पर iPhone।

— क्रैश

@ क्रशवर्क - किसी ने आपके प्रश्न से उन उदाहरणों को हटा दिया है। क्या आप उन्हें फिर से विवरण के साथ जोड़ सकते हैं? फोटो उदाहरण लगता है कि कुछ और चल रहा है, जैसे कि एक लापता निर्भरता या यह इंटरनेट और टाइमिंग पर कुछ देखने की कोशिश कर रहा है। क्या आपने देखा कि क्या हो रहा है? एक अच्छी कहानी यह है कि जब MS ने HyperV जारी किया, तो VMWare समीक्षक ने उल्लासपूर्वक कहा कि भले ही उसने इसे जारी करने के अगले दिन स्थापित किया था, जबकि उसे विंडोज अपडेट का एक गुच्छा डाउनलोड करना था। क्यूं कर? HyperV सक्रियण प्रक्रिया ने IE8 dll का पुनः उपयोग किया। आधुनिक वातावरण में बहुत सारे गौचे हैं।

— 13

Answer 13

आप बेहतर सॉफ्टवेयर के लिए कितना भुगतान करने को तैयार हैं? बेहतर सॉफ्टवेयर के लिए बाजार कितना इंतजार करेगा? अगले रिलीज में कितना कम जुड़ना चाहेगा?

यह कट-ऑफ मार्केट है, जहां कई समझौते किए जाते हैं। यदि यह वास्तव में बकवास है तो बाजार उत्पाद को विफल कर देगा (या करना चाहिए)। शायद पर्याप्त ग्राहक हैं जो यथास्थिति के साथ रह सकते हैं?

Answer 14

मुझे लगता है कि इस समस्या का सबसे सामान्य जवाब प्रबंधन करना भी सबसे कठिन है, जो यह है कि प्रत्येक प्रोग्रामर को कुछ भी करने के साथ प्रदर्शन के प्रति सचेत होना चाहिए। मुझे यह भी एहसास हुआ कि बाहर पुलिस का एक सा है।

परियोजना के आकार, और इसी टीम के आधार पर, मेरा मानना ​​है कि समर्पित प्रदर्शन प्रोग्रामर होने में बहुत अधिक मूल्य हो सकता है।

एक उदाहरण के रूप में, मैंने एक टीम पर काम किया है जहाँ परियोजना टीम (लगभग 30 देवों सहित) में कम से कम 2 लोग प्रदर्शन अनुकूलन के लिए समर्पित थे। यह विशेष रूप से एप्लिकेशन भी प्रदर्शन के मुद्दों के लिए काफी प्रवण था क्योंकि न केवल वेब सेवाओं पर, बल्कि विभिन्न डेटा मैपिंग और एडेप्टर घटकों के साथ विरासत की परतों के संदर्भ में भी, अंतर्संचालनीयता घटकों के गुणांक थे।

Answer 15

पहले हाथ का अनुभव महत्वपूर्ण है। डेवलपर्स को संकलन करने और बनाने के लिए एक तेज़ कंप्यूटर दें, लेकिन अपने ऐप (ओं) को चलाने के लिए वास्तव में धीमी गति से अतिभारित कंप्यूटर (कुछ प्रतिशत उपयोगकर्ताओं के पास) हो सकता है। (यह फ़ंक्शन द्वारा VMs या सर्वरों को विभाजित करके क्लाउड / सर्वर आधारित विकास वातावरण में किया जा सकता है।) उन्हें आधी मृत बैटरी वाला एक सेल फोन दें, और उन्हें केवल शुरुआती मोबाइल ऐप परीक्षण के लिए इसका उपयोग करने की आवश्यकता होती है।

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

Answer 16

सामान खरीदना बंद करें, और, आपके द्वारा आए किसी भी ऑनलाइन समीक्षा पर खराब प्रदर्शन पर टिप्पणी करें।

यदि डिवाइस अभी भी बेच रहे हैं, तो सॉफ़्टवेयर "काफी अच्छा" है और अधिक समय और धन का निवेश नहीं करना है। यदि प्रदर्शन के बारे में खराब समीक्षा बिक्री को काफी कम कर देती है, तो सॉफ्टवेयर "बहुत अच्छा नहीं" है और इसे ठीक करने की आवश्यकता है।

एकमात्र मेट्रिक्स जो उपभोक्ता वस्तुओं के निर्माता के हित में हैं, प्रति यूनिट बिक्री और लाभ हैं।

Answer 17

मैं सहमत हूं कि प्रोग्रामर को अधिकतम प्रदर्शन, आदि पर बेहतर सिखाया जाना चाहिए।

लेकिन मुझे लगता है कि समाधान प्रोग्रामर को दैनिक उपयोग के लिए लगभग मरने वाला हार्डवेयर नहीं दे रहा है। यह कितना तनावपूर्ण होगा यदि आपका दृश्य स्टूडियो दिन में दो बार दुर्घटनाग्रस्त हो जाता है, तो सामान बनाने में x सेकंड लग गए, समाधान खोलने के लिए y सेकंड, विंडोज़ बदलने के लिए z सेकंड। मुझे नहीं लगता कि यह कंपनी के लिए बहुत ही किफायती था क्योंकि हार्डवेयर सस्ता है और प्रोग्रामर का समय महंगा है।

चूंकि अगला हाथ जो कोड को संभाल रहा होगा वह क्यूए (परीक्षण) टीम है, क्या उन्हें प्रदर्शन के महत्व के बारे में सिखाने के लिए बेहतर नहीं होगा, एक मानक मानक के रूप में व्हाट्सएप स्वीकार्य मानक का मानक है, (अच्छी तरह से, सही दुनिया में) प्रदर्शन मानक कल्पना में होना चाहिए, लेकिन यह बहुत बार नहीं होता है)? (यानी रेगुलर एंटरप्राइज ईई-चेंजिंग पेज / टैब तुरंत होना चाहिए, "सेव अपडेट x सेकंड में होना चाहिए", अगर यह एक महत्वपूर्ण ऐप है ...)। क्यूए टीमों को चलाने वाले कंप्यूटर में विशिष्ट उपयोगकर्ता कंप्यूटर होना चाहिए। (हम उन्हें एक 386 देकर उन्हें नाराज नहीं करना चाहते हैं, लेकिन उदाहरण के लिए 8GB RAM के साथ उन्हें एक क्वाड कोर न दें)। अगर वे प्रदर्शन के साथ पर्याप्त रूप से नाराज हो जाते हैं, तो क्या वे प्रोग्रामरों को हवा देंगे?

मुझे लगता है कि क्लाइंट / प्रोजेक्ट मैनेजर को प्रोग्रामर / क्यूए टीम / डेवलपर / कंपनी टीम के प्रतिनिधि को अपनी विशिष्ट कंप्यूटर हार्डवेयर पर अपनी प्रस्तुति करने के लिए मजबूर करना चाहिए। (उदाहरण के लिए कंपनी का सबसे कमजोर कंप्यूटर)। यदि यह फिर से लिखा जाता है, तो उन्हें पुराने सॉफ्टवेयर में x प्रक्रिया को करने के लिए कितनी तेजी से डेटा इकट्ठा करना होगा और नए सॉफ्टवेयर पर कितनी तेजी से इसकी तुलना करना है (यह धीमा हो सकता है, क्योंकि नए सॉफ़्टवेयर में अतिरिक्त व्यावसायिक प्रक्रिया शामिल हो सकती है लेकिन एक स्वीकार्य खिड़की होनी चाहिए)।

Answer 18

मैंने इसे पहले कहा है, लेकिन मैं इसे फिर से कहूंगा: मुझे लगता है कि इसे संभालने का एक सबसे अच्छा तरीका यह है कि आपके डेवलपर्स को केवल (अपेक्षाकृत) ट्रेलिंग एज हार्डवेयर पर काम करना है।

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

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

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

Comments

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

— क्रैश

जिस मामले में कंपनी को मुझे एक सभ्य तलवार खरीदना चाहिए, क्योंकि मैं अपना अधिकांश समय संकलन में खर्च करने जा रहा हूं।

— डेविड थॉर्नले

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

— मार्टिन यॉर्क

यह Slashdot टिप्पणी में (कुछ के बारे में) साल पहले सुझाव दिया गया था। प्रतिक्रिया थी: "डेवलपर्स को तेज मशीनों पर विकसित होना चाहिए और धीमी गति से परीक्षण करना चाहिए।"

— user16764

@ user16764: अक्सर डेवलपर्स परीक्षण वातावरण देने पर बहुत कम ध्यान दिया जाता है जो उनके विकास के वातावरण से अलग होते हैं। मेरी पत्नी के पास एक बहुत ही कठिन समय था जब दोनों को एक व्यवस्थापक खाता (विकसित करने के लिए) और एक अधिक सीमित खाता (परीक्षण के लिए) मिल रहा था, और इससे पहले लगातार एक रखरखाव में कुछ गलती करने के साथ लगातार समस्याएं थीं जो एक सामान्य उपयोगकर्ता पर नहीं चलेंगी लेखा।

— डेविड थॉर्नले