मैं लोगों को बिकेशिंग (तुच्छताओं पर ध्यान केंद्रित करने) को रोकने के लिए कैसे प्राप्त करूं?


139

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

Why is that named that? (यह बताने के लिए 2 मिनट कि इसका नाम क्यों रखा गया है, 10+ मिनट एक नए नाम पर बहस करते हुए)

Why is that an abstract base class rather than an interface? (समझाने के 2 मिनट, 10+ मिनट इस निर्णय के सापेक्ष गुणों पर बहस करते हुए)

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

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

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

तो आप अन्य प्रोग्रामरों को पर्याप्त रूप से कैसे शिक्षित करते हैं कि वे तुच्छताओं को ठीक करना बंद कर दें और डिजाइन में सार्थक योगदान दे सकें?


44
मुझे यह कहने से नफरत है, लेकिन यह मुझे लगता है कि यह घटना नए लोगों के साथ कोडबेस के साथ एक समस्या का अधिक चित्रण है।
निकोल

30
क्या आपने अंत तक सवालों को हटाने की कोशिश की है? "कुछ और मिनटों के लिए रुकें और मैं अंत में समझा सकता हूं" और फिर बस बाकी सामग्री के माध्यम से धक्का दे रहा हूं। शायद इनमें से कुछ सवाल खुद जवाब देंगे
jozefg

21
@NickC, मेरा मानना ​​है कि कोड अच्छा है या नहीं, इससे कोई लेना-देना नहीं है कि आप इसे कैसे समझ सकते हैं, आप इसकी एक स्पष्ट बड़ी तस्वीर कैसे प्राप्त कर सकते हैं। आरंभिक बड़ी तस्वीर पाने के लिए समय निकाले बिना छोटे विवरण पर समय बर्बाद करना बुरा है और उस संभावित बुरे कोड को ठीक करने में कभी मदद नहीं करेगा।
शिवन ड्रैगन

11
किसी को कोडबेस सिखाने का लक्ष्य क्या है? हो सकता है कि आप उस लक्ष्य को अधिक स्पष्ट रूप से संवाद कर सकें, और यह महत्वपूर्ण क्यों है, ताकि वे देख सकें कि किसी वस्तु के लिए एक नए नाम पर बहस करना उस लक्ष्य से विचलित कर रहा है और उसे किसी अन्य बैठक के लिए आरक्षित किया जाना चाहिए।
लार्स

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

जवाबों:


159

मुझे लगता है कि समस्या कार्य है: "मुझे अन्य टीमों को एक नया कोडबेस सिखाने का काम सौंपा गया है"।

आपको गलत काम दिया गया है, या शायद आपके द्वारा दी गई नौकरी की गलत व्याख्या की गई है।

कोड स्तर पर प्रस्तुत करके, आप कोड स्तर की सोच को आमंत्रित करते हैं।

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

जब आप कोड स्तर पर पहुँचते हैं, तो आप पहले से ही सिस्टम शब्दावली के साथ उन्हें प्राइम कर चुके होते हैं। नाम (मुझे लगता है) समझ में आएगा। ऊपर के समान: कोई विस्तारित चर्चा, समझने के लिए प्रश्न। आगे बढ़ो।

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

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


3
मैंने पहले उच्च स्तरीय डिज़ाइन निर्देश का एक सा किया है, साथ ही साथ कुछ नई / अपरिचित प्रौद्योगिकियों (IoC कंटेनरों, डायनेमिक्स) पर प्रशिक्षण देने में मदद की है। यह प्रशिक्षण बहुत अच्छा रहा है। यह एक अच्छी बात है।
तेलस्तीन

+1 fot "साइकिक हैक्स" जैसे लोगों के साथ लड़ने की कोशिश नहीं कर रहा है जैसे "मैं आपके समय में आपके विषय के सवालों का जवाब दूंगा!" बल्कि देखने का नज़रिया बदल रहा है
Buksy

3
शानदार जवाब। मुझे विशेष रूप से ध्यान केंद्रित करने का सुझाव पसंद है कि 'इसके आंतरिक घटकों का नाम क्या है' के बजाय 'यह क्या करता है'।
डैनियल हॉलिन्रेके

66

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


8
+1 इस तरह लोगों को लगता है कि उनकी अनदेखी नहीं की जा रही है।
andy256

मैं इससे सहमत हु। यदि समस्या बहुत लंबे समय से अप्रासंगिक चीजों पर चर्चा कर रही है, तो अप्रासंगिक चीजों पर चर्चा न करें ...
क्रिस '

7
हो सकता है कि एक व्हाइटबोर्ड पर ओटी प्रश्न लिखकर हर किसी का समय लेने के बजाय, प्रश्नकर्ता से इसे नोट करने के लिए कहें (निर्दिष्ट विकी पेज पर, JIRA मुद्दा, जहां भी हो)।
लार्स

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

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

21

अपेक्षाओं को सही ढंग से सेट करें और ईमानदार, खुले और आगे बढ़ें।

सुनिश्चित करें कि आपके लक्ष्य खुले और पारदर्शी हैं।

Andy256 (+1) द्वारा प्रचारित उच्च स्तरीय दृश्य के साथ चर्चा शुरू करें लेकिन यह भी सुनिश्चित करें कि आप अपने उद्देश्यों को शामिल करें, आदि।

"... जैसा कि हम इस मुद्दे को देखते हैं, यह सुनिश्चित करते हैं कि हम x, y और z पर ध्यान केंद्रित नहीं करते हैं। यह भी सुनिश्चित करें कि हम कार्यान्वयन विवरणों जैसे कि, b, c या तुच्छ विवरणों को नहीं देख रहे हैं। जैसे कि j, k, l। मुझे पता है कि कोड में बहुत सारे विवरण होना आवश्यक है और उन चीजों का ब्योरा देते हैं जिन्हें संबोधित किया जा सकता है, सुधार किया जा सकता है या अधिक मानक बनाया जा सकता है, लेकिन कोशिश करें और देखें कि यह वास्तव में पहले उच्च स्तर पर क्या हासिल कर रहा है। "


पहले 2 वाक्यों के लिए +1। हालांकि, लोगों को किसी चीज के बारे में न सोचने के लिए कहना, उन्हें इस बारे में न सोचने का एक अच्छा तरीका नहीं है। "आप जो भी करते हैं, गुलाबी गेंडा के बारे में नहीं सोचते हैं।" इससे पहले कि मैं गुलाबी गेंडा का उल्लेख करता, क्या आप उनके बारे में सोच रहे थे? शायद ऩही। अगर इसके बजाय मैंने कहा "काल्पनिक जानवरों से विचलित न हों और इसके बजाय ऑस्ट्रेलियाई जानवरों पर ध्यान केंद्रित करें" तो कोआला और कंगारू आपके पास हो सकते हैं, लेकिन शायद गुलाबी गेंडा नहीं।
माइकल शॉ

अच्छी बात। हालाँकि असली बिंदु लोगों की सोच को रोकना नहीं है (और कहा नहीं गया), लेकिन उन लोगों से बचने के लिए बातचीत से बचना चाहिए जो हत्यारों और मनोबल चूसने वालों से मिल रहे हैं। लोग हमेशा बहुत सी अनसेफ चीजें सोचेंगे। ठीक है। व्यावसायिक व्यावसायिक स्थिति में कुछ बातें कही जाती हैं और कई नहीं।
माइकल डुरंट

17

तो आप अन्य प्रोग्रामरों को पर्याप्त रूप से कैसे शिक्षित करते हैं कि वे तुच्छताओं को ठीक करना बंद कर दें और डिजाइन में सार्थक योगदान दे सकें?

पहले, उनकी चिंताओं को "तुच्छता" या "बिकेशिंग" न समझें। वे निर्णयात्मक शब्द हैं, और वे अपमानजनक हैं। उनकी चिंताएँ मान्य हैं। वे इस समय महत्वपूर्ण नहीं हैं।

किसी भी अच्छी बैठक की कुंजी सभी को पता है:

  • आप बैठक क्यों कर रहे हैं और
  • आप इससे बाहर निकलने की उम्मीद करते हैं
  • यह कब तक चलना चाहिए

इन बातों को स्पष्ट, और लक्ष्यों को स्पष्ट करें।

उदाहरण के लिए, आप कह सकते हैं: "यह बैठक मेरे लिए आपको फू पैकेज से परिचित करने के लिए है और हमारे रिपोर्टिंग मॉड्यूल में इसका उपयोग कैसे किया जाता है। मेरा लक्ष्य फू के बारे में आपको पर्याप्त समझना है कि आप बार रिपोर्ट प्रोजेक्ट पर काम कर सकते हैं। अगले हफ्ते। मैं चाहूंगा कि हमें अगले 90 मिनट में किया जाए। "

फिर, जब कोई विषय आता है, तो यह इस तरह से हो सकता है:

नया व्यक्ति: "क्यों FooWidget एक मुखौटा पैटर्न के रूप में लागू किया गया है?"

आप: "ठीक है, मुझे लगता है कि यह है (क्योंकि डिजाइन निर्णय का संक्षिप्त विवरण)" या "मुझे नहीं पता।"

यदि उत्तर पर्याप्त है, तो यह बहुत अच्छा है। यदि नहीं, और यह जारी है:

एनपी: "क्या आपको नहीं लगता कि यह एक सिंगलटन के रूप में बेहतर होगा?"

आप: "मैंने वास्तव में इसके बारे में नहीं सोचा था, लेकिन मैं यह समझाते हुए आगे बढ़ना चाहूंगा कि FooWidget कैसे काम करता है।"

एनपी: "लेकिन अगर यह एक सिंगलटन के रूप में किया जाता है तो हम कर सकते हैं -"

आप: "मुझे बाधा डालने के लिए खेद है, लेकिन मुझे इस बात पर ध्यान केंद्रित करने की आवश्यकता है कि फूविडगेट कैसे काम करता है। यह बैठक केवल 11:00 बजे तक निर्धारित है और हमारे पास आने के लिए बहुत कुछ है। डिजाइन चर्चा के लिए एक और समय का इंतजार करना होगा। । "

आपके द्वारा एक या दो बार जाने के बाद, आप इसे "इस बैठक के दायरे से बाहर है।"

ध्यान दें कि आप यह नहीं कह रहे हैं कि "यह चिंता का विषय है" या "इससे कोई फर्क नहीं पड़ता" या "चुप रहो" या "आप इनपुट के लिए बहुत नए हैं।" आप बस बैठक पर ध्यान केंद्रित कर रहे हैं कि क्या करने की जरूरत है और इसमें शामिल समय।


1
यह बताना आसान है कि जब कोई प्रस्तुतकर्ता वास्तव में प्रतिक्रिया में रुचि नहीं रखता है। वे बैठकें तेजी से होती हैं। कोई परवाह नहीं करता है।
चक्स

4

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

वास्तविक समस्या को हल करने, अमूर्त सोच, और कठिन मुद्दों पर निर्णय लेने के साथ इस शक्ति-विरोधाभास का विरोध करें कि वे बाद के परिणामों के लिए जिम्मेदार हो सकते हैं, और बहुत से कर्मचारी जितना संभव हो सके बिकने की कोशिश करने के लिए भारी वजन करते हैं।

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

ऐसा करना अक्सर कठिन होता है, क्योंकि वरिष्ठ व्यक्ति आमतौर पर प्रौद्योगिकी के बारे में नहीं समझता है, वह दिलचस्पी नहीं रखता है, और दुर्भाग्य से, कच्चे माल को नियंत्रित करता है: कर्मचारी समय; किराया और आग, सम्मेलन कक्ष की राजनीति, पदोन्नति, आदि, गंभीरता से, एट cetera to the nth।


3

जिसे आप बाइकेडिंग कहते हैं, मैं किसी के विचारों के प्रवाह को अपने आप में परिवर्तित करने को कहूंगा। नाम, पैटर्न पर चर्चा करके, वे कोड को अपनी शर्तों में समझते हैं और इसे रोकने का कोई तरीका नहीं है, इसकी आवश्यकता है।

इसके अलावा, एक पूरे कोडबेस के बहुत विस्तृत पूर्वाभ्यास के लिए जाने की कोई आवश्यकता नहीं है, क्योंकि इस पर काम करने से पहले विवरण को बहुत पहले ही भुला दिया जाएगा।

इन दो विचारों के आधार पर, मैं कोड बेस को इकाइयों में, और शिक्षार्थियों को दो-जन समूहों में विभाजित करने का सुझाव दूंगा। कोड की प्रत्येक इकाई के लिए, प्रत्येक समूह के पास 25 मिनट ( कोर्स के LOC पर निर्भर करता है ), दूसरों को कोड के 5-10 मिनट चलने में सक्षम होने के लिए कहेंगे । तीन मिनट के सवाल और अगली इकाई के साथ दोहराएं। व्याख्या करना प्रमुख शब्द है; उन्हें यह सुनिश्चित करना होगा कि दूसरों को यह सब समझ में आए।

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

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

क्षमा करें यदि आपने पहले ही कोशिश कर ली है कि ...


1

क्या आपने पूर्व-पाठ बनाने की कोशिश की है जो लोग व्यक्तिगत रूप से देखते हैं?

लघु वीडियो या प्रस्तुतियां बनाएं जो सामग्री की व्याख्या करते हैं, कि कोड कैसे काम करता है, या मूल रूप से यह सब आप उन्हें एक प्रारूप में सिखाना चाहते हैं, जहां उन्हें इसे स्वयं देखना होगा और उन सूचनाओं को सीखना होगा जिन्हें आप उन्हें सिखाने की कोशिश कर रहे हैं।

तब आप सामग्री से संबंधित मुद्दों पर चर्चा करने के लिए टीम-आधारित सत्रों का उपयोग करते हैं। आपको विशिष्ट रूप से पहचानने की आवश्यकता है कि टीम सत्र केवल सामग्री से संबंधित मुद्दों पर चर्चा और समस्या निवारण के लिए हैं।

यदि आप एक व्यक्ति के आधार पर लोगों को सबक प्रदान करते हैं, तो आप उस अन्य सामाजिक मुद्दे से बचने में सक्षम हो सकते हैं जहां एक एकल मामला सामूहिक के रूप में समूह की आवाज बन सकता है और पाठ के वास्तविक उद्देश्य से विचलित हो सकता है।


13
Nooo ......., वीडियो नहीं ..... "डेथ बाय पॉवरपॉइंट" को एक और भी बदतर भाग्य द्वारा छीन लिया गया है ......, हालांकि इसमें सवालों को रोकने का वांछित प्रभाव होगा - उन्हें धमकी 30 मिनट में समझा जा सकता है और सेकंड में समझा जा सकता है कि समझाने के लिए और अधिक वीडियो 10 मिनट लगते हैं ....
Mattnz

6
+1 मैटनज़ संचार समस्याओं को एक तरफ़ा बातचीत के साथ सुधारने की संभावना नहीं है।
माइकल डुरंट

1
मैं विडियो में होने पर भी रुका हुआ नहीं रहना चाहता! क्या वीडियो प्रारूप / कोडेक रोकना अक्षम करता है? :) :) :)
कज़

1

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

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

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