क्या यह उम्मीद करना उचित है कि एक वरिष्ठ डेवलपर जानता है कि ओओपी डिजाइन पैटर्न क्या हैं? [बन्द है]

Question

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

तो मेरा सवाल यह है कि क्या इन सवालों को पूछने का कोई मतलब है? या यह एक ऐसा अस्पष्ट विषय है कि आप पहले से ही उन्हें जानने के लिए नए काम की उम्मीद नहीं कर सकते हैं?

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

जोड़े अब तक जवाब पढ़ने के बाद, मैं कुछ स्पष्टीकरण देना चाहिए:

• नौकरी OOP / OOD में अनुभव के साथ .NET डेवलपर के लिए है
• मौजूदा कोड क्लास नामों जैसे IParameterGraphVisitorऔर IStorageFactoryकई स्थानों का उपयोग करता है
• यदि आप अपने डिजाइनों की व्याख्या करने की शब्दावली नहीं रखते हैं, तो आप लोगों से उनके पुराने अनुभवों के बारे में कैसे पूछ सकते हैं, जो उन्होंने बनाए थे? यही मैं करना चाहता हूं, और सभी के साथ मैं आ सकता हूं "कृपया आप व्हाइटबोर्ड पर अपने पिछले प्रोजेक्ट के डिजाइन / ऑब्जेक्ट पदानुक्रम को आकर्षित करें"।

Comments

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

— माइकल के

@ मिचेल: सहमत हैं। नामों को जानने और पैटर्न का उपयोग करने में सक्षम होने के बीच अंतर है। मुझे OO पर उठाया गया है, लेकिन अगर आपने मुझसे कुछ पैटर्न का नाम पूछा और उनका वर्णन किया तो मैं अच्छा नहीं करूंगा। मुझे विशेष रूप से परवाह नहीं है कि किस उद्योग ने इसे कॉल करने का फैसला किया है, लेकिन मुझे यकीन है कि मैंने वास्तव में उन अधिकांश पैटर्न को लागू किया है जिन्हें आप सूचीबद्ध होने की उम्मीद कर रहे थे।

— अनहोलिसप्लर

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

— निक ने

शायद एक बेहतर दृष्टिकोण उन्हें पूछना होगा कि किसी विशिष्ट समस्या को कैसे हल किया जाए। मैं एक के लिए सभी डिजाइन पैटर्न के नाम याद नहीं करता, लेकिन मैं जानता हूं कि उन्हें कैसे लागू किया जाए और उनका उपयोग कैसे किया जाए। जैसा कि @Michael कहते हैं, अनुभव होना और buzzwords जानना दो अलग चीजें हैं।

— तारणी

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

— विलियम पीट्री

Answer 1

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

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

Comments

+1, मैं गैंग ऑफ फोर से पहले कुछ समय के लिए उन संरचनाओं का उपयोग कर रहा था, इसलिए मुझे हमेशा उन नामों को याद रखने में परेशानी होती है जो उन्हें दिए गए थे।

— डायटबुद्ध

पैटर्न साहित्य है, मुझे लगता है, इस तरह की चीजों के बारे में बहुत स्पष्ट है - पैटर्न डिजाइन के विकल्प के लिए नहीं हैं, वे डिजाइन के बारे में संवाद करने में मदद करने के लिए हैं। (मैं कहूंगा कि डिज़ाइन के बारे में संवाद करने में भी डिज़ाइन में मदद मिलती है, लेकिन मुझे लगता है कि यह एक अलग बात है।)

— एडन कूली

+1। यह मेरे साथ हर समय होता है। इसके बाद मैंने "डिपेंडेंसी इंजेक्शन" पर विकी लेख पढ़ा, यह जानने के लिए कि यह इतना लोकप्रिय क्यों लगता है, केवल यह पता लगाने के लिए कि यह एक ऐसी तकनीक है जिसका मैं वर्षों से उपयोग कर रहा हूं, लेकिन बस इसे कभी नाम नहीं दिया। "राज्य मशीन" के साथ भी।

— whatsisname

क्या यह एक उचित उम्मीद नहीं है कि एक वरिष्ठ डेवलपर के लिए इस बात का पालन करना कि क्षेत्र में क्या हो रहा है, और व्यापक रूप से इस्तेमाल की जाने वाली शब्दावली को अपनाएं? पैटर्न अब तक लगभग 15 वर्षों से अधिक समय तक रहे हैं, इसलिए आप शायद ही अब उन्हें "नया" भी कह सकते हैं ...

— पेटर टॉर्क

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

— डंक

Answer 2

एक वरिष्ठ OO डेवलपर के लिए आपकी अपेक्षा काफी उचित है। कोई भी उसे खुद को बुला रहा है कि बिना डिजाइन पैटर्न को जाने बस यह दर्शाता है कि उस अनुभव को स्वचालित रूप से वर्षों से पारित नहीं किया जाता है :-( यकीन है कि बहुत सारे डेवलपर्स हैं जो क्षेत्र पर या यहां तक ​​कि दशकों तक क्षेत्र में रहते हैं, डिजाइन के बारे में कभी सुनवाई किए बिना। पैटर्न - यह दर्शाता है कि वे नए विचारों को सीखने, खुद को बेहतर बनाने और सर्वोत्तम प्रथाओं को अपनाने में रुचि नहीं रखते थे।

क्या किसी वरिष्ठ डेवलपर को डिज़ाइन पैटर्न के साथ पूर्व अनुभव होना चाहिए, या आप कहेंगे कि डिज़ाइन पैटर्न एक ऐसा सरल विषय है जिसे हर सभ्य डेवलपर प्रशिक्षण के दौरान चुन सकता है?

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

आप उनकी डिजाइन क्षमताओं को नापने के बजाय क्या प्रश्न पूछेंगे?

उपरोक्त के साथ कॉन्सर्ट में, मैं केवल आपकी सूची में इन प्रश्नों को जोड़ूंगा:

• डिजाइन पैटर्न की कमियां क्या हैं (सामान्य रूप से, और उनमें से जो वे स्पष्ट रूप से उल्लेख करते हैं)?
• जब उनका उपयोग नहीं करना है, और क्यों?

अद्यतन करें

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

Comments

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

— ऐदन कल्ली

@ ऐडन, वहाँ अच्छी बात है, मेरे लिए यह पैटर्न का दुरुपयोग है । यह एक और तरीका है जिसमें अनुभव और अभ्यास अपरिहार्य है, अर्थात एक ही पैटर्न बनाम दो अलग-अलग पैटर्न के बीच अंतर करने में।

— पेटर तोर्क

+1, कोई भी व्यक्ति जो खुद को एक वरिष्ठ .NET देव कहता है, को कम से कम कुछ स्पष्ट पैटर्न के नाम, और उनके उपयोग का नाम देना चाहिए। यह संचार और टूलबॉक्स की बात है, अगर कुछ और नहीं।

— Techphoria414

मैंने इसे 3 बार पढ़ा है और अभी भी नहीं बता सकता कि पहला पैराग्राफ व्यंग्य है या नहीं

— briddums

@briddums, क्या आपको लगता है कि यह व्यंग्य है?

— पेटर तोर्क

Answer 3

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

Comments

निष्पक्ष तौर पर। OO केवल आपके जीवन काल के दौरान प्रमुख तरीकों में से एक बन गया। जावा में कॉलेज में इस्तेमाल की जाने वाली भाषा से पहले कई लोग थे जिन्होंने अपनी डिग्री प्राप्त की । ऐसे बहुत से लोग हैं जो OO दुनिया में नहीं रहते हैं।

— अनहोनीसमर २०

@unholysampler: बेशक, लेकिन मुझे लगता है कि यह एक OOP स्थिति है जिसके बारे में बात की जा रही है

— Anto

@unholysampler: मैं मुझे लगता है कि समय में रहते थे इच्छा .. मैं uni पर कुछ भी नहीं लेकिन जावा देखकर बर्दाश्त नहीं कर सकता <_ <

— प्रहार

Answer 4

एक साक्षात्कार में आपको पूछना चाहिए कि नौकरी करने के लिए उम्मीदवार को क्या जानना जरूरी है।

अगर उन्हें पैटर्न का नाम जानना है क्योंकि वे गैंग ऑफ़ फोर से हैं तो यह एक वैध आवश्यकता है।

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

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

Answer 5

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

Comments

+1 डिजाइन पेटेंट के साथ बहुत दूर नहीं ले जाने के लिए :)

— ज़ाकी जर्मन

अच्छी बात। प्रश्न में स्पष्टीकरण जोड़ा गया। यह .NET डेवलपर के लिए है, कम से कम ओओ प्रोग्रामिंग भाषा पर परियोजना के अनुभव के साथ।

— निकाइ

Answer 6

मान लें कि आप OOP में वरिष्ठता चाह रहे हैं तो इसका उत्तर हाँ है। डिजाइन पैटर्न ओओपी भाषा के लेक्सिकॉन हैं।

इसके अलावा यह आजकल अनुचित है कि 10 साल के अनुभव के साथ एक अच्छा ओओपी प्रोग्रामर एक डिजाइन पैटर्न का नाम नहीं दे सकता है, मानक एपीआई, पुस्तकालयों और विकास के ढांचे में व्यापक रूप से अपनाया गया डिजाइन पैटर्न है।

अब वर्षों हो गए हैं मैं साक्षात्कार के दौरान यह सवाल पूछ रहा हूं और यह एक शोस्टॉपर है जब उम्मीदवार विषय पर संतोषजनक जवाब नहीं देता है।

Answer 7

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

फॉलो-अप के साथ "मुझे डिज़ाइन करें एक टेक्स्ट एडिटर" जैसे प्रश्न को देखते हुए, "आप छवियों जैसी एम्बेडेड ऑब्जेक्ट्स का समर्थन कैसे करने जा रहे हैं? बोल्ड और इटैलिक? अनडू?" आप शायद अंततः कमांड पैटर्न, समग्र पैटर्न, स्मृति चिन्ह पैटर्न, और कुछ अन्य लोगों को एक छोटी बातचीत के साथ पहचानने के लिए पर्याप्त रूप से सुनेंगे।

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

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

Answer 8

उचित। निश्चित रूप से। ज़रूरी। नहीं

मैं संभावित उम्मीदवारों से पूछता हूं कि क्या वे डिजाइन पैटर्न जानते हैं। इसके कई मानदंडों में से एक को एक पूरे के रूप में तौला जाना है। कुल तस्वीर को नजरअंदाज न करें।

हां, कई डेवलपर्स अनजाने में कुछ डिज़ाइन पैटर्न का उपयोग करते हैं, इसमें कोई संदेह नहीं है।

इसलिए मैं सवाल नहीं करता।

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

वे रीफैक्टरिंग प्रक्रिया में भी मदद करते हैं। एक कोड के माध्यम से झलकना किसी कारखाने के पैटर्न के कुछ रूप को जल्दबाजी में लागू कर सकता है, लेकिन GoF कारखाने के पैटर्न ने समय की कसौटी पर कस लिया है। यही कारण है कि अपनी है कारखाने पैटर्न, अभी तक नहीं एक और fp (पहिया पुनर्रचना बेहतर नहीं है, जोएल सॉफ्टवेयर पर ऐसा करने का नुकसान पर बहुत सारे है)।

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

Answer 9

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

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

Answer 10

मुझे लगता है कि एक बेहतर प्रश्न होगा: पैटर्न का नाम, और पैटर्न का वर्णन, उदाहरण के लिए, गैंग ऑफ़ फोर बुक से एक फ़ैक्टरी पैटर्न, उम्मीदवार को एक परिदृश्य के साथ आने में सक्षम होना चाहिए जहाँ पैटर्न होगा एक उचित दृष्टिकोण।

Answer 11

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

Answer 12

हां वास्तव में उन्हें इस शब्द से परिचित होना चाहिए, और यहां तक ​​कि कुछ पैटर्न का नाम भी देना चाहिए - लेकिन अनुभव के साथ सैद्धांतिक ज्ञान को भ्रमित करने की गलती न करें।

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

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

क्लास पीपुलवेयर की तरह जो बाजीगर से पूछे बिना एक बाजीगर को काम पर रखने की बात करता है - सिर्फ इसलिए कि वे कहते हैं कि उनका ज्यादा मतलब नहीं है .. उन्हें आज़माएं।

Comments

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

— नीकी

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

— स्टीफन बेली

Answer 13

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

Answer 14

निश्चित रूप से उन्हें पैटर्न पता होना चाहिए, लेकिन जरूरी नहीं कि buzzwords।

उदाहरण के लिए MVC में PAC, 3-tier जैसे कई समान विकल्प हैं। कुछ साल पहले MVC के लिए एक और लोकप्रिय चर्चा "मॉडल 2" थी। मैं वास्तव में बहुत अच्छे डेवलपर्स को जानता हूं जो उस पैटर्न को पूरी तरह से जानते हैं, लेकिन यह नहीं जानते थे कि इसके लिए मौजूदा buzzword MVC है।

Answer 15

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

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

Answer 16

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

मान लें कि आपके पास लगभग समान पृष्ठभूमि वाले दो उम्मीदवार हैं, और एक आपको डिज़ाइन पैटर्न के बारे में बताने में सक्षम है, और दूसरा नहीं है। जो आपको बताएंगे कि वे नौकरी पर कैसा प्रदर्शन करेंगे?

आप कहते हैं कि मौजूदा सॉफ़्टवेयर डिज़ाइन पैटर्न का उपयोग करता है। क्या यह एक फायदा है? यदि हां, तो कैसे? क्या यह आपका लक्ष्य है कि लिखा गया नया सॉफ्टवेयर मौजूदा पैटर्न के अनुरूप हो, या उस नए पैटर्न को पेश किया जाए? क्यूं कर?

Answer 17

मैं एक वरिष्ठ डेवलपर के बारे में सोच सकता हूं जो निम्नलिखित स्थिति में डिजाइन पैटर्न के बारे में नहीं जानता है:

1. डिज़ाइन पैटर्न के बारे में केवल एक पुस्तक है। यह वह किताब है जिसने उन्हें पहले स्थान पर लोकप्रिय बनाया। यदि व्यक्ति ने इस एक पुस्तक को नहीं पढ़ा है, तो यह संभव है कि वे डिजाइन पैटर्न के बारे में नहीं जानते हैं, या उनके बारे में सुना हो सकता है, लेकिन ठीक से नहीं जानते हैं कि वे किस लिए हैं
2. इसके बजाय, उन्हें uml जैसा कुछ जानना होगा ...।
3. इंटरनेट से डिजाइन पैटर्न के बारे में अच्छी जानकारी प्राप्त करना आसान नहीं है। यदि आप सही वेब पेज को हिट करते हैं तो आप बहुत भाग्यशाली हैं जो अच्छे डिजाइन पैटर्न का ज्ञान रखते हैं। बस 1995 के बाद सॉफ्टवेयर में आने से एक व्यक्ति को डिज़ाइन पैटर्न बुक के बारे में पता नहीं चल सकता है, क्योंकि किताब पुरानी है।

Answer 18

एक गैर-ओओ वातावरण में किसी भी डेवलपर को ओओ डिजाइन पैटर्न के बारे में क्यों जानना चाहिए? मैंने दुकानों में काम किया है केवल कोबोल, केवल पीएल / एसक्यूएल, केवल प्रोग्रेस 4 जीएल, आदि। ओओ डिजाइन सिद्धांत वहां अप्रासंगिक हैं, मैं उन वातावरण में वरिष्ठ नागरिकों से अपेक्षा करूंगा कि उन वातावरणों के लिए प्रासंगिक ज्ञान हो, ओओ डिजाइन के लिए नहीं। पैटर्न।

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

Comments

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

— निकी

unix / linux 'C' में लिखा गया है, यह OO पैटर्न्स से भरा है, और कई और अधिक जो कि gof book में हैं।

— ctrl-alt-delor

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

— नाथन लॉन्ग

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

— डुबो देना