जूनियर प्रोग्रामर्स टेस्ट कैसे लिखें? [बन्द है]


108

हमारे पास एक जूनियर प्रोग्रामर है जो बस पर्याप्त परीक्षण नहीं लिखता है।
मुझे हर दो घंटे में उसे नहलाना है, "क्या आपने परीक्षण लिखा है?"
हमने कोशिश की है:

  • यह दिखाते हुए कि डिजाइन सरल हो जाता है
  • इसे दिखाने से दोषों से बचाव होता है
  • यह एक अहम् बात कहते हुए कि केवल खराब प्रोग्रामर नहीं हैं
  • इस सप्ताह के अंत में 2 टीम के सदस्यों को काम करना पड़ा क्योंकि उनके कोड में NULL संदर्भ था और उन्होंने इसका परीक्षण नहीं किया था

मेरे काम के लिए उच्च गुणवत्ता वाले स्थिर कोड की आवश्यकता होती है, और आमतौर पर हर कोई इसे प्राप्त कर लेता है और परीक्षणों को आगे बढ़ाने की आवश्यकता नहीं होती है। हम जानते हैं कि हम उसे परीक्षण लिखने के लिए बना सकते हैं, लेकिन हम सभी जानते हैं कि उपयोगी परीक्षण वे लिखे जाते हैं जब आप उसमें होते हैं।

क्या आप अधिक प्रेरणाओं के बारे में जानते हैं?


16
मुझे अपनी कंपनी में किराया! मैं ख़ुशी से एक के लिए मेरा पीछा छोड़ता हूं जो मुझे सॉफ्टवेयर के बारे में पर्याप्त देखभाल करता है कि मुझे बेहतर परीक्षण कैसे लिखना है।
स्टीवन एवर्स

@SnOrfus - मैंने नौकरी बदल दी है, क्षमा करें;)
abyx

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

1
@ और मैं कहूंगा कि बाकी को अनुभव के साथ और अधिक करना है, जबकि परीक्षण एक मन-सेट का अधिक है?
27'10

1
यह प्रश्न ऑफ़-टॉपिक प्रतीत होता है क्योंकि यह एक विशिष्ट प्रोग्रामिंग समस्या नहीं है, और सॉफ़्टवेयर इंजीनियरिंग पर अधिक उपयुक्त होगा ।
hichris123

जवाबों:


125

यह सबसे कठिन काम है। अपने लोगों को पाने के लिए

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

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

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

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

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


बॉलिंग गेम काटा अच्छा है!
हर्टेंटो लेट

यूनिट टेस्टिंग 101 लिंक टूट गया है। मैंने वेबपेज संग्रह की खोज करने की कोशिश की, लेकिन कुछ भी उपयोगी नहीं पाया। किसी को भी यह प्रस्तुति मिली?
डिस्प्ले 33

21

हर प्रतिबद्ध होने से पहले एक कोड की समीक्षा करें (भले ही यह 1 मिनट "मैंने इस चर नाम को बदल दिया है"), और कोड समीक्षा के हिस्से के रूप में, किसी भी इकाई परीक्षणों की समीक्षा करें।

परीक्षण होने तक अपनी ओर से साइन अप न करें।

(यह भी - यदि उनके काम का परीक्षण नहीं किया गया था - तो यह पहली बार उत्पादन निर्माण में क्यों था? यदि यह परीक्षण नहीं किया गया है, तो इसे अंदर न आने दें, फिर आपको सप्ताहांत काम नहीं करना पड़ेगा)


20

खुद के लिए, मैंने जोर देकर कहा है कि मैं जो भी बग ढूंढूं और ठीक करूं उसे एक परीक्षण के रूप में व्यक्त किया जाए:

  1. "ह्म्म्म, यह सही नहीं है ..."
  2. संभव समस्या का पता लगाएं
  3. एक परीक्षण लिखें, यह दिखाएं कि कोड विफल रहता है
  4. समस्या का समाधान कीजिए
  5. दिखाएँ कि नया कोड पास हो गया है
  6. यदि मूल समस्या बनी रहती है तो लूप करें

मैं सामान बाहर पीटते हुए भी ऐसा करने की कोशिश करता हूं, और मैं लगभग एक ही समय में आंशिक परीक्षण सूट के साथ ही काम करता हूं।

(मैं एक वाणिज्यिक प्रोग्रामिंग वातावरण में नहीं रहता हूं, और मैं अक्सर केवल एक विशेष परियोजना का काम करने वाला कोडर हूं।)


1
+1 मुझे लगता है कि परीक्षण शुरू करने के लिए यह एक उत्कृष्ट कम प्रभाव तरीका है। इस तरह, ज्ञात बग कभी भी गलती से फिर से पेश नहीं किए जाते हैं।
जोनाथन

4
इसे प्रतिगमन परीक्षण कहा जाता है! :)
pfctdayelise

16

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

आइए इसे निर्माता के साथ शुरू करें:

यह दिखाते हुए कि डिजाइन सरल हो जाता है।

अधिक कैसे लिख सकते हैं, चीजों को सरल बना सकते हैं। मुझे अब अधिक मामलों को प्राप्त करने पर नजर रखनी होगी, और अगर आप मुझसे पूछें तो यह अधिक जटिल हो जाता है। मुझे ठोस विवरण दें।

इसे दिखाने से दोषों से बचाव होता है।

मुझे पता है। यही कारण है कि उन्हें परीक्षण कहा जाता है। मेरा कोड अच्छा है, और मैंने इसे मुद्दों के लिए जाँच लिया है, इसलिए मैं नहीं देखता कि वे परीक्षण कहाँ मदद करेंगे।

यह एक अहम् बात कहते हुए कि केवल खराब प्रोग्रामर नहीं हैं।

ओह, तो आपको लगता है कि मैं एक बुरा प्रोग्रामर हूं, क्योंकि मैं उतना परीक्षण नहीं करता हूं। मैं अपमानित हूं और आप पर सकारात्मक रूप से नाराज हूं। मेरे पास कहने के बजाय सहायता और समर्थन होगा।

@ जस्टिन स्टैंडर्ड : नए प्रस्ताव की शुरुआत पर जूनियर व्यक्ति को अपने या किसी अन्य वरिष्ठ प्रोग्रामर के साथ जोड़ा जाता है।

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

@ जस्टिन स्टैंडर्ड : केट रोड्स द्वारा यूनिट टेस्टिंग 101 प्रस्तुति पढ़ें ।

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

मैं अधिक सम्मोहक लेख देखना पसंद करूंगा, और अन्य उपकरण मुझे यह सोचने में सहायता करेंगे कि यह चीजों को करने का सही तरीका है।

@ डोमिनिक कॉनी : कुछ समय बिताएं और परीक्षण तकनीक साझा करें।

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

@ डोमिनिक कॉनी : सवालों के जवाब, उदाहरण और किताबें।

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

@ एडम हायले : सरप्राइज़ रिव्यू।

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

@ Rytmis : आइटम केवल तभी किए जाते हैं जब उनके पास परीक्षण के मामले हों।

ओह, दिलचस्प है। मुझे लगता है कि मुझे वास्तव में अब ऐसा करना है, अन्यथा मैं कुछ भी पूरा नहीं कर रहा हूं। यह समझ में आता है।

@ jmorris : छुटकारा पाएं / बलिदान

चकाचौंध, चकाचौंध, चकाचौंध - एक मौका है जो मैं सीख सकता हूं, और समर्थन और सहायता के साथ, मैं टीमों का एक बहुत ही महत्वपूर्ण और कार्यात्मक हिस्सा बन सकता हूं। यह अब मेरे बाधा में से एक है, लेकिन यह लंबे समय तक नहीं रहेगा। हालांकि, अगर मुझे यह नहीं मिलता है, तो मैं समझता हूं कि मैं जाऊंगा। मुझे लगता है कि मुझे मिल जाएगा।


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

रीजनिंग, तैयारी, टीचिंग, फॉलो अप, सपोर्ट।


12

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

लक्ष्य, तब, किसी तरह उन्हें यह समझने के लिए होना चाहिए कि परीक्षण वास्तव में मापने का एकमात्र तरीका है जब कुछ "किया जाता है", और इस प्रकार उन्हें परीक्षण लिखने के लिए आंतरिक प्रेरणा दें।

मुझे डर है कि यह बहुत कठिन है, हालांकि यह होना चाहिए। आप "मैं वास्तव में जल्दबाज़ी में हूँ," की तर्ज पर बहुत सारे बहाने सुनूँगा, मैं इसे बाद में दोबारा लिखूंगा / करूँगा और फिर परीक्षण जोड़ूँगा "- और निश्चित रूप से, फॉलोअप कभी नहीं होता, क्योंकि आश्चर्यजनक रूप से, वे ' अगले सप्ताह के रूप में व्यस्त हैं


9

यहाँ मैं क्या करूँगा:

  • पहली बार ... "हम संयुक्त रूप से इस परियोजना को करने जा रहे हैं। मैं परीक्षण लिखने जा रहा हूं और आप कोड लिखने जा रहे हैं। मैं परीक्षण कैसे लिखता हूं, इस पर ध्यान दें, कि हम कैसे काम करते हैं। इधर-उधर और यही मैं तुमसे उम्मीद करता हूँ। "

  • इसके बाद ... "आप काम कर रहे हैं! महान! पहले उन परीक्षणों को देखें जो आपके विकास को चला रहे हैं। ओह, कोई परीक्षण नहीं। मुझे बताएं कि कब किया गया है और हम आपके कोड को देखकर पुनर्निर्धारित करेंगे। यदि आप '। परीक्षणों की रूपरेखा तैयार करने में मदद की जरूरत है, मुझे बताएं और मैं आपकी मदद करूंगा। "


6

वह पहले से ही ऐसा कर रहा है। वास्तव में। वह अभी इसे लिखते नहीं हैं। आश्वस्त नहीं? उसे मानक विकास चक्र से गुजरते हुए देखें:

  • कोड का एक टुकड़ा लिखें
  • इसे संकलित करें
  • यह देखने के लिए कि वह क्या करता है
  • कोड का अगला भाग लिखें

चरण # 3 परीक्षण है। वह पहले से ही परीक्षण करता है, वह सिर्फ मैन्युअल रूप से करता है। उससे यह सवाल पूछें: "आप कल कैसे जानते हैं कि आज से कोड अभी भी काम करता है?" वह जवाब देगा: "यह कोड की इतनी कम राशि है!"

पूछें: "अगले सप्ताह के बारे में कैसे?"

जब उन्हें कोई जवाब नहीं मिला, तो पूछें: "जब कोई बदलाव कल काम करता है तो आप अपने कार्यक्रम को कैसे बताना चाहेंगे?"

यही कारण है कि स्वचालित इकाई परीक्षण सभी के बारे में है।


5

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

यह परीक्षण के दीर्घकालिक उद्देश्य पर जोर देने के लायक भी हो सकता है: यह सुनिश्चित करना कि कल जो काम किया था वह आज भी काम कर रहा है, और अगले सप्ताह, और अगले महीने। मैं केवल यह कहता हूं कि क्योंकि मैंने जो उल्लेख किया था, उन उत्तरों को संक्षिप्त करने में नहीं।

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

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

संपादित करें: [ जस्टिन मानक ]

अपने आप को नीचे मत रखो, आपको जो कहना है वह बहुत सही है।

कोड समीक्षाओं के बारे में आपके बिंदु पर: आपको जो मिलेगा वह यह है कि न केवल जूनियर देव प्रक्रिया में सीखेंगे, बल्कि समीक्षक भी ऐसा करेंगे। एक कोड समीक्षा में हर कोई सीखता है कि क्या आप इसे एक सहयोगी प्रक्रिया बनाते हैं।


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

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

4

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

मैं मान रहा हूँ कि वह भी एक नया किराया है (<1 वर्ष) और शायद हाल ही में स्कूल से बाहर है ... जिस स्थिति में वह किसी कॉर्पोरेट सेटिंग में काम करने के लिए आदी नहीं हो सकता है। इस तरह की चीजें हममें से अधिकांश कॉलेज में दूर कर सकते हैं।

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

मुझे पता है, आप ऐसा करने से दूर रहना चाह सकते हैं क्योंकि यह आधिकारिक नहीं है ... लेकिन मुझे लगता है कि आप ऐसा करने के कारण हैं और यह संभवत: उसे आग लगाने और किसी की भर्ती करने की तुलना में पूरी तरह से सस्ता होगा।


3

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

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

मैं भाग्यशाली था कि मैं एक दयालु और बहुत धैर्यवान वरिष्ठ प्रोग्रामर की देखरेख में था । मेरे लिए सौभाग्य से, उन्होंने मेरे साथ बैठने और 1-2 सप्ताह मेरे बेहद हैक किए गए कोडहोर कोड से गुजरने का फैसला किया। वह समझाएगा कि मैं कहाँ गलत हो गया था, सी और पॉइंटर्स (लड़के ने मुझे भ्रमित किया था!) ​​के बारीक बिंदु। हम लगभग एक सप्ताह में एक सुंदर सभ्य वर्ग / मॉड्यूल लिखने में कामयाब रहे। मैं बस इतना कह सकता हूं कि अगर वरिष्ठ देव ने सही रास्ते पर आने में मेरी मदद करने के लिए समय का निवेश नहीं किया होता, तो मैं शायद बहुत लंबे समय तक नहीं टिकता।

खुशी से, रेखा से 2 साल नीचे, मुझे उम्मीद है कि मेरे कुछ कॉलेजियम मुझे एक औसत प्रोग्रामर भी मान सकते हैं।

घर के अंक ले लो

  1. अधिकांश विश्वविद्यालय वास्तविक दुनिया के लिए छात्रों को तैयार करने में बहुत खराब हैं
  2. जोड़ीदार प्रोग्रामिंग ने वास्तव में मेरी मदद की। यह कहने के लिए नहीं कि यह सभी की मदद करेगा लेकिन इसने मेरे लिए काम किया।

3

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

कौन जानता है, वे उन तकनीकों के साथ भी बेहतर हो सकते हैं जो आपकी टीम वर्तमान में उपयोग करती है।


2

यदि जूनियर प्रोग्रामर, या कोई भी, परीक्षण में मूल्य नहीं देखता है, तो उन्हें ऐसा करने के लिए प्राप्त करना कठिन होगा ... अवधि।

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

अंत में, आपकी सभी मदद, प्रोत्साहन, सलाह के बावजूद, वह आपकी टीम के लिए फिट नहीं हो सकता है, इसलिए उसे जाने दें और किसी ऐसे व्यक्ति की तलाश करें जो उसे मिलता है।


2

मैं कोड की समीक्षा करने के बारे में RodeoClown की हर टिप्पणी की समीक्षा करता हूं। एक बार जब वह ऐसा कर लेता है तो उसे कुछ समय के लिए सामान की जांच करने की आदत पड़ जाती है।

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

ध्यान दें: यदि आप ऐसा करने की योजना बनाते हैं, तो आप वास्तव में वज्र रंग-डिफरेंस्ड एडन चाहते हैं ।

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

आप लोगों को समय-समय पर यह कहने की आदत से प्रोत्साहित करने में मदद कर सकते हैं कि "अरे, बॉब, क्या आपने देखा है कि मैंने आज सुबह किया, मुझे यह साफ-सुथरी चाल मिली, जहां आप ब्ला ब्ला कर सकते हैं जो भी हो, पढ़ें और देखें यह काम किस प्रकार करता है!"

NB: हमारे पास 2 'वरिष्ठ' देवता और 3 कनिष्ठ हैं। यह पैमाने पर नहीं हो सकता है, या आपको अधिक डेवलपर्स के साथ प्रक्रिया को थोड़ा समायोजित करने की आवश्यकता हो सकती है।


2
  1. कोड कवरेज को समीक्षाओं का हिस्सा बनाएं।
  2. "एक परीक्षण लिखें जो बग को उजागर करता है" बग को ठीक करने के लिए एक शर्त।
  3. कोड की जाँच करने से पहले एक निश्चित स्तर की कवरेज की आवश्यकता होती है।
  4. परीक्षण-संचालित विकास पर एक अच्छी पुस्तक ढूंढें और यह दिखाने के लिए उपयोग करें कि परीक्षण-विकास को कैसे गति दे सकता है।

2

मनोविज्ञान के बहुत सारे और सहायक "मेंटरिंग" तकनीक लेकिन, सभी ईमानदारी से, यह सिर्फ "टेस्ट लिखने के लिए उबालता है यदि आप अभी भी नौकरी करना चाहते हैं, तो कल।"

आप इसे उपयुक्त, कठोर या नरम समझ सकते हैं। लेकिन तथ्य यह है, प्रोग्रामर को केवल एक साथ कोड को फेंकने और इसे चेक करने के लिए भुगतान नहीं किया जाता है - वे ध्यान से एक साथ कोड डालने के लिए भुगतान किए जाते हैं, फिर एक साथ परीक्षण करते हैं, फिर उनके कोड का परीक्षण करते हैं, फिर पूरी चीज की जांच करते हैं (कम से कम) आपके विवरण से ऐसा लगता है।)

इसलिए, यदि कोई अपना काम करने से इंकार कर रहा है, तो उन्हें समझाएं कि वे कल, घर पर रह सकते हैं, और आप किसी ऐसे व्यक्ति को काम पर रखेंगे, जो नौकरी करेगा।

फिर, आप यह सब धीरे से कर सकते हैं, अगर आपको लगता है कि यह आवश्यक है, लेकिन बहुत सारे लोगों को बस लाइफ इन द रियल वर्ल्ड के एक बड़े कठिन थप्पड़ की आवश्यकता है , और आप उन्हें इसे देने के लिए एक एहसान कर रहे हैं।

सौभाग्य।


2

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

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

संपादित करें> सॉफ़्टवेयर की आवश्यकताओं का अर्थ है कि वह कोड को जानबूझकर तोड़ने के लिए परीक्षण नहीं लिख रहा है जब कोड का कभी इरादा नहीं था या उस परीक्षण मामले को ध्यान में रखने की आवश्यकता नहीं थी।


1

यदि आपके सहकर्मी के पास अनुभव लेखन परीक्षण का अभाव है, तो हो सकता है कि उसे साधारण स्थितियों से परे परीक्षण करने में कठिनाई हो रही हो, और वह खुद को अपर्याप्त परीक्षण के रूप में प्रकट कर रहा हो। यहाँ मैं कोशिश करूँगा:

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

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

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


1

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

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

वह / वह केवल उतना ही अच्छा होगा जितना आप सिखाते हैं। यदि वे "जस्ट गेट इट" करने में सक्षम थे, तो क्या आपको लगता है कि उन्होंने पहले स्थान पर कोई जूनियर स्थान लिया होगा?

मेरे अनुभव में जूनियर्स को काम पर रखा गया है और सीनियर्स के रूप में लगभग एक ही जिम्मेदारी दी गई है, लेकिन उन्हें कम भुगतान किया जाता है और फिर जब वे लड़खड़ाने लगते हैं तो उन्हें अनदेखा कर दिया जाता है। मुझे माफ कर दो अगर मैं कड़वा लगता हूं, तो यह 'कारण' है।


1

@ जसमोरिस

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

मैंने जवाब दिया और टीम के साथ cc'd: "मुझे अब एक महीने के लिए आप में निराशा हुई है। मुझे टीम से कभी मदद नहीं मिली। अगर आपको मेरी जरूरत है तो मैं सड़क के किनारे कॉफी शॉप में रहूंगा।" क्षमा करें, मैं 12 पैरामीटर, 800 लाइन विधि को डिबग नहीं कर सका जो कि सब कुछ के बारे में निर्भर है। "

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

"तो आपकी छोड़ने की?"


1

अपने स्रोत भंडार पर: प्रत्येक कमिट से पहले हुक का उपयोग करें (उदाहरण के लिए SVN के लिए पूर्व-प्रतिबद्ध हुक)

उस हुक में, प्रत्येक विधि के लिए कम से कम एक उपयोग के मामले की मौजूदगी की जाँच करें। इकाई परीक्षण संगठन के लिए एक सम्मेलन का उपयोग करें जिसे आप आसानी से पूर्व-प्रतिबद्ध हुक के माध्यम से लागू कर सकते हैं।

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

किसी परियोजना पर केवल स्वचालित जाँच ही अच्छी हो सकती है। आप हाथ से सब कुछ नहीं देख सकते।

डेवलपर के पास यह जांचने के लिए एक साधन होना चाहिए कि क्या उसके परीक्षण के मामले 100% कोड को कवर करते हैं। इस तरह, यदि वह 100% परीक्षण कोड नहीं करता है, तो यह उसकी अपनी गलती है, न कि "उफ़, माफ करना, मैं भूल गया"।

याद रखें: लोग कभी भी वह नहीं करते हैं जिसकी आप उम्मीद करते हैं, वे हमेशा वही करते हैं जो आप निरीक्षण करते हैं।


1

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

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

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

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

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

थोड़ा कम तामसिक दृष्टिकोण इस व्यक्ति को वह करने देगा जो वे अच्छे हैं (मैं मान रहा हूं कि इस व्यक्ति को काम पर रखा गया है क्योंकि वे वास्तव में नौकरी के प्रोग्रामिंग भाग में सक्षम हैं), और परीक्षण करने के लिए एक परीक्षक या दो को काम पर रखें ( विश्वविद्यालय के छात्रों के पास अक्सर व्यावहारिक या "सह-ऑप" शब्द होते हैं, एक्सपोज़र को पसंद करेंगे, और सस्ते होंगे)

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

यदि आपका संगठन 6 से छोटा है, या आप एक नई टीम बनाने से दूर नहीं हो सकते, तो मैं युग्मित प्रोग्रामिंग (पीपी) की सलाह देता हूं। मैं सभी चरम प्रोग्रामिंग तकनीकों का कुल रूपांतरण नहीं हूं, लेकिन मैं निश्चित रूप से युग्मित प्रोग्रामिंग में विश्वास करता हूं। हालाँकि, युग्मित प्रोग्रामिंग टीम के दोनों सदस्यों को समर्पित होना होगा, या यह बस काम नहीं करता है। उन्हें दो नियमों का पालन करना होगा: निरीक्षक को यह समझना होगा कि स्क्रीन पर क्या कोडित किया जा रहा है या उसे यह समझाने के लिए कोडर से पूछना है; कोडर केवल वही कोड कर सकता है जो वह समझा सकता है - नहीं "आप देखेंगे" या "मुझ पर भरोसा करें" या हाथ से लहराते हुए सहन किया जाएगा।

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

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

यदि अन्य सभी विफल हो जाते हैं, तो प्रोग्रामर को एक शपथ जार के समकक्ष होना चाहिए - प्रत्येक बार जब प्रोग्रामर बिल्ड को तोड़ता है, तो उन्हें आपके पसंदीदा () में जाने वाले जार में $ 20, $ 50, $ 100 (जो भी आपके कर्मचारियों के लिए मामूली रूप से दर्दनाक है) को डालना होगा। पंजीकृत!) दान। जब तक वे भुगतान करते हैं, तब तक उन्हें छोड़ दें :)

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


0

यह थोड़ा हृदयहीन हो सकता है, लेकिन जिस तरह से आप इस स्थिति का वर्णन करते हैं, लगता है कि आपको इस आदमी को आग लगाने की ज़रूरत है। या कम से कम यह स्पष्ट करें: घर के विकास प्रथाओं (लेखन परीक्षण सहित) का पालन करने से इनकार करना और छोटी गाड़ी कोड की जांच करना जो अन्य लोगों को साफ करना है, अंततः आपको निकाल दिया जाएगा।


0

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

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

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


0

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

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

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

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