मैंने कल अपने वर्तमान कार्यस्थल से इस्तीफा दे दिया, और मैं इसे अपने प्रोजेक्ट्स को दस्तावेज करने के लिए खुद पर ले रहा हूं ताकि मैं उन्हें आसानी से सौंप सकूं।किसी कंपनी को छोड़ते समय कोडिंग कोड
इस बात को ध्यान में रखते हुए कि मेरा कोड पहले से ही एक अच्छे मानक पर टिप्पणी कर रहा है, मेरे साथी डेवलपर्स को मेरी परियोजनाओं को लेने में मदद करने के लिए मुझे और क्या करना चाहिए?
किसी अन्य व्यक्ति द्वारा लिखे गए नए कोड के साथ काम करते समय, पहली बात यह है कि नए व्यक्ति (या लड़की) की कमी सिस्टम पर एक सिंहावलोकन है। वहां क्या उपप्रणालीएं हैं, उनका उद्देश्य क्या है और किसी को दिए गए कार्य को पूरा करने के लिए कहां देखना चाहिए, कुछ प्रश्न हैं जो ध्यान में आते हैं।
कुछ संक्षिप्त चित्रों के साथ समग्र सिस्टम डिज़ाइन (और इस डिजाइन को क्यों चुना गया था) समझाते हुए एक संक्षिप्त प्रारंभिक दस्तावेज़, कुछ ऐसा होगा जो किसी और द्वारा लिखे गए सॉफ़्टवेयर के टुकड़े पर काम करते समय मुझे खुशी होगी ।
से संबंधित नहीं है। बैठ जाओ और सोचें कि जब आप अपनी अगली कंपनी में शामिल हों तो आपको क्या चाहिए। –
मैं एक और चीज जोड़ता हूं, (ज्ञात बग के लिए एक और दस्तावेज़ हल नहीं किया गया) –
तो, एक व्यापक अवलोकन और कुछ बुनियादी प्रश्नोत्तर? अनसुलझा/अपूर्ण विशेषताएं भी लिखना एक अच्छा विचार है। – GenericTypeTea
व्यक्तिगत रूप से मैं अपने सभी दस्तावेज़ों को एक शीर्ष-डाउन शैली में लिखता हूं, पहले सभी शर्तों को परिभाषित करता हूं (एक सामान्य शब्दावली स्थापित करने के लिए) और फिर विस्तृत शब्दों में प्रश्नों को समझाते हुए, दस्तावेज़ को और विवरण को परिशोधित करते हैं। तो सिस्टम के सभी प्रमुख हिस्सों को कवर करने वाला इस प्रकार का डॉक्टर काफी अच्छी तरह से काम करेगा। साथ ही, यह अच्छा होगा अगर आपने अपनी परियोजनाओं में स्थापत्य निर्णयों के लिए तर्क प्रदान किया।
पुरानी परियोजनाओं के लिए तर्कसंगतता के संबंध में ... आप 18 महीने पहले कुछ करने के कारणों की व्याख्या कैसे करते हैं कि अब आप जानते हैं कि गलत है ... या उस समय गलत नहीं था, लेकिन अब आप जानते हैं कि यह सबसे अच्छा तरीका नहीं है? – GenericTypeTea
मैं व्यक्तिगत रूप से अपने सभी विचारों को एक छोटे से "उपयोग में आसान" विकी में लिखता हूं .. अगर कुछ गलत हो जाता है, तो मुझे बस अपनी विकी खोजनी है ... बाद में मैं इस मुद्दे के बारे में अपने सहयोगी से बात करने और इसे लिखने के लिए मेरे प्रलेखन में नीचे। मेरे लिए सबकुछ लिखना महत्वपूर्ण है। कभी-कभी यह जानकारी का एक बड़ा हिस्सा है, लेकिन यह मेरे लिए काम कर रहा है। :-) – bastianneu
@GenericTypeTea - उस स्थिति में आप दस्तावेज़ कर सकते हैं - 1) उस समय उस डिजाइन को क्यों चुना गया था 2) अब इसे गलत/अप्रचलित क्यों माना जाता है और 3) तथ्य/कैसे के बाद इसे बदला नहीं जा सकता आप इसे बदलने की योजना बना रहे थे। – samitgaur
किसी भी जटिल कक्षा/सिस्टम इंटरैक्शन के लिए यूएमएल अनुक्रम आरेख, किसी भी जटिल ओओ डिज़ाइन के लिए कक्षा आरेख, और सिस्टम-स्तरीय आरेख जो दिखाते हैं कि विभिन्न सिस्टम और ऐप्स इंटर-कनेक्ट कैसे होते हैं।
आप प्रोजेक्ट के डिज़ाइन की व्याख्या कर सकते हैं, कुछ महत्वपूर्ण सुविधाएं कैसे काम करती हैं और शायद आप किसी भी भविष्य के संवर्द्धन को दस्तावेज कर सकते हैं।
अपने शीर्ष-स्तर के अवलोकन दस्तावेज़ को विकी बनाने पर विचार करें - यह आपके जल्द से जल्द पूर्व-सहयोगियों को इसे संपादित और विस्तारित करने की अनुमति देता है।
और एक तर्क (जैसा कि बताया गया है) बहुत उपयोगी है: आपने समाधान ए का चयन क्यों किया, जब समाधान बी और सी एक आरामदायक पर्यवेक्षक के लिए इतना बेहतर दिखते थे? यह कली में सभी प्रकार की अंतहीन चर्चाओं को निपटा सकता है।
यह स्वयं स्पष्ट हो सकता है, लेकिन यदि परियोजनाएं ताजा विकास पर्यावरण (निश्चित रूप से उन्हें चाहिए) के लिए पहली बार जांचते समय "बॉक्स से बाहर" संकलित/चला नहीं जाती हैं, तो एक चरण-दर-चरण सब कुछ पाने और चलाने के तरीके पर कदम गाइड नए लोगों को सिरदर्द से बचाएगा।
मेरी इच्छा है कि मेरे पास यहां कुछ भी उपयोगी नहीं है, लेकिन कोड के प्राप्तकर्ता के रूप में कई मंदी, कौशल rebalancings आदि के माध्यम से, मैं पिछले जवाब में कुछ अंक दोहराना और जोड़ना चाहता हूं।
मुझे लगता है कि आपके प्रबंधन ने आपके काम को लेने के लिए एक या अधिक लोगों को नियुक्त किया है।
आपने कहा कि आपको इसकी आवश्यकता नहीं है, लेकिन यह कोड पर टिप्पणी जोड़ने का समय नहीं है।
यह पहले से ही बताया गया था कि सॉफ़्टवेयर के नए मालिक को उच्च स्तरीय अवलोकन की आवश्यकता है, सॉफ्टवेयर क्या करता है और इसे करने के लिए क्या आवश्यक था। इस संक्षिप्त को रखें, और इसे 'सॉफ़्टवेयर की तरह क्या दिखना चाहिए' में भंग करने की कोशिश न करें, कब्र से सिस्टम को फिर से आर्किटेक्ट करने के लिए परेशान न हों।
फिर व्यावहारिक मामलों पर जाएं: हितधारकों, परीक्षकों और कोई भी जो शामिल थे और शामिल हो सकते हैं और इस सॉफ़्टवेयर के बारे में जानते हैं।
अन्य दस्तावेज और पीआरएस की आवश्यकताएं कहां हैं, क्या पीआर की आने वाली आवश्यकताओं में विशेष रूप से उल्लेखनीय कुछ भी है?
संस्करण नियंत्रण में सॉफ़वेयर कहां है, वहां सबकुछ है? वास्तव में?
सोफवेयर बनाने के लिए क्या आवश्यक है?
सबसे मूल्यवान समय पिछले दो बिंदुओं को सत्यापित करने पर खर्च किया जाएगा: संस्करण नियंत्रण से एक पूर्ण निर्माण वातावरण को मनोरंजन और नए मालिक की मशीन से निर्माण (परीक्षण/वितरण) को मनोरंजन करें। यदि समय है, तो एक साधारण समस्या को ठीक करें।
नई नौकरी में शुभकामनाएं!
किसी और ने पहले से ही अपने पूरे टूलचेन को दस्तावेज करने का उल्लेख किया है ताकि किसी को देव पर्यावरण स्थापित करने में मदद मिल सके। एक और चीज जो थोड़ा सा मेटा हो सकती है वह दस्तावेज करना है क्यों आप उन उपकरणों का उपयोग करते हैं।
जड़ से सभी एमएस वर्ड को फाड़ने की योजना बनाने से पहले कुछ भी बुरा नहीं है, केवल यह पता लगाने के लिए कि जब आप जर्मन बिक्री कार्यालय को अपनी टीपीएस रिपोर्ट जेनरेट करते हैं उस प्रारूप में और विज़बैंग JSON का उपयोग नहीं कर सकते जिसे आप इसे बदलना चाहते थे।
मैं इस प्रश्न को ऑफ-विषय के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह प्रोग्रामिंग –