आपको अपने उत्तराधिकारियों के लिए क्या छोड़ना चाहिए?

18

मान लें कि आप एक नौकरी छोड़ने वाले एकमात्र डेवलपर हैं। कोड के बाहर किस तरह की जानकारी / सामग्री, आपको अपने प्रतिस्थापन के लिए बनाना और छोड़ना चाहिए?

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

मै सोच रहा हूँ:

खातों / पासवर्ड
उपकरण, बैकअप, सॉफ्टवेयर सीडी का स्थान

और क्या?

documentation knowledge-transfer

— स्टीवन एवर्स
स्रोत

1

मैं उन्हें

— gnat

मैं अपनी टिप्पणी में एक नायक ... ओह और बहुत सारी TODO बनने का मौका छोड़ूंगा।

— जॉब

2

जमे हुए प्रोजेक्ट के संभावित डुप्लिकेट - मेरे बाद लोगों को क्या छोड़ना चाहिए? और जॉब हैंडओवर चेकलिस्ट

— gnat

1

के संभावित डुप्लिकेट क्या मैं एक नौकरी पेशेवर छोड़ने के लिए करते हैं चाहिए?

26

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

— Tarka
स्रोत

स्रोत नियंत्रण स्थानों की सूची!

— HLGEM

@HLGEM यदि कोड वे पहले से ही उपयोग करते हैं तो स्रोत नियंत्रण में है आपको बस

— रीमोट्स की

@Demizey, हो सकता है कि आपका स्रोत नियंत्रण हमारी तुलना में समझने में आसान हो, लेकिन मैंने सिर्फ ope प्रोजेक्ट से दूसरे में संक्रमण किया था और मुझे अपना प्रतिस्थापन कई अलग-अलग स्थानों को दिखाना था, जो कि एक बार डेटा फिक्स होने पर निर्भर करता है , एक आयात, एक निर्यात, एक रिपोर्ट, आवेदन या एक ग्राहक अनुकूलन के लिए एक परिवर्तन। और जब आप क्रॉस-फ़ंक्शनल टीम पर काम करते हैं जैसा कि मैं करता हूं, तो मेरे पास 30-40 अलग-अलग जगहों पर स्रोत नियंत्रण के बारे में जानना होगा।

— HLGEM

2

मुझे खुशी है कि मैंने इसका जवाब दिया। मैंने हाल ही में वह नौकरी छोड़ी थी जिसमें मैं वह था जहाँ मैं यह सब चाहता था, और यह मुझे एक अच्छा चेकलिस्ट देता है कि मुझे क्या लिखना है।

— तारका

22

एक मजबूत कप कॉफी और एक माफी नोट।

क्या मैं चाहता हूं कि मुझे छोड़ दिया गया।

प्रलेखन। कुछ टिप्पणियां लिखना कितना कठिन है? सिस्टम नोट्स को आगे बढ़ाते हुए नोट्स, तैनाती नोट्स बनाएं। जब आप पुनरारंभ करते हैं और सब कुछ चला गया है तो क्या करें।
पत्रों। यह लिखें कि यह इस तरह क्यों किया जा रहा है इसलिए मुझे आश्चर्य नहीं है कि आप इसे दूसरे तरीके से क्यों नहीं कर रहे हैं। बैकअप सिस्टम कैसे काम करता है, सर्वर लोड, परीक्षण, परीक्षण मामलों, उपयोग मामलों का जवाब कैसे देता है।
टिप्पणियाँ। "डेटाबेस का उपयोग करते समय, कभी मत कहो SELECT * FROM clients। हमें यकीन नहीं है कि यह डेटाबेस को क्यों प्रभावित करता है" ।

— जोश के
स्रोत

8

मेरा ईमेल पता, या शायद फ़ोन नंबर भी।

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

— Vetle
स्रोत

3

ई-मेल ज़रूर, लेकिन शायद ही कभी मैं अपना फोन नंबर किसी को देता हूं जिसे मैं व्यक्तिगत रूप से अच्छी तरह से नहीं जानता हूं।

— स्टीवन एवर्स

अच्छी बात है, मैंने फोन नंबर के बारे में बताया।

— वेटल

यह एक राजनीतिक मुद्दा हो सकता है कि आप ऐसा कर सकते हैं या नहीं।

@ ThorbjørnRavnAndersen राजनीतिक या सामाजिक?

— आरोन मैकाइवर

7

आपके द्वारा लिखे गए कार्यक्रमों का दस्तावेज़ीकरण जैसे कि उनका उद्देश्य, भविष्य के विकास के लिए स्रोत फ़ाइलों का स्थान, पासवर्ड, आदि।

यह या तो एक टिप्पणी के रूप में या सादे दृष्टि में कोड के भीतर हो सकता है।

— जेरेमी
स्रोत

6

केवल प्रलेखन से अधिक, मैं जानना चाहूंगा कि जब वे किए गए थे तो कुछ निर्णय क्यों किए गए थे। हम वर्तमान में एक प्रोजेक्ट पर SWIG का उपयोग कर रहे हैं और अन्य डेवलपर्स में से एक यह जानना चाहता है कि हमने सिर्फ Boost :: Python का उपयोग क्यों नहीं किया। सरल उत्तर यह था कि ग्राहक ने उस समय बूस्ट के उपयोग की अनुमति नहीं दी थी। अब एक अलग कहानी है।

इस तरह की चीजें उन्हें न केवल परियोजना को समझने में मदद करेंगी, बल्कि आपके कार्यान्वयन को सीमित करने वाली सीमाओं / बाधाओं / चुनौतियों का सामना भी करेंगी। यह उन्हें भविष्य के रखरखाव और सुविधा वृद्धि के लिए एक प्रारंभिक बिंदु देगा।

— Wheaties
स्रोत

दर्ज "क्यों" होने के साथ महत्वपूर्ण लाभ यह है कि यह आपको उन निर्णयों को फिर से करने की अनुमति देता है जब बाधाएं बदलती हैं। हेक, यह आपको यह समझने में मदद करेगा कि वास्तव में उन बाधाओं को क्या है। बहुत ही मूल्यवान।

— डोनाल्ड फेलो

4

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

— केन हेंडरसन
स्रोत

3

यदि यह एक डेस्कटॉप प्रोग्राम है, तो स्क्रैच से पूरे सिस्टम का निर्माण कैसे किया जा सकता है (कई अलग-अलग प्रोग्राम हो सकते हैं), वितरण के लिए एक पैकेज कैसे बनाया जाए (इसके लिए क्या निर्भरताएँ हैं, उदाहरण के लिए .NET के संस्करण), और इसे सर्वर पर कैसे तैनात करें यदि यह लागू है तो डाउनलोड के लिए, या इसे सीडी या डीवीडी में जला दें।

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

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

— tcrosley
स्रोत

2

मैंने हाल ही में आपके लिए समान परिस्थितियों में एक नौकरी छोड़ दी (मैं केवल डेवलपर नहीं था , लेकिन वास्तव में केवल हम में से दो थे, इसलिए मुझे काफी ज्ञान था कि दूसरे व्यक्ति के पास नहीं था (और इसके विपरीत, क्या) बेशक))।

सामान्य दस्तावेज सामग्री के संदर्भ में, पूरे सिस्टम के अवलोकन का दस्तावेजीकरण करना महत्वपूर्ण है। अलग-अलग घटकों को पहले से ही कोड में प्रलेखित किया जाता है, लेकिन घटकों के बीच की बातचीत और ऐसा क्यों होता है या क्यों उस घटक से बात करने की आवश्यकता होती है यह महत्वपूर्ण है और हमेशा केवल डिबगिंग / कोड को देखकर पता लगाना आसान नहीं है।

फिर, मेरे जाने से पहले एक महीने के लिए, हर बार मैंने कुछ ऐसा किया जो केवल मैं ही कर सकता था, मैंने वही लिखा, जो हुआ, जो मुझे करना था, और क्यों। यह आमतौर पर "xyz घटक में एक बग था, इसे ठीक करने के लिए मैं एक्स के कारण फाइल एबीसी में देखना जानता था, तो मुझे यह करना चाहिए, यह और यह"।

बेशक, मैंने अपना ईमेल पता और फोन नंबर छोड़ दिया, अगर कुछ भी सामने आया तो वे अपने आप पता नहीं लगा सके। मुझे पहले कुछ हफ्तों में कुछ कॉल मिले, लेकिन वे धीरे-धीरे बंद हो गए।

— डीन हार्डिंग
स्रोत

1

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

— bigtang
स्रोत

1

प्रलेखन के लिए # 1 नियम वह नहीं है जो वह करता है लेकिन क्यों । जो प्रोग्राम चलते हैं, उन पर बैकस्टोरी क्या है और वे क्या करते हैं?

— एंडी लेस्टर
स्रोत

0

मुझे लगता है कि दस्तावेज़ों में देखने के लिए मुझे क्या अच्छा लगेगा, सामान्य सुविधाओं के अलावा क्या होगा। जैसे कुछ विचारों को लागू नहीं किया गया था या एक निश्चित मंच या विधि का उपयोग नहीं किया गया था (जो अन्यथा एक स्पष्ट विकल्प था)।

यह सुनिश्चित करता है कि उत्तराधिकारी हमेशा जानता है कि क्या नहीं करना है या यदि वह अधिक सक्षम है तो शायद वह एक काम के साथ आ सकता है और कुछ विशेषताओं को काम कर सकता है।

यह विशेष रूप से ओपन सोर्स प्रोजेक्ट्स पर लागू होता है। बहुत समय और मस्तिष्क की शक्ति बचा सकते हैं!

— Kasahs
स्रोत