आप अपनी टीम द्वारा लिखी गई कक्षाओं और कार्यों को कैसे ट्रैक करते हैं?


43

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

क्या इस प्रकार की चीजों के दस्तावेजीकरण का कोई विशेष अभ्यास है? आप उन्हें खोजने में आसान कैसे बनाते हैं?

यदि आपकी टीम के पास ऐसा कोई दस्तावेज नहीं है, तो आपको यह कैसे पता चलेगा कि आपका पहिया पहले से मौजूद है?

संपादित करें:

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

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

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

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

क्या इस नस में कोई और विचार हैं ... अलग-थलग और समय-समय पर डेवलपर्स के लिए?


5
मैं बड़े पैमाने पर पूछने के लिए प्रश्न का विस्तार करूंगा, शायद 100+ कर्मचारियों की कंपनी में आप कैसे करते हैं। पहले से किए गए कार्यों के दोहराव से बचने के लिए कौन से सर्वोत्तम अभ्यास किए जा सकते हैं?
आसफ

1
@Asaf - मुझे संदेह है कि सही उत्तर जनसंख्या के आकार पर निर्भर करेगा - 5 व्यक्ति की दुकान के लिए क्या काम 50 के लिए काम नहीं करेगा, और 50 के लिए क्या काम करता है 500 के लिए काम नहीं करेगा। सभी का जवाब स्वागत होगा।
डैन पिचेलमैन

3
यह एक बड़ा सवाल है!
रॉकलन

4
कॉनवे का नियम : "जो संगठन सिस्टम डिज़ाइन करते हैं ... वे डिज़ाइन तैयार करने के लिए विवश होते हैं जो इन संगठनों की संचार संरचनाओं की प्रतियां हैं"।
बजे मार्क रुशकोफ

2
@nathanhayfield: यह एक समाधान है जो 1 देव के लिए काम कर सकता है, और 2 के लिए कुछ हद तक, लेकिन 20 या 100 के लिए नहीं। और यहां तक ​​कि जब मैं अकेले काम करता हूं, तो मैं सहायक कार्यों को अलग करना पसंद करता हूं।
डॉक्टर ब्राउन

जवाबों:


29

पुस्तकालय। फ़्रेमवर्क। संस्करण नियंत्रण।

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

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


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

2
मुझे लगा कि तकनीकी शब्द बीबीओएम है
zzzzBov

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

3
@ कालेब: शांत रहो, मेरी पोस्टिंग पूरी तरह से पढ़ो। मेरा कहना है: कोड को कहीं और से कॉपी करना, इसे ट्वीक करना और इसे एक टीम लाइब्रेरी में एकीकृत करना जरूरी नहीं कि आपको "सड़न के रास्ते पर" लाएगा। जब आपके पास ओवरलैपिंग कार्यक्षमता के साथ दो काम होते हैं, और दो टीमों जिसमें से प्रत्येक अपने दायित्व को बनाए रखने के लिए जिम्मेदार होता है, तो स्थिति इतनी खराब नहीं होती है। यह सही नहीं है, क्योंकि एक टीम कुछ काम कर सकती है, दूसरा काम भी करती है, लेकिन कभी-कभी इसका फायदा यह होता है कि वे टीमें स्वतंत्र रूप से डबल वर्क आउट करती रहती हैं।
डॉक्टर ब्राउन

1
@DocBrown वहाँ रहे हैं लेकिन, जिसमें यह कोड कॉपी करने के लिए आवश्यक हो जाता है स्थितियों, कि एक सोचा-समझा फैसला है और कुछ है कि आप जिस तरह से कोड पहली जगह में साझा किया गया था की वजह से करने को मजबूर कर रहे हैं होना चाहिए।
कालेब

13

इसके लिए एक दृष्टिकोण उस उद्देश्य के लिए एक विकी स्थापित कर रहा है, और आपके पास कौन से पुन: प्रयोज्य घटक हैं, आपने किसी समस्या को कैसे हल किया आदि पर कुछ उच्च-स्तरीय डॉक्स लिखें।

कठिन हिस्सा यह है कि आपकी टीम में हर एक उस विकी को लगातार बनाए रखे। लेकिन किसी भी अन्य प्रकार के प्रलेखन एक ही समस्या से ग्रस्त हैं।

आपका कुछ कोड पुन: प्रयोज्य पुस्तकालय में डालने के लिए पर्याप्त हो सकता है। इससे बाद में कोड को फिर से खोजना भी आसान हो जाता है।


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

@ कालेब का संचार कठिन भाग है
jk।

@jk - अगर आपके पास C
JeffO

3
@ कालेब: ओपी का प्रश्न कोड को प्रसारित करने के बारे में नहीं था, यह सवाल बाद में संवाद करने और उसे खोजने के बारे में था।
डॉक्टर ब्राउन 19

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

7

700 कर्मचारियों वाली एक कंपनी में होने के नाते, 2 और 20 लोगों के बीच अलग-अलग टीमों में, यहाँ मेरा अनुभव है।

टीम के स्तर पर

हमारे पास लगभग 15-20 मिनट तक रोज़ "स्टैंडअप मीटिंग" होती है। हम जल्दी से सामान्य ज्ञान साझा कर सकते हैं जैसे "मैंने यह कार्य कल किया था, यह इतना कठिन है"।

हमारे पास प्रति प्रोजेक्ट एक विकी भी है। जिसका अर्थ है कि हम इस परियोजना के बारे में जानकारी (तकनीकी) साझा कर सकते हैं, जिसमें कस्टम कक्षाएं / फ़ंक्शन शामिल हैं जो अंतर्निहित थे।

एजेंसी के स्तर पर

एजेंसी स्तर पर, हमारे पास 4 उपकरण हैं:

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

कंपनी के स्तर पर

कंपनी के स्तर पर, यह अधिक संगठित है।

"एजेंसी स्तर" विकि वास्तव में कंपनी की विकि का हिस्सा है।

और फिर विकी को प्रौद्योगिकियों के आधार पर विभाजित किया जाता है। इस प्रकार, कोई भी इसे सुधार सकता है, इसके माध्यम से खोज कर सकता है, और मूल रूप से विकि को एक जीवन दे सकता है।

उपलब्ध मेलिंग सूचियाँ भी हैं जिन पर हम सदस्यता ले सकते हैं। एजेंसी में कोई भी सदस्यता ले सकता है, और अधिकांश लोग कम से कम एक या दो तकनीकों का पालन करते हैं, वास्तव में अधिकांश लोग उनमें से 5-10 का अनुसरण करते हैं।

और VCS बेशक सबसे अच्छा कोड शेयरिंग सिस्टम है।

निष्कर्ष

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


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

6

खैर, यह सब संचार के लिए नीचे आता है।

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

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

यदि ऐसा कुछ नहीं किया जा रहा है, तो इसे अपने बॉस के साथ लाएं, समझाएं कि इससे कंपनी को क्या फायदा होगा और आगे का रास्ता सुझाएगा :)


1
मैं आपके उत्तर में "आम" अवधारणा को थोड़ा आगे बढ़ाऊंगा।
जेएफओ

4

कोड समीक्षा सत्र मदद कर सकते हैं। यदि आपकी टीम नियमित रूप से चर्चा करती है कि क्या विकसित हुआ था, तो एक व्यक्ति जो एक समाधान के साथ आया था, वह दूसरों को दिखा सकता है कि इसका उपयोग कैसे किया जाए। यदि कोई ऐसा बिंदु उठाता है जिस पर वे चिपके रहते हैं, तो टीम के अन्य सदस्य एक दृष्टिकोण का प्रस्ताव रख सकते हैं जो मौजूदा घटकों के पुन: उपयोग को बढ़ाता है।


1
फिर 4 साल और 600 कार्य बाद में जब आप याद रखना चाहते हैं कि एक फ़ंक्शन जो कुछ समय के लिए बनाया गया था? ओपी की समस्या का एक हिस्सा उन सभी चीजों को याद रखने की कोशिश कर रहा था जो बनाई गई थीं, जबकि यह शुरुआत में अच्छी है, शायद यह एक महीने या दो महीने तक नहीं
रहेगी

2

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


0

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

TL; DR: हर चेकइन के लिए कोड समीक्षाएँ।


2
नहीं मिलता है। क्या आप परीक्षण और काम करने वाले कोड को सिर्फ इसलिए फेंक देंगे क्योंकि यह कोड समीक्षा में एक डुप्लिकेट की तरह दिखता है? सवाल यह था कि पहली बार में डुप्लिकेट कोड लिखने से कैसे बचें। @ डेनेथ का उत्तर जैसा सत्र बेहतर लगता है।
एड्रिनम

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