उत्पाद डिजाइन निर्णयों के पीछे तर्कसंगतता दर्ज करने का एक प्रभावी तरीका क्या है?


30

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

हमारा उत्पाद अभी भी प्रारंभिक अवस्था में है, और हम अक्सर डिजाइन तत्वों को फिर से बनाते हैं जो महीनों पहले तय किए गए थे।

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

हम डिजाइन निर्णयों के पीछे तर्कसंगत रूप से कैसे प्रभावी ढंग से रिकॉर्ड कर सकते हैं?

हमारा वर्कफ़्लो Pivotal Tracker पर आधारित है। एक समाधान जो मुझे होता है, वह सभी प्रासंगिक डिजाइन निर्णयों के लिए तर्कसंगतता को उपयोगकर्ता की कहानी पर टिप्पणियों के रूप में रिकॉर्ड करना है, लेकिन यह अविश्वसनीय लगता है।

100% स्पष्ट होने के लिए: मैं कोड के डिजाइन के बारे में बात नहीं कर रहा हूं। मैं उस उत्पाद के डिजाइन के बारे में बात कर रहा हूं जो कोड द्वारा महसूस किया गया है। दूसरे शब्दों में, मैं ऐसे निर्णयों के बारे में बात नहीं कर रहा हूं जैसे "क्या हमें इस श्रेणी को कई विरासतों के बजाय रचना का उपयोग करना चाहिए?" मैं ऐसे निर्णयों के बारे में बात कर रहा हूँ जैसे "क्या हमें लॉग इन करने में सक्षम होने से पहले उपयोगकर्ता को अपने ईमेल पते की पुष्टि करने की आवश्यकता है?"

प्रलेखन का उद्देश्य व्यवसाय को एक रिकॉर्ड देखने की अनुमति देना है कि निर्णय क्यों किए गए थे, उसी विषयों के बारे में आगे के निर्णय लेने में सहायता करने के लिए।


13
अगर आपको लगता है कि आपको एक डिज़ाइन डॉक्यूमेंट की आवश्यकता है तो क्यों न एक डिज़ाइन डॉक्यूमेंट बनाया जाए?
मेटाफ़ाइट

मुझे लगता है कि तर्कसंगत अनुमान गद्य के रूप में दर्ज किए जाएंगे, पहले अनुमान में गद्य लिखे गए हैं। उन लोगों के लिए इच्छित पाठक कौन है?
लॉरेंट ला रिज़्ज़ा

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

लेखक कौन हैं और इस प्रलेखन के उपभोक्ता कौन हैं? यह मुझे लगता है जैसे "व्यवसाय" लेखक है और हर कोई इसके पाठक हैं? क्या यह सही होगा? (मुझे लगता है कि आप अभी छोटे हैं, लेकिन अगर आप बड़े होते हैं तो जवाब क्या होगा?)
mlk

मेरा सुझाव है कि "क्या हमें लॉग इन करने में सक्षम होने से पहले उपयोगकर्ता को उनके ईमेल पते की पुष्टि करने की आवश्यकता होगी?" इस तरह के निर्णय स्वीकृति मानदंडों के तहत होने चाहिए।
कूड़ेदान

जवाबों:


26

आप डिजाइन निर्णयों के पीछे तर्कसंगतता दर्ज करते हैं। आदर्श रूप से पास की वस्तु जो निर्णय के अधीन है (जो "उपयोगकर्ता कहानी" नहीं है - उपयोगकर्ता कहानियां वर्णन हैं कि क्या लागू किया जाना है, कैसे नहीं)।

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

IMHO डिजाइन दस्तावेजों में उनका मूल्य हो सकता है, लेकिन अगर वे उन वस्तुओं से बहुत दूर "वस्तुओं" का वर्णन करते हैं जो वे वर्णन करते हैं, तो वे बहुत जल्दी असंगत हो जाते हैं। इसलिए मेरी अनुशंसा है कि किसी भी डिज़ाइन के दस्तावेज़ को यथासंभव डिज़ाइन किए गए आइटम के पास रखा जाए।

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


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

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

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

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

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

8

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

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

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

इसलिए आपके पास दो चरण की प्रक्रिया है। आपको स्क्वैशवेयर से बाहर निकलकर प्रलेखन में आने की जरूरत है। फिर आपको यह सुनिश्चित करने की आवश्यकता है कि तर्कसंगतता को स्क्विशीवेयर में वापस लाने के लिए पर्याप्त रूप से व्यवस्थित किया जाता है जब आपको इसकी आवश्यकता होती है! अब मुझे लगता है कि हमारे पास समस्या बयान के लिए पर्याप्त है कि यह महसूस किया जाए कि चुनौतियाँ कहाँ पर होंगी। जब आप दस्तावेज़ दे रहे होते हैं, तो आप आमतौर पर यह नहीं जानते हैं कि बाद में कौन इसे देखने वाला है, या वे क्या देख रहे हैं। इसी तरह, जब आप दस्तावेज़ीकरण को देख रहे होते हैं, तो आप आमतौर पर नहीं जानते कि आप क्या देख रहे हैं (सबसे अच्छा आपको पता है कि कब हो सकता है)।

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

फुर्तीले होने का समय।

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

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

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

0

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


2
वास्तुकला और उच्च स्तरीय निर्णय - ठीक हो सकता है। एपीआई डॉक्स - नहीं! हमारे संगठन के कुछ लोगों ने अतीत में यह कोशिश की थी कि यह हमेशा समान हो - निम्न स्तर के डॉक्स कोड के साथ आउट-ऑफ-सिंक हो जाते हैं। विकीएस VCS के साथ अच्छी तरह से बातचीत नहीं करते हैं, लोग इसे अपडेट करने के लिए समय नहीं भूलते हैं या नहीं लेते हैं। एपीआई डॉक्स कोड में हैं , उनके द्वारा किए गए कार्यों के सामने। यदि आपको लगता है कि आपको अपने इंट्रानेट में उनकी आवश्यकता है, तो उन्हें वहां से निकालने के लिए डॉकटर जैसे HTML जनरेटर का उपयोग करें। लेकिन अपने आप को एक एहसान करो और उन्हें अलग से, मैन्युअल रूप से, विकी में बनाए न रखें।
डॉक्टर ब्राउन

3
मेरा दृढ़ विश्वास है कि स्रोत कोड भंडार के भीतर सभी डिजाइन तर्कसंगत लिखे जाने चाहिए। कोई अन्य स्थान, और वे न केवल सिंक से बाहर निकलते हैं, वे अपने इतिहास को भी याद नहीं करेंगे।
7

एक समाधान है कि काम करता है downvoting ... वाह। ठीक है फिर।
ज़ेरोबांड एक्सपोज़र

0

इसे उस कोडर के दृष्टिकोण से सोचें जो इसे 12 महीनों के समय में बदलने के लिए कहा जा रहा है।

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

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

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


0

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

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.