नए टीम के सदस्यों को परियोजना के साथ तारीख तक कैसे प्राप्त करें? [बन्द है]

Question

हम सॉफ्टवेयर टीम (3 डेवलपर्स, 1 टेस्टर सहित) के लिए 1-2 नए इंजीनियरों को नियुक्त करने वाले हैं।

उन्हें टीम में एकीकृत करने के लिए क्या कदम हैं?

मेरे विचार हैं:

• प्रलेखन पढ़ें (कोडिंग मानकों, विकास के तरीकों में दस्तावेज जो हम उपयोग करते हैं)
• मौजूदा कोड पढ़ने के लिए उन्हें प्राप्त करें
• उन्हें कुछ सरल कार्य सौंपें
• अंत में, उन्हें कोड भाग के लिए जिम्मेदार बनाएं

इसके सिवा और क्या कर सकते थे?

---

परियोजना एक चिकित्सा क्षेत्र (अल्ट्रासाउंड प्रणाली) में है, और पहले से ही 5 साल का समय हो रहा है। हमारे पास वार्षिक रिलीज़ हैं, और हम एक रिलीज़ को समाप्त करने वाले हैं, जब हम 1-2 इंजीनियरों को जोड़ना चाहते हैं।

परियोजना रखरखाव चरण में है (विरासत कोड को पुन: सक्रिय करना, और नई सुविधाओं को जोड़ना)। चीजें बहुत ज्यादा शेड्यूल पर हैं (कम या ज्यादा)।

Comments

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

— बेन डीमोट

@BenDeMott: बहुत अच्छी तरह से रखा। मैं और अधिक सहमत नहीं हो सका। यदि आप इसका उत्तर देते हैं, तो मैं इसे कुछ समय के लिए बढ़ा दूंगा (यदि एसई मुझे जाने देगा)।

— मार्जन वेनेमा

2 वोट बंद। यह कैसे रचनात्मक नहीं है?

— जेएफओ

@BenDeMott: आपको उस उत्तर को बनाने की आवश्यकता है :)

— c_maker

मैं जोड़ना चाहूंगा कि यह आपकी परियोजना पर तकनीकी ऋण को मापने का एक अच्छा अवसर है। भाप में उठने में जितना अधिक समय लगता है, उतना ही अधिक तकनीकी ऋण आपको अपनी परियोजना में मिला है।

— अनोन

Answer 1

मेरे कैरियर में बहुत से अलग-अलग कोडबेस पर तेजी से आने के लिए किसी के आने से, यहाँ मैं सुझाव दूंगा:

1. उत्पाद का उपयोग करने से संबंधित गतिविधियों के साथ समय की एक छोटी राशि (शायद एक या दो दिन) खर्च करें ताकि वे उत्पाद के साथ परिचित हो सकें। यह बगों की पुष्टि कर सकता है या क्यूए परीक्षण योजनाओं को निष्पादित कर सकता है या उपयोगकर्ता प्रशिक्षण के माध्यम से जा सकता है।
2. छोटे, स्थानीय बग पर काम करें। यह इंजीनियर को आर्किटेक्चर के बारे में बहुत कुछ सीखने के बिना आवेदन के निर्माण और डिबग करने के तरीके से परिचित कराता है।
3. आदर्श रूप में, एक छोटी सी नई सुविधा लिखें जो स्थानीयकृत हो। इससे उन्हें कोड का एक हिस्सा लिखने की सुविधा मिलती है और जैसा कि वे लिखते हैं कि वे कोड के आसपास के बिट्स से परिचित हो जाएंगे जिनके साथ उनके नए कोड को काम करने की आवश्यकता है।

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

मैं केवल कार्य (प्रलेखन या कोड) पढ़ने से बचूंगा। पढ़ना प्रलेखन वास्तव में तेजी से उबाऊ हो जाता है और यादृच्छिक कोड पढ़ना उपयोगी नहीं है क्योंकि उनके पास काम करने के लिए कोई संदर्भ नहीं होगा। जब आप उत्पाद और कोडबेस को पहले से जानते हैं तो कोड समीक्षाओं के लिए कोड पढ़ना काफी कठिन है। मैं बस कोड को पढ़ने के लिए एक नया इंजीनियर होने से उपयोगी कुछ भी नहीं देख सकता।

Comments

+1, पहले कुछ समय बिताने पर उन्हें AS USER के उत्पाद के रूप में जाना जाता है। यह आश्चर्यजनक है कि अंतिम-उपयोगकर्ता के दृष्टिकोण से कितना बड़ा-चित्र दृश्य डेवलपर्स को मूल बातें समझने में मदद कर सकता है कि वे क्या काम करने जा रहे हैं।

— एंजेलो

Answer 2

मेरी भावना यह है कि दस्तावेज़ीकरण पढ़ने के लिए ज्यादातर लोगों की सहनशीलता काफी कम है (एक या दो दिन के लिए अच्छा है, लेकिन इससे परे वे शायद कुछ ज्यादा ही हाथ से कुछ करने के लिए खुजली करेंगे)।

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

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

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

Answer 3

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

Answer 4

मैं केवल 10 महीनों के लिए उद्योग में काम कर रहा हूं (प्लेसमेंट पर) लेकिन मैंने पाया कि निम्नलिखित ने मेरी मदद की:

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

उन दोनों ने मेरी काफी मदद की। सौभाग्य।

Answer 5

मैं उच्च स्तर से निम्न स्तर पर जाऊंगा।

जितनी जल्दी हो सके एप्लिकेशन को डेमो करें

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

उच्च स्तरीय वास्तुकला की व्याख्या कीजिए

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

एक बेहतरीन ऑन-बोर्डिंग दस्तावेज तैयार रखें

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

उसे सवाल पूछने के लिए प्रोत्साहित करें (और उन्हें जवाब देने के लिए उपलब्ध रहें)

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

टीम के अन्य सदस्यों को नवागंतुक का स्वागत करने में मदद करें

सिक्के के दो पहलू होते हैं जब कोई टीम में शामिल होता है। टीम के पास नए डेवलपर के स्वागत के लिए भी उपकरण होने चाहिए।

उन्हें एक या दो काम करने दें

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

एक बार जब वे अधिक से अधिक आरामदायक महसूस करते हैं, तो उन्हें कठिन कार्यों में शामिल होने के लिए प्रोत्साहित करें

अच्छे उम्मीदवार स्वाभाविक रूप से ऐसा करेंगे।

Answer 6

एक "अभिविन्यास" प्रवाह जिसे मैं (और उपयोगी पाया गया है) कुछ इस प्रकार था:

1. एक संक्षिप्त प्रस्तुति "बिग पिक्चर" दे रही है कि घटक क्या हैं, कैसे फिट हैं और सामान्य वास्तुकला।
2. कोड का अवलोकन, उन कार्यों को परिचय देता है जो मुझे सौंपे गए घटक के लिए मुख्य तर्क को संभालते हैं। कोडिंग परंपराओं और शैली से संबंधित कुछ सामान को कवर किया।
3. खुले मुद्दों और कम प्राथमिकता वाले बगों का एक गुच्छा सौंपा गया था (जो मोटे तौर पर मुझे सौंपे गए घटक के लिए स्थानीय थे और काफी सरल थे)।
4. मुझे एप्लिकेशन के माध्यम से डिबग करने और सामान के साथ मदद मांगने की उम्मीद थी जिसे मैं समझ नहीं सका।
5. फिक्स किए जाने के बाद, मुझे एकीकरण जारी करने की प्रक्रिया (कोड-समीक्षा, देव-स्तरीय परीक्षण आदि) के माध्यम से चलाया गया।
6. बचे हुए कार्यों / बगों के लिए दोहराएँ।

मुझे लगता है कि यह दृष्टिकोण (और इसके रूपांतर) उपयोगी होंगे क्योंकि:

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

Answer 7

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

Answer 8

मैं इसी तरह चलता हूं

1. उन्हें कुछ कार्य दें जो प्रोजेक्ट से संबंधित हैं। (जैसे: यदि आपका प्रोजेक्ट डेटाबेस एप्लिकेशन है, तो उन्हें डेटाबेस से जुड़ने के लिए एप्लिकेशन बनाने और कुछ सरल ऑपरेशन करने के लिए कहें।)
2. जब आप पाते हैं कि वे काम करने के विचार को समझ गए हैं, तो उन्हें प्रोजेक्ट का डेमो दें
3. उन्हें प्रलेखन पढ़ने के लिए कहें।
4. उन्हें कोडिंग शैलियों और मानकों से परिचित कराएं
5. बाद में उन्हें कुछ डिबगिंग अभ्यास (परियोजना के प्रवाह को जानने के लिए) दें।
6. उन्हें एक बिंदु तय करने के लिए कहें जो आपने पहले ही तय कर लिया है (बस इसके साथ उनके तर्क का पता लगाने के लिए)।
7. अंत में उन्हें प्रोजेक्ट का हिस्सा बनाएं।

याद रखें: कोई फर्क नहीं पड़ता कि आप कितना प्रयास करते हैं, जब तक और जब तक कि जोइन परियोजना को पूरी तरह से नहीं समझ लेता है, तब तक आप उससे कुशलतापूर्वक काम करवा सकते हैं।

Answer 9

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

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

Answer 10

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

इसके अतिरिक्त, आप कुछ मूल्यांकन केंद्र शैली के कार्यों की कोशिश करके टीम पर पहले से ही अन्य लोगों के साथ उन्हें एकीकृत करने की कोशिश कर सकते हैं जैसे कि एक कॉफी कप का समर्थन करने वाले कागज की 4 शीट से 45 मिनट में एक पुल का निर्माण करना। हम इस तकनीक का उपयोग सॉफ्टवेयर इंजीनियरिंग में एक व्यावहारिक पाठ्यक्रम में 3 सप्ताह के लिए एकल परियोजना पर काम करने से पहले 8 छात्रों के समूह को बर्फ तोड़ने के लिए करते हैं। यह चरण बनाने वाली टीम को गति देने में मदद करता है।

Answer 11

1) उन्हें अपने कोड नियमों और दिशानिर्देशों का स्पष्टीकरण दें। अपने आवेदन कैसे काम करता है और सामान्य कोड संरचना की एक सामान्य व्याख्या भी दें।

2) कुछ छोटे कीड़े या परियोजनाएं खोजें जो बड़े पैमाने पर अन्य कोड से स्वतंत्र हैं। समझाएँ कि क्या करना है, कहाँ कोड में और नियमित रूप से उन पर जाँच करें।

3) धीरे-धीरे उन्हें कम और कम जाँचते हुए बड़े और बड़े प्रोजेक्ट देना शुरू करें।

4) समय-समय पर उनके बगल में बैठें। आप सिर्फ यह देखकर बहुत कुछ सीख सकते हैं कि कोई और समस्या से कैसे निपटता है। छोटी चीजें जैसे "ओह, आप अपने कोड में फ़ंक्शन ctrl-" के लिए देख सकते हैं। बहुत उपयोगी हैं।

अब, मैंने पाया है कि दो चरम सीमाएं हैं :

• कोई जो हर पांच मिनट में एक सवाल पूछता है। "यह क्या करता है। क्या करें?"। उन्हें उत्तर के लिए पहले Google चाहिए और केवल तभी आपके पास आना चाहिए जब वे उत्तर नहीं पा सकते हैं।

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

Answer 12

ये मेरे सूत्र थे और कई नए कामर्स के साथ उपयोग किए गए - ये कदम अत्यधिक प्रभावी साबित हुए।

a) सभी नए डेवलपर्स को 2 दिनों के लिए परियोजना की आवश्यकताओं और विकास प्रक्रियाओं के बारे में कुछ परिचय दिया जाएगा।

b) कोड के लिए जुनिट परीक्षण लिखने के 3 सप्ताह के कार्य को सौंपना जिसमें पर्याप्त कवरेज नहीं है।

c) एक बार 3 हो जाने के बाद, छोटे कार्य असाइन करें

घ) जटिल कार्यों को पूरा करना और किया जाना।

Comments

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

— c_maker

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

— java_mouse

Answer 13

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

आपको एक वरिष्ठ डेवलपर भी सौंपना चाहिए, अधिमानतः प्रति नया डेवलपर जो उम्मीदवार को मदद कर सकता है।

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

Answer 14

केवल अच्छी प्रथाओं और कोडिंग के मानकों की व्याख्या न करें, लेकिन समझाएं कि पढ़ा हुआ कोड कैसे संरचित है। बताएं कि सॉफ्टवेयर क्या करना है और यह कैसे हासिल किया जाएगा।

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