क्या किसी डेवलपर के नौकरी विवरण में "त्रुटि मुक्त" एक प्रमुख आउटपुट के रूप में उपयुक्त है? [बन्द है]


10

सभी नौकरी विवरणों की समीक्षा के एक हिस्से के रूप में, मेरी कंपनी ने निम्नलिखित को मुख्य आउटपुट के रूप में शामिल करने का निर्णय लिया है:

वेबसाइट का विकास समय पर पूरा हुआ, विनिर्देश और त्रुटि मुक्त

यह देखते हुए कि विनिर्देश नियमित रूप से बदलते हैं, कोई औपचारिक परिवर्तन नियंत्रण प्रक्रिया नहीं है और वातावरण हैं, क्या हम कहेंगे, यह अप्रत्याशित है कि यह KPI कितना वास्तविक और उचित है?


20
पूरी तरह से अवास्तविक। यह शायद किसी ऐसे व्यक्ति द्वारा लिखा गया था, जिसने एक बहुत से बुरे डेवलपर्स के साथ काम किया है। लेकिन यह खराब प्रबंधन का दोष भी हो सकता है। पर्याप्त जानकारी नहीं दी गई।
मार्क कैनलास

11
जो डेवलपर अपने रिज्यूमे पर "एरर फ्री कोड लिखता है" स्थिति से मिलान करने के लिए पर्याप्त रूप से आकर्षक होगा।
पी। ब्रायन। मैके 20

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

8
pfft ... लोगों को आसानी से बलि का बकरा जैसा लग सकता है। "क्षमा करें, आप अपने रोजगार समझौते पर नहीं टिके ... हम आपको बिना नोटिस या अतिरिक्त कारण के आग लगाने जा रहे हैं। टोटल्स।"
स्टीवन एवर्स

5
बेशक यह त्रुटि मुक्त है। संकलक कहता है: 0 त्रुटियां, 0 चेतावनी। यह पूरी तरह से नौकरी की आवश्यकताओं को पूरा करता है :-)
फेर्रुकियो

जवाबों:


21

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


9

मैं अधिकांश उत्तरों का विरोध करने वाला स्थान लेता हूँ और कहता हूँ कि यह बिल्कुल उचित और यथार्थवादी है।

क्या सभी विकास समय पर पूरे होंगे? बेशक, यह हमेशा नहीं होगा।

क्या सभी विकास विनिर्देश के भीतर पूरा हो जाएंगे? आप ऐसा करना चाहते हैं, लेकिन कभी-कभी यह संभव नहीं होगा और आपको एक असंभव या आत्म-विरोधाभासी कल्पना से विचलन को चिह्नित करना होगा।

और क्या सभी विकास त्रुटि मुक्त होंगे? कभी नहीं

लेकिन यही एक KPI है। यह कुछ ऐसा है जिसे मापा जा सकता है और जिसके द्वारा आप प्रदर्शन और प्रगति को ट्रैक कर सकते हैं।

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

काउंटर सवाल: KPI आप एक प्रोग्रामर के लिए क्या प्रस्ताव करेंगे ? यह कठिन है। हम जो करते हैं उसका बहुत कुछ मापना कठिन है।


4
किसी भी महत्वपूर्ण आकार का एक कोड आधार "त्रुटि मुक्त" के रूप में गारंटी देने के लिए व्यावहारिक रूप से असंभव है, क्योंकि एक त्रुटि हो सकती है जो आपको बस नहीं मिली है। इसके अलावा, एक त्रुटि क्या है? एक दोष? यह कैसे मापा जाता है?
फिलोसोडाद

1
@philosodad - यह मेरी बात है। यह त्रुटि मुक्त नहीं होगा । लेकिन अगर इस वर्ष आपके द्वारा लिखे गए कोड में x त्रुटियां पाई गई हैं, और अगले वर्ष x-4 हैं, तो आपने अपने KPI में सुधार किया है। जैसा कि एक त्रुटि है, यह वास्तव में आपके संगठन के लिए एक मामला है, और इसमें कोई संदेह नहीं है कि कुछ तर्क हो जाएंगे "त्रुटि" बनाम "अनिर्दिष्ट आवश्यकता" बनाम "परिवर्तित आवश्यकता" बनाम "राय का अंतर"।
कार्सन63000

3
@ Carson63000: लेकिन यह मेरी बात है! एक केपीआई जो कई तर्कों का कारण बनता है, पार्टियों के बीच अपरिहार्य असहमति पैदा करता है, और एक प्रमुख मीट्रिक को परिभाषित करता है, बहुत कम से कम, समस्याग्रस्त। अपना उदाहरण लेने के लिए, यदि "त्रुटि" एक व्यक्तिपरक उपाय है, तो यह अनुमान है कि प्रबंधक खुद को बेहतर दिखने के लिए त्रुटियों को परिभाषित करेंगे, इसलिए सभी के पास सटीक प्रदर्शन के लिए त्रुटि दर कम होगी। लेकिन एक नया प्रबंधक इसे परिभाषित कर सकता है, और फिर नीचे, यह दिखाने के लिए कि वे उसी सटीक आउटपुट को "सुधार" कैसे करते हैं।
फिलोसोडैड

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

3
KPI में एक लक्ष्य शामिल है जो न केवल काफी पूरा हो सकता है, बल्कि पार भी किया जा सकता है। आप इसका उपयोग मट्ठे को मापने के लिए करते हैं जो आप केपीआई लक्ष्य से भी बदतर या बेहतर कर रहे हैं। मैं नहीं देखता कि "त्रुटि मुक्त" कैसे पार किया जा सकता है। इसलिए, भले ही KPI के रूप में इरादा किया गया हो, यह त्रुटिपूर्ण है। एक बेहतर KPI दोषों की संख्या को मापने के लिए होगा, आपके द्वारा लिखे गए कोड के खिलाफ प्रस्तुत परीक्षण रिपोर्ट, जिसके परिणामस्वरूप वास्तविक कोड परिवर्तन हुए, आदि
Marjan Venema

4

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

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

यहां एक उदाहरण है जो बिंदु को अच्छी तरह से बनाता है।
एक प्रोग्रामर को पता चलता है कि हमारे सॉफ्टवेयर में एक "वर्ष 3000" बग है और 31 दिसंबर को 31,2999 के बाद कार्य करना बंद कर देगा। समस्या को ठीक करने में 6-8 महीने लगेंगे। KPI के आधार पर कंपनी को कोई वास्तविक मूल्य नहीं होने के बावजूद इस परियोजना को लेने के लिए प्रोत्साहित किया जाता है।

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


ऐसा लगता नहीं है कि आपके पास कोई KPI होगा जो "फिक्सिंग दोषों को कवर करता है जिन्हें प्रबंधन ने समस्या माना है, और फिक्सिंग की आवश्यकता नहीं है।"
कार्सन63000

@ करसन - कुछ बड़ी कंपनियों में नहीं जिन्हें मैं जानता हूं। मूर्खतापूर्ण लक्ष्य व्यवसाय करने के उनके तरीके का हिस्सा हैं।
जल्दी_अगले

3

नहीं

न केवल यह उचित नहीं है, बल्कि यह भव्य है

परीक्षण केवल त्रुटियों के अस्तित्व को साबित कर सकता है, उनकी अनुपस्थिति को नहीं, इसलिए इस सगाई के तहत लिखे गए प्रत्येक कार्यक्रम में शुद्धता का एक कठोर प्रमाण शामिल करना होगा ... और 100% परीक्षण कवरेज

"उपरोक्त कोड में बग से सावधान रहें; मैंने केवल इसे सही साबित किया है, इसे आजमाया नहीं है।" - डी। नथ

KPI एक लक्ष्य की दिशा में सफलता और प्रगति का माप है। वे बाइनरी टॉगल नहीं कर रहे हैं "त्रुटि-मुक्त कोड = सफलता, एक ही त्रुटि = विफलता, आपको निकाल दिया गया है!"
कार्सन63000

@ कैरसन: "त्रुटि-मुक्त" एक KPI नहीं है, यह एक कल्पना है।
स्टीवन ए। लोव

1
मेरे लिए एक सिलाई की तरह लगता है। जद में मूर्खतापूर्ण तरीके से कुछ डालें फिर जब भी किसी बहाने की जरूरत होती है तो व्यक्ति को निकाल दिया जा सकता है क्योंकि वे जद के रूप में प्रदर्शन नहीं कर रहे हैं।
जल्दी_अगले

3

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

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

प्रोग्रामर अपनी त्रुटियों के लिए बाकी सभी को दोष देना पसंद करते हैं। "मेरे कार्यक्रम में आवश्यकताओं के कारण या कार्यक्रम के कारण बग हैं, या क्योंकि चंद्रमा 8 वें घर में है" लेकिन वास्तव में दोष देने वाला कोई और नहीं है। यदि आपके प्रोग्राम में त्रुटियां हैं, तो आप उन्हें वहां डाल देंगे।

हमारा पेशा कभी भी ऐसा पेशा नहीं होगा जब तक प्रोग्रामर को यह एहसास न हो जाए कि हिरन उनके साथ रुकता है। कि वे अपने कार्यक्रमों की गुणवत्ता के लिए जिम्मेदार हैं।

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

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

हम कभी भी एक पेशा नहीं बनेंगे जब तक कि हमें यह महसूस नहीं हो जाता कि यह हमारा काम है कि क्यूए को कुछ नहीं मिलता है।


+1, लेकिन मैं वास्तविकता के बजाय व्यक्तिगत लक्ष्य के रूप में त्रुटि मुक्त होना चाहता हूं। हम सभी को इसके लिए जाना चाहिए लेकिन जब तक हमें अंतहीन संसाधन नहीं मिलेंगे, हम कम से कम यह नहीं बताएंगे कि अब हम सॉफ्टवेयर कैसे विकसित करते हैं।
रजनीसन

मैं अंकल बॉब की भावनाओं के साथ अधिक दृढ़ता से सहमत नहीं हो सका। यह व्यावसायिकता का सवाल है।
जॉन्सवेब

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

3

अफसोस की बात है कि यह उनके लिए "सभी ठिकानों को कवर" करने का एक तरीका है, और स्पष्ट रूप से अनुशंसित नहीं है और डेवलपर्स में सिर्फ मोहभंग होने की संभावना है।

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


मेरे वर्तमान कार्य वातावरण को देखते हुए, मुझे बहुत संदेह होगा कि वे उस शब्द को कैसे लागू करेंगे।
फिल.हेलर

2

"त्रुटि-मुक्त" के रूप में "सही?" जैसा कि "ईश्वर और स्वर्गदूतों द्वारा लिखा गया है, मनुष्य नहीं?" (हम यहाँ प्रोग्राम-लॉजिक और शायद हार्डवेयर-लॉजिक एरर्स बोल रहे हैं)

मैं कोड की एक भी लाइन के बारे में सच नहीं कह सकता कि यह त्रुटि के बिना है। ऐसा इसलिए है क्योंकि हम इंसान, अच्छी तरह से, हम कोई नकारात्मक परिकल्पना साबित नहीं कर सकते हैं!

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

और मैं उस समझ को केवल एक संभावना के रूप में व्यक्त कर सकता हूं । तो "लॉजिक-एरर-फ्री" शब्द का अर्थ है, कुछ भी नहीं।

यदि मैंने एक सॉफ़्टवेयर इंजीनियर के लिए एक विज्ञापन देखा, जिसने "त्रुटि-मुक्त" कोड का उत्पादन किया, तो मैं तुरंत लागू करूंगा या मैं तुरंत भाग जाऊंगा: कंपनी ने इस बारे में ज्यादा नहीं सोचा कि यह कैसे विकसित होती है, परीक्षण करती है, और इसके सॉफ्टवेयर का उद्धार करती है । तो यह या तो एक महान अवसर या एक अंतहीन दुःस्वप्न होगा।

और चाहिए - - किसी भी सॉफ्टवेयर की, हालांकि, मैं आसानी से कर सकते हैं कहते हैं कि मैं कोड कोई त्रुटि है कि गिरावट है कि उम्मीद के बाहर है कि sucky, संदिग्ध, तर्क-ey सामान: कोड है कि compiles और त्रुटि या चेतावनी के बिना लिंक; वह "वैध html" या "वैध css" है; जावास्क्रिप्ट (कहना) जो कोई अस्पष्टीकृत त्रुटि संदेश या ब्राउज़र दोष उत्पन्न करता है। वह हिस्सा मैं सीधा और एक ग्राफ पर काले और सफेद रंग में चिह्नित कर सकता हूं।

पाई के रूप में वह हिस्सा आसान है। कोई भी ऐसा कर सकता है

अरे, आपकी खोज में अच्छी किस्मत :-)


1

क्या मैं बेवकूफ हूं, या "त्रुटि" का मतलब "गैर-संकलित कोड के लिए घातक संकलक संदेश" नहीं है?

उस परिभाषा के अनुसार, यह एक बहुत ही उचित आवश्यकता है ...


1
सच। पृष्ठ पाद लेख पर गलत तरीके से लिखे गए पाठ में त्रुटि हो सकती है, लेकिन यह निश्चित रूप से त्रुटि के समान वर्ग में नहीं है, जो कुछ ऐसा है जो पृष्ठ को लोड करने में विफल होने से रोकता है और उपयोगकर्ता को रनटाइम त्रुटियों को थूकता है।
FrustratedWithFormsDesigner

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

इस टिप्पणी को लिखने के बाद से चार वर्षों में, मैंने बहुत अधिक वेब विकास का एक नरक किया है और पूरी तरह से सहमत हूं - असामान्य रूप से, हालांकि, मैं 4 साल पहले से अपने जवाब से खड़ा होने जा रहा हूं और कहता हूं कि मैं जिस बिंदु की कोशिश कर रहा था यह है कि "त्रुटि" की परिभाषा मनमाना है, और (बहुत) कुछ परिभाषाओं का चयन करना एक उचित आवश्यकता है।
क्रिस ब्राउन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.