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