2010-05-12 9 views
19

कहें कि यह 10 लोगों की परियोजना है, तो मूल प्रोग्रामर के 2-3 छोड़ने के बाद परियोजना को थोड़ी देर के लिए एक स्थिर संस्करण जारी किया गया है। कोड इस मामले में कैसे बनाए रखने योग्य है?मूल प्रोग्रामर को छोड़ने के बाद कोड को बनाए रखने के लिए कैसे रखें

प्रोजेक्ट रिलीज संस्करण के बाद मेरी कल्पना कोड की समीक्षा कर रही है और बाद में इसकी समीक्षा जारी रखती है? शायद 2-3 छोटे समूहों में विभाजित हो और प्रत्येक समूह कोड के भाग की समीक्षा कर सके। तो कम से कम 3-4 लोग कोड के हिस्से से परिचित हैं। क्या यह काम करता है? कंपनियां इस मुद्दे से कैसे निपटती हैं?

आमतौर पर कोड की समीक्षा करने में कितने प्रतिशत खर्च किए गए? कृपया सलाह दें, समुदाय के लिए धन्यवाद।

+2

आप किस समस्या को हल करने की कोशिश कर रहे हैं? – Anonymoose

+0

सभी वोट देखें! – zaf

+1

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

उत्तर

25

प्रोग्रामर छोड़ने से पहले आप कोड को बनाए रखने योग्य बनाते हैं। कोडिंग मानकों को परिभाषित करें, अच्छी कोड लिखें, अच्छी टिप्पणियां लिखें, और निश्चित रूप से, कोड की समीक्षा अक्सर

+2

+1 में पूरी तरह से सही है – faya

+5

हे, मुझे यकीन है कि स्टेन इस सलाह को पसंद करेंगे! – richq

7

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

+3

.. "प्रोग्रामर पत्तियों से पहले" -> "कोड लिखने से पहले";) – Juri

+0

हां बिल्कुल। ;-) – khmarbaise

+0

या लगभग उतना ही अच्छा, कोड –

4

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

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

+0

पर लिखने के साथ-साथ परीक्षण लिखें, वास्तव में, उन ब्लॉग पोस्ट, वह * अपने बस कारक को कम करने की कोशिश कर रहा है। ;) –

+0

@ निक, अच्छा बिंदु। आम तौर पर "बस कारक" उन डेवलपर्स की संख्या है जिन्हें परियोजना को पतन के बिना बस द्वारा मारा जा सकता है, लेकिन लेख में मैंने लिंक किया है, वे इसे पीछे की ओर उपयोग करते हैं। –

2

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

2

मौजूदा कोड को पढ़ने के लिए अपने शेष प्रोग्रामर को सिखाते हुए समस्या यह है कि, क्या उन्हें हिरण चरागाहों पर जाने का फैसला करना चाहिए, आप एक बार फिर स्क्वायर वन पर वापस आ सकते हैं।

तुम सिर्फ अपने कार्यकर्ताओं जानने के लिए कैसे अलग कोडर के काम (जो अद्वितीय और विदेशी भाषाओं को पढ़ने की तरह हो सकता है) को पढ़ने के लिए होने के साथ अधिक से अधिक समय बर्बाद कर खत्म ...

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

0

यदि आपके पास स्थिर निर्माण है तो आप किस बारे में चिंतित हैं। कोड स्रोत नियंत्रण के तहत रखा जा सकता है। मूल प्रोग्रामर छोड़ने से पहले आप उनसे नए संसाधनों में पूर्ण ज्ञान हस्तांतरण लेते थे। या यह अनियोजित था।

वैसे भी जब तक आपके पास उन संबंधित कोड में ठीक करने के लिए बग नहीं है, मुझे नहीं लगता कि चिंता करने की कोई बात नहीं है।

1

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

एक और लाभ यह इकाई परीक्षण जीवन के लिए कर रहे हैं वे अपने कोड का परीक्षण के साथ कंपनी :)

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

3

अन्य लोगों की तरह कहा, यह वास्तव में जरूरी है कि कोड पोषणीय है पहले प्रोग्रामर छोड़ दें। मैं अन्य सभी पदों को दोहराना नहीं चाहूंगा क्योंकि वे सभी सत्य हैं और सभी महत्वपूर्ण चीजों का जिक्र करते हैं।

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

हाँ, मुझे पता है कि यह बहुत है काम। लेकिन यह एक बार किया जाने पर जानकारी का एक बड़ा स्रोत है।

सादर, जनवरी

2

आप, प्रलेखन लेखन इकाई परीक्षण का निर्माण शुरू और javadocs प्रकाशित करने के लिए किया है।

संबंधित मुद्दे