भविष्य में वन मैन प्रोजेक्ट से टीम प्रोजेक्ट की ओर बढ़ना। मुझे अब तैयारी में क्या करना चाहिए और क्या इंतजार कर सकता हूं?

Question

यह जानने में मेरी दिलचस्पी है कि एक आदमी प्रोजेक्ट (टीम सोर्स कंट्रोल, डॉक्यूमेंटेशन, बिल्ड वगैरह) के बारे में आप लोगों को क्या लगता है कि आपको क्या करना है। परियोजना पर।

इस परिदृश्य के माध्यम से आगे बढ़ने के किसी भी अनुभव के साथ, उनकी अंतर्दृष्टि की सराहना की जाएगी।

Comments

क्या आप कह रहे हैं कि आपके पास अब संस्करण नियंत्रण नहीं है? क्या आप अपनी वर्तमान परियोजना अवसंरचना का वर्णन कर सकते हैं? आप किस सहायक उपकरण और दस्तावेज़ का उपयोग या निर्माण कर रहे हैं?

— थॉमस ओवेन्स

कोई संस्करण नियंत्रण नहीं। वर्तमान स्रोत आईडीई परियोजना के हिस्से के रूप में बनाए रखा गया है। सभी प्रोजेक्ट कलाकृतियों के नियमित, मैनुअल बैक-अप। तकनीकी घटकों / व्यावसायिक नियमों पर छिटपुट दस्तावेज। ANT बिल्ड, मैनुअल (FTP) परिनियोजन। इसलिए इस समय बहुत बुनियादी है।

— बजे Dan MacBean

बहुत बुनियादी? कि एक क्म्व्यनी है।

— थॉमस ओवेन्स

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

— Mac पर Dan MacBean

यहां तक ​​कि एक आदमी परियोजनाओं को स्रोत नियंत्रण का उपयोग करना चाहिए। यह एक पेशेवर आदत है जो सभी डेवलपर्स के पास होनी चाहिए। और न; सोर्स कॉन्ट्रोल में सभी डेटाबेस कोड के लिए स्क्रिप्ट जोड़ना भूल जाते हैं। सभी db ऑब्जेक्ट्स shoudl को स्क्रिप्ट के साथ बनाया या बदल दिया जाता है और उन्हें स्रोत नियंत्रण और संस्करण में होना चाहिए ताकि आप उत्पाद के प्रत्येक रिलीज़ के लिए डेटाबेस संरचना के बारे में वास्तव में बता सकें। ।

— HLGEM

Answer 1

मैंने जो सीखा है। (मैंने एक अलग क्रम की कोशिश की। मैं गलत था। यह वह क्रम है जिसमें चीजें प्रासंगिक हो जाती हैं।)

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

2. एक क्यूए / टेस्ट क्षेत्र बनाएं जो आपके व्यक्तिगत "काम" या "विकास" वातावरण से पूरी तरह से अलग हो। कम से कम एक अलग यूजर आई.डी. आदर्श रूप से एक अलग वीएम पर।
   पूरी तरह से अलग। आपके वर्तमान कार्य वातावरण के साथ कोई संभावित ओवरलैप नहीं।

3. अपने काम के माहौल में इकाई परीक्षण से परे परीक्षण बंद करो। कोड और इकाई परीक्षण आप "खुद के रूप में" करते हैं। अन्य सभी परीक्षण (एकीकरण, प्रदर्शन, जो भी हो) आप अलग वीएम पर करते हैं। कभी भी खुद की तरह परीक्षा न करें। हमेशा एक अलग क्यूए उपयोगकर्ता के रूप में परीक्षण करें। आदर्श रूप से एक अलग वीएम पर।

   "मेरे लिए काम करता है," अपनी टीम के सदस्य (ओं) को कहना एक बुरी बात है। बहुत बुरा। आपको यह पता लगाने की आवश्यकता है कि वे क्या गलत कर रहे हैं। एक दिन में कई बार।

4. सब कुछ लिखने की योजना बनाएं। सादा-पाठ मार्कअप टूल (RST या Markdown या कुछ) का उपयोग करें ताकि संस्करण नियंत्रण रिपॉजिटरी में सभी प्रलेखन सादा-पाठ हो। एक टूल HTML पेज (यानी, RST के लिए Docutils) या PDF या जो भी सबसे अच्छा लगता है बना सकता है। मालिकाना दस्तावेज़ प्रारूप (यानी एमएस-वर्ड) का उपयोग न करें। वे कुछ स्रोत-कोड नियंत्रण प्रणालियों के साथ अच्छा नहीं खेल सकते हैं।

5. पहली चीजें जो आपको लिखनी हैं, वे निम्नलिखित हैं।

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

   • यूनिट टेस्ट सूट कैसे चलाएं। फिर। सुनिश्चित करें कि निर्देश काम करते हैं और सोचने की आवश्यकता नहीं है। "यह टाइप करें:" "पुष्टि करें कि:" सामान की तरह। ऐसा नहीं है कि आपकी टीम के सदस्य बेवकूफ हैं। यह है कि आपको याद नहीं है कि आप क्या मान रहे हैं जब तक कि आप इसे नीचे नहीं लिखते।

   • एकीकरण परीक्षण सूट कैसे चलाएं।

   वास्तुकला या डिजाइन सिद्धांतों का वर्णन करने में बहुत समय बर्बाद न करें। आपको पहले किसी को उठने और चलने की आवश्यकता है। आप बाद में सामान समझा सकते हैं।

6. दस्तावेज़ के लिए अगली चीजें उपयोगकर्ता कहानियां हैं। और परीक्षण के मामले जो उन कहानियों का समर्थन करते हैं। और उन उपयोगकर्ता कहानियों का समर्थन करने वाले परीक्षण मामलों के लिए आवश्यक डेटा जुड़नार।

   आप इसे साझा करेंगे। यह सोर्स कोड कंट्रोल के तहत जाता है।

7. आखिरकार, आप अन्य 4 विचारों का दस्तावेज़ कर सकते हैं।

   • तार्किक दृश्य दस्तावेज़ के लिए सहायक सामग्री है। चित्र यहाँ स्वीकार्य हैं। यह तेजी से विकसित होता है, इसलिए विरासत की जानकारी कैप्चर करने में समय व्यतीत न करें। अपनी टीम के सदस्य (सदस्यों) के साथ सहयोग करने का एक तरीका निकालें।

   • प्रक्रिया दृश्य अक्सर सहायक होता है। समग्र आवेदन पर निर्भर करता है कि यह कितना महत्वपूर्ण है।

   • विकास दृश्य - मॉड्यूल, पुस्तकालय, रूपरेखा, आदि - अक्सर अनौपचारिक रूप से वर्णित किया जाता है। एक तस्वीर मदद कर सकती है, लेकिन यह पूरी तरह से इसे पूरा करने के लिए कुख्यात है कि कोई दस्तावेज़ उठा सकता है और उसके सिर या पूंछ बना सकता है। यहां तक ​​कि लंबे समय से स्थापित, बहुत सार्वजनिक परियोजनाओं में पुस्तकालय प्रलेखन है जिसे बस अनदेखा किया जाता है। (ढेर ढेर सवालों के लिए अग्रणी।)

     अनौपचारिक होने के लिए स्वीकार्य होने के अलावा, यह तेजी से बदलता है।

   • तैनाती की जानकारी। सर्वर। आईपी ​​पते। डेटाबेस क्रेडेंशियल। वह सब सामान नीचे लिखा होना चाहिए । अंततः।

Comments

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

— ह्यूगो

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

— S.Lott

Answer 2

उपकरण और कार्यप्रणाली

सफलतापूर्वक सहयोग करने और उत्पादक होने के लिए क्या आवश्यक है?

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

प्रबंधन / टीम वर्क

... या पारस्परिक स्तर पर कुछ और

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

पुस्तक संदर्भ

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

वे पुस्तकें वास्तव में टीमों, संगठनों और प्रोग्रामिंग परियोजनाओं के संबंध में पढ़ने लायक हैं:

• peopleware
• पौराणिक पुरुष मास
• सॉफ्टवेयर एस्टीमेशन, ब्लैक आर्ट डेमिस्टिफाई करना

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

Comments

इस उत्तर को प्रश्न प्रोग्रामर से जोड़ा गया था ।stackexchange.com/ questions/ 121603/… जो लगभग एक वर्ष के बाद स्टैकओवरफ्लो से प्रोग्रामर के लिए माइग्रेट किया गया था और एक भरपूर ... इसलिए यदि उत्तर के कुछ भाग थोड़े से हैं (मूल प्रश्न पूछे गए हैं) पुस्तक संदर्भ के लिए), इसीलिए।

— marapet

Answer 3

मैं अनुभव से बात करूंगा, लेकिन ध्यान रखें कि हर कोई अलग है। ये चीजें सार्वभौमिक नहीं हैं।

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

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

इसके दो तरीके हो सकते हैं - सहकर्मी एक ड्रैग होगा, और आप जो करेंगे या वह करेंगे, या आपमें से दो के कौशल को फिर से जोड़ना होगा, न कि केवल जोड़ना, और आप वास्तव में एक साथ काम करने की सराहना करेंगे।

"स्वच्छ, तेज, पुन: प्रयोज्य कोड" के एक विषय पर - मैं एक साक्षात्कार पर सुझाव देता हूं, एक छोटा माइक्रो-कर्नेल / सेवा प्रबंधक और / या नौकरी निष्पादक लिखने के लिए कहें। देखें कि प्लग करने योग्य घटक कैसे निर्दिष्ट और कॉन्फ़िगर किए गए हैं। समाप्त होने की जरूरत नहीं है, यह एक विचार है जो मायने रखता है। और यह भी कि आप जल्दी से उन लोगों को सीखेंगे जो अच्छी तरह से जानते हैं कि यह कैसे करना चाहते हैं सभ्य पैसा ;-) अच्छी किस्मत!

Comments

+1, "इसे जाने दो" यह पहली बात होगी जो मैं भी बताऊंगा।

— slugster

Answer 4

मेरा लेना: किसी के लिए अपनी आंतरिक परियोजना की वास्तुकला के दस्तावेज़ के साथ शुरू करें ... जो इसके बारे में पता नहीं है। यह समझाने की कोशिश करें कि कौन सी धारणाएँ लागू हैं और कब / कहाँ आपने सामान्य प्रथाओं से हटकर और क्यों।

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

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

Answer 5

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

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

यदि आप ऐसा करने में विफल रहते हैं, तो या तो आप इन कार्यों को हमेशा के लिए करने के लिए जकड़ जाएंगे, या (कुछ) नए आदमी (ओं) को अनिवार्य रूप से जल्दी या बाद में कुछ पेंच होगा।

अन्य महत्वपूर्ण कार्य है, जैसा कि @dimitris ने उल्लेख किया है, प्रलेखन। @S। Lott ने इस पर और अधिक विवरण जोड़ा, इसलिए इसे दोहराने के बजाय सिर्फ +1 उसे :-)

Answer 6

यहाँ कुछ विचार हैं, आंशिक रूप से व्यक्तिगत अनुभव पर आधारित:

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

• नए कर्मचारी को कोड के साथ धीरे-धीरे परिचित करने के लिए नए कर्मचारी को कुछ "एप्लिकेशन लेयर" कार्य या बग फिक्सिंग देते समय, सबसे पहले, एपीआई- / कोर-स्तर कोड पर ध्यान केंद्रित करें। आम तौर पर, आसान , फिर भी सार्थक और इस प्रकार पुरस्कृत कार्यों के साथ शुरू करें ।

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

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

• एक नियंत्रण प्रणाली का उपयोग करें । एक तार्किक स्रोत फ़ाइल लेआउट बनाए रखें और अनुशासन बनाएं ।

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

Answer 7

प्रौद्योगिकी

यदि आप किसी और को डेवलपर के रूप में ला रहे हैं तो तीन महत्वपूर्ण चीजें हैं जो मैं शुरू करने से पहले उठने और चलाने की सलाह दूंगा।

1. स्रोत नियंत्रण
2. मुद्दा ट्रैकिंग
3. लगातार मेल जोल

अगर ये तीन चीजें ठीक से चल रही हैं और आप एक नई टीम के सदस्य को लाने पर होने वाली आम समस्या का लगभग 75% खत्म कर देंगे। प्रौद्योगिकी के इन टुकड़ों की बात यह है कि केवल आपके सिर में क्या हो रहा है, इसका बहुत कुछ लेना है और इसे बाहर निकालना है जहां आपकी टीम का सदस्य इसके साथ बातचीत कर सकता है।

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

व्यावहारिक प्रोग्रामर इस पर कुछ बहुत अच्छी किताबें हैं। यहाँ कुछ मैं सुझाऊंगा। उनके पास अन्य समान शीर्षक हैं जो आप जिस प्रोग्रामिंग भाषा का उपयोग कर रहे हैं या आप किस संस्करण नियंत्रण का उपयोग करना चाहते हैं, उसके आधार पर हैं:

http://www.pragprog.com/tmarks/tpp/the-pragmatic-programmer http://www.pragprog.com/tmarks/tsgit/pragmatic-version-control-use-git http: //www.pragprog। com / खिताब / ऑटो / व्यावहारिक-परियोजना स्वचालन

निजी

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

आप अपने नए भाड़े को उन समस्याओं को हल करने की स्वतंत्रता देना चाहते हैं जो उनके लिए काम करती हैं जबकि सुरक्षा उपायों को ध्यान में रखते हुए आप उन्हें जल्दी पकड़ सकते हैं।

Answer 8

मेरी राय में ये बिंदु सबसे महत्वपूर्ण हैं:

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

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