क्या एक डिज़ाइन दस्तावेज़ में किसी दिए गए डिज़ाइन के पेशेवरों / विपक्षों की चर्चा होनी चाहिए या क्या उसे तथ्यों और औचित्य पर ध्यान केंद्रित करना चाहिए?


13

मैं वर्तमान में एक डिज़ाइन दस्तावेज़ को अपडेट करने की प्रक्रिया में हूं ताकि यह भविष्य के डेवलपर्स के लिए सही और अद्यतित हो।

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

हालाँकि, डिजाइन के कुछ निर्णय, परियोजना की आवश्यकताओं को देखते हुए, बहुत ही खराब निर्णय हैं। हालांकि, कुछ अच्छे भी हैं।

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

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

प्रशन:

  • क्या एक डिज़ाइन दस्तावेज़ को कच्चे तथ्यों ("यह डिज़ाइन है") और औचित्य ("यहाँ यही डिज़ाइन है") से चिपके रहना चाहिए या क्या इसका उपयोग उस डिजाइन के साथ गैर-दोषपूर्ण मुद्दों को इंगित करने के लिए भी किया जाना चाहिए जो समस्याग्रस्त हो सकता है भविष्य के डेवलपर्स?
  • यदि इस जानकारी को पकड़ने के लिए डिज़ाइन दस्तावेज़ का उपयोग नहीं किया जाना चाहिए, तो इसे किस प्रकार के दस्तावेज़ को कैप्चर करना चाहिए, और डिज़ाइन तर्कसंगत, ट्रेडऑफ़, और ज्ञात समस्याओं की चर्चा के साथ और क्या कैप्चर किया जाना चाहिए (जो कि दोष नहीं हैं, क्योंकि दोष ट्रैक किए जाते हैं। अन्य उपकरणों का उपयोग करते हुए)?

1
डिज़ाइन दस्तावेज़ ऐसी आलोचनाओं के लिए उपयुक्त स्थान नहीं हैं, लेकिन यह महत्वपूर्ण है कि उन चिंताओं को कुछ उपयुक्त माध्यमों से प्रसारित किया जाए।
रॉबर्ट हार्वे 15

1
@ रॉबर्ट ऐसा लगता है जो मेरे लिए एक जवाब की तरह लगता है, हालाँकि शायद इस बात पर विस्तार करना कि आप उपयुक्त साधनों पर क्या विचार करेंगे।
थॉमस ओवेन्स

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

जवाबों:


7

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

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


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

2
@ थोमस ओवेन्स: इसके लिए जाओ! यह यहां अच्छा काम करता है, और मुझे भी अच्छा लगता है। :) मुझे नहीं लगता कि आप इसे "चोरी" कर सकते हैं क्योंकि मुझे पता है कि अन्य कंपनियों में लोग इसी तरह की चीजें करते हैं, यह मुश्किल से "नया" है;)
कुंठितवॉटरफ़ॉर्मडिजाइनर

5

क्या एक डिज़ाइन दस्तावेज़ को कच्चे तथ्यों ("यह डिज़ाइन है") और औचित्य ("यहाँ यही डिज़ाइन है") से चिपके रहना चाहिए या क्या इसका उपयोग उस डिजाइन के साथ गैर-दोषपूर्ण मुद्दों को इंगित करने के लिए भी किया जाना चाहिए जो समस्याग्रस्त हो सकता है भविष्य के डेवलपर्स?

यह "या तो-या" नहीं है।

पहली बार में कोई भी दस्तावेज नहीं पढ़ता है। वे स्किम करते हैं - सबसे अच्छे से। इसलिए, संभव के रूप में कुछ दस्तावेज़ लिखें। एक दस्तावेज़ सभी के लिए धैर्य है। "अन्य मुद्दों" के साथ एक दूसरे "गैर-देसी" दस्तावेज़ को पढ़ने के लिए बिल्कुल भी संभावना नहीं है।

एक दस्तावेज़ के लाभ? लोग इसे पढ़ सकते हैं।

एक दस्तावेज़ का नुकसान? कुछ। अधिकतर यह पुराना हो जाता है।

कई दस्तावेजों के लाभ? कोई नहीं।

कई दस्तावेजों का नुकसान? कृपया DRY सिद्धांत और साक्षर प्रोग्रामिंग पर पढ़ें। एकाधिक दस्तावेजों का अर्थ है त्रुटियों के कई स्रोत। प्रत्येक दस्तावेज़ दूसरे से असहमत है और कोड से असहमत है। यह बहुत स्पष्ट है। यह पागलपन का रास्ता है।


हाथ से लिखने से बचें।

एक पेशेवरों और विपक्ष दस्तावेज़ क्या-अगर और आकर्षक उपद्रव चर्चाओं की अनिश्चित गहराई में खींच सकते हैं।

यदि आपको लगता है कि पेशेवरों और विपक्षों को पेश करना आवश्यक है, तो इसे कम और बिंदु पर रखें।

जो है उस पर ध्यान दें।

रखें जो नंगे हड्डियों के लिए नीचे नहीं है।

यदि आपने बेंचमार्क, अध्ययन, या वास्तव में विकल्प, दस्तावेज का पता लगाया है। लेकिन अगर आप सिर्फ विकल्पों पर विचार कर रहे हैं, तो इसे कम से कम करें।

यह परीक्षण और क्लेश का आपका व्यक्तिगत इतिहास नहीं होना चाहिए।

  • कोई समस्या थी? ठीक कर दिया? हफ्ता लिया? वास्तव में संघर्ष किया? बमुश्किल एक दिलचस्प किस्सा। यह कोड में तय किया गया है। पिछले संस्करण, गलत संस्करण, छोटी गाड़ी संस्करण और निम्न-प्रदर्शन संस्करण कोई मायने नहीं रखते। वे ब्लॉग-चारा सबसे अच्छा कर रहे हैं।

  • अभी भी एक समस्या है? निश्चित नहीं? इसका मतलब है कि विकल्प हैं। यह दस्तावेज।


आपके अंतिम दो वाक्य विशेष रूप से सत्य हैं। जिस चीज पर मैंने चर्चा करने की योजना बनाई थी, वह या तो ऐसी समस्याएँ थीं, जिनका सामना मैंने एक फीचर को लागू करने / एक दोष को ठीक करने, परीक्षण लिखने, या प्रोफाइलिंग के दौरान करने और समग्र रूप से डिज़ाइन के समग्र समालोचना के रूप में नहीं किया। क्या आप इसे डिज़ाइन दस्तावेज़ या एक अलग दस्तावेज़ में दर्ज करने की सलाह देते हैं?
थॉमस ओवेन्स

"समस्याओं का सामना करना पड़ा"? अनिवार्य रूप से अप्रासंगिक। कोड समाधान है, समस्या आमतौर पर सिर्फ एक टिप्पणी है। "प्रोफाइलिंग के दौरान खोजा गया" का अर्थ है यह ठीक है, इसलिए यह अतीत में है, और इसकी कोई प्रासंगिकता नहीं है। इसे "जर्नलिंग" अभ्यास के रूप में उपयोग न करें।
S.Lott

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

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

1
@ थोमस ओवेन्स: इस बात पर विचार करें कि आप अद्वितीय हैं और बाकी सभी लोग आलसी हैं। "मैं किसी की कल्पना नहीं कर सकता जो नहीं करता है"। आपको अधिक लोगों से मिलने और यह देखने की आवश्यकता है कि प्रलेखन में कितना कम स्टॉक रखा गया है। उदाहरण के लिए। स्टैकऑवरफ्लो के 100 प्रश्न - हर दिन - ट्यूटोरियल द्वारा तुच्छ उत्तर दिए जाते हैं। फिर भी। दोस्तों ने पढ़ा नहीं है और पूरी तरह से मूर्खतापूर्ण सवाल पूछते हैं। मैं केवल वही दोहरा सकता हूं जो मैंने पिछले 3 दशकों से देखा है। लोग पढ़ते नहीं हैं। आपका अनुभव अलग हो सकता है। आपने सलाह मांगी। मैंने यह आपको दे दिया।
S.Lott

2

निर्णय लेने की प्रक्रिया में 3 महत्वपूर्ण तथ्य हैं:

  • क्या करने की कोशिश की गई थी और काम नहीं किया था (और यह काम क्यों नहीं किया, क्योंकि आप एक चलती लक्ष्य को लक्षित कर रहे हैं)
  • क्या है
  • क्या हो सकता है (बस एक्स के लागू होने का इंतजार है ...)

हालांकि, "क्या है" के अलावा, अन्य सभी पाठक को भ्रमित करेंगे और उसे सिस्टम को चलाने से रोकेंगे।

मुझे अन्य 2 को कैप्चर करने का विचार पसंद है, हालांकि वे सिस्टम सीखने के लिए कम दिलचस्प हैं, इसे बदलते समय वे समय बचाने वाले हो सकते हैं।

इसलिए, मैं एक ट्विस्ट के साथ @FrustratedWithFormsDesigner के विचार से अवगत कराऊंगा। अपने स्वयं के जीवन-चक्र के साथ अभी तक एक और दस्तावेज़ बनाने के बजाय, मैं एक एनेक्स अनुभाग पर व्यवहार करूँगा। फिर चर्चा के योग्य प्रत्येक निर्णय के लिए, मैं अनुलग्नक में संबंधित प्रविष्टि की ओर इशारा करता हूँ।


1

हाँ। एक डिज़ाइन दस्तावेज़ में वर्णित डिज़ाइन के साथ जुड़े लाभों, जोखिमों और मान्यताओं के बारे में बताया जाना चाहिए। एक डिज़ाइन दस्तावेज़ के कई उद्देश्य हैं:

  1. नीचे लिखा हुआ डिजाइन प्राप्त करें ताकि हर कोई इसे समझे, और ताकि प्रत्येक व्यक्ति की समझ समय के साथ न बढ़े।

  2. परियोजना पर काम करने वाले गैर-तकनीकी लोगों के लिए डिजाइन का संचार करें।

  3. शेड्यूलिंग, संसाधन आवंटन, लागत अनुमान और अन्य प्रकार की योजना में सहायता।

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

  5. अक्सर अनुबंध द्वारा आवश्यक डिलिवरेबल्स में से एक होता है।

(शायद अन्य लोग हैं, लेकिन ये एक अच्छी शुरुआत हैं।)

इन उद्देश्यों में से हर एक अच्छी तरह से एक डिजाइन डॉक्टर द्वारा परोसा जाता है जो स्पष्ट रूप से बताता है कि इस डिजाइन को क्यों चुना गया और संबंधित जोखिम क्या हैं:

  1. यह आवश्यक है कि टीम के सभी लोग जानते हैं कि जोखिम और लाभ क्या हैं ताकि वे उन जोखिमों से बचने के लिए एक साथ काम कर सकें और डिजाइन के लाभों का सर्वोत्तम उपयोग कर सकें।

  2. गैर-तकनीकी टीम के सदस्यों के लिए, जोखिम और लाभों को समझना अक्सर डिजाइन के विवरणों से अधिक महत्वपूर्ण होता है।

  3. जोखिम प्रबंधन उन सबसे महत्वपूर्ण चीजों में से एक है जो एक परियोजना प्रबंधक सफलता सुनिश्चित करने के लिए कर सकता है, और पहला कदम उन जोखिमों की पहचान करना है जिन्हें प्रबंधित करने की आवश्यकता है। यह तय करना प्रबंधक के लिए होना चाहिए कि जोखिमों से कैसे निपटा जाए, लेकिन डिज़ाइनर के ज्ञात जोखिमों को इंगित करना डिज़ाइनर की ज़िम्मेदारी है।

  4. यहां तक ​​कि जब कोई जोखिम अब कोई समस्या नहीं है, तो इसे अक्सर प्रलेखित करना उपयोगी होता है क्योंकि यह उस स्थिति को स्पष्ट करने में मदद कर सकता है जब डिजाइन बनाया गया था। यह एक अनुचर को कुछ तय करने दे सकता है: "ठीक है, उन्होंने इसे इस तरह से वापस किया, क्योंकि ... लेकिन अब यह कोई समस्या नहीं है, इसलिए मैं उस कोड को एक सरल, तेज कार्यान्वयन के साथ बदल सकता हूं।" लाभ के लिए भी वही जाता है।

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

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

यहाँ डिज़ाइन दस्तावेज़ लिखने पर एक ब्लॉग प्रविष्टि है जो आपको मददगार लग सकती है।


0

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

मुझे नहीं पता कि सभी शॉर्ट-कॉमिंग को इंगित करने के लिए बहुत लाभ है या नहीं। यह परिवर्तन करने के लिए व्यावहारिक नहीं हो सकता है या अन्य प्राथमिकताएं होंगी। आप निकट भविष्य में उनमें से कुछ को ठीक कर सकते हैं और यह अपडेट करने के लिए सिर्फ एक और चीज होगी।


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

0

मैं व्यक्तिगत रूप से इसे डिज़ाइन दस्तावेज़ में नहीं डालूंगा। एक डिज़ाइन दस्तावेज़ को यह रेखांकित करना चाहिए कि यह कैसा है, क्यों नहीं।

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


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

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

0

मैं डिज़ाइन दस्तावेज़ में तर्क रखने के बारे में आपसे सहमत हूँ।

वैसे भी,

किसी अन्य व्यक्ति द्वारा लिखित डिज़ाइन दस्तावेज़ को अपडेट करने की प्रक्रिया में, मैं विनम्र रहूंगा और यह अनुमान लगाने की कोशिश नहीं करूँगा कि ऐसा निर्णय क्यों लिया गया है।

इसलिए,

मैं केवल उन परिवर्तनों के बारे में तर्क को सम्मिलित करूँगा जो रखरखाव के दौरान डिज़ाइन में किए गए हैं।


निश्चित रूप से वह आखिरी वाक्य। मुझे नहीं पता कि जिम, बॉब और स्टीव ने अपने ऐप को इस तरह से डिजाइन करने का फैसला क्यों किया, इसलिए मैं इसे तर्कसंगत बनाने की कोशिश भी नहीं कर रहा हूं। हालांकि, मैं यह सुनिश्चित कर सकता हूं कि एक विशेष मॉड्यूल या घटक आवश्यकता (एस) से जुड़ा हुआ है और मेरे द्वारा किए गए निर्णयों को भी तर्कसंगत बनाता है।
थॉमस ओवेन्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.