2009-11-04 15 views
6

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

ये प्रमुख सिस्टम हैं जिन्हें ठोस वास्तुकला की आवश्यकता होती है। मैं लगातार "पुस्तक को पढ़ने" नहीं कहना चाहता हूं। मैं डिजाइन पैटर्न के नियमित उपयोग को पोम्पास के बिना आने के बिना कैसे प्रोत्साहित करूं? क्या कोई भी पूरी टीम सीखने और डिजाइन पैटर्न का उपयोग करने में सफल रहा है?

+0

$ - या तो + या - से अधिक की तुलना में कोई बेहतर प्रतिक्रिया पाश नहीं है। – jldupont

+1

"हथौड़ा वाला आदमी" सिंड्रोम से सावधान रहें; ऐसे पैटर्न आवश्यक नहीं होने पर "डिजाइन पैटर्न के नियमित उपयोग" के लिए कोई कारण नहीं है। डौग टी इसे नाखून करता है। –

+0

तरह का व्यक्तिपरक लगता है, मैं "समुदाय विकी" कहूंगा? –

उत्तर

14

मैं सुझाव देता हूं कि डिज़ाइन पैटर्न को कमजोर न करें, इसके बजाय विशिष्ट समस्याओं के लिए विशिष्ट डिज़ाइन/दृष्टिकोण की वकालत करें।

बाद में जब एक समान स्थिति होती है, तो आप पिछली समस्या के लिए उठाए गए दृष्टिकोण पर वापस आ सकते हैं। फिर आप इसे "पैटर्न" कह सकते हैं जिसे टीम ने असली लाभ के साथ वास्तविक समस्याओं को हल करने के लिए उपयोग किया है।

मैं पुस्तक के डिजाइन पैटर्न को अपने स्वयं के लिए सख्ती से पालन नहीं करता। यह आपको गैर-डिजाइन-पैटर्निस्टों से अच्छे सुझावों के लिए अंधेरा कर सकता है या आपको वास्तविक समस्याओं से अंधेरा कर सकता है जो आपके पर्यावरण/समस्या डोमेन के लिए विशिष्ट हो सकते हैं।

+4

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

1

पुस्तक को पढ़ने के लिए उन्हें मजबूर न करें, यह काम नहीं करेगा।

बस डिज़ाइन पैटर्न का उपयोग करके अपने कोड को दोबारा दोहराएं, और उन्हें दिखाएं कि यह आसान क्यों है।

उन्हें काम करने का नया तरीका जानने के लिए कुछ समय दें।

4

कोड समीक्षा।

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

+0

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

2

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

इसलिए एक टीम मैं निम्नलिखित करना होगा के लिए:

1)। डिजाइन और कोड समीक्षा। समीक्षा केवल वरिष्ठ लोगों द्वारा नहीं की जानी चाहिए। जूनियर भी कोड और टिप्पणी पढ़ते हैं। आदर्श रूप से वे भी सीखते हैं।

2)। डिजाइन wokrshops चारों ओर समस्याओं को टॉस और वैकल्पिक समाधान के साथ आते हैं।

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

2
  1. एक समस्या अच्छी तरह से करने के लिए उन्हें जाना जाता है।

  2. पैटर्न को पहचानें समस्या को सबसे प्रभावी ढंग से हल करें। और पैटर्न के साथ समस्या को हल करें और समाधान को लागू करें और उन्हें काम दिखाएं।

  3. अभी तक डिज़ाइन पैटर्न के बारे में उन्हें न बताएँ। लगभग 3-4 समस्याओं के लिए दोहराएं। बाद में उन्हें बताएं कि आपने डिजाइन पैटर्न के साथ क्या समस्या हल की है - प्रत्येक पैटर्न को नाम दें और उन्हें उनके आगे के अध्ययन और शोध के लिए संदर्भ पुस्तकें या यूआरएल पॉइंटर्स दें।

0

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

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

1

"हेड फर्स्ट डिज़ाइन पैटर्न" की कुछ प्रतियां प्राप्त करें और लोगों को इसे पढ़ने के लिए कहें। पैटर्न के बारे में जानने के लिए यह एक मजेदार तरीका है।

मैं प्रोफेशनल के लिए जॉन्स हॉपकिन्स इंजीनियरिंग प्रोग्राम (शाम परास्नातक डिग्री प्रोग्राम) के लिए एक डिजाइन पैटर्न कोर्स पढ़ता हूं, और नियमित रूप से पैटर्न के बारे में बात करने के लिए काम पर भूरे रंग के बैग लंच रखता हूं।

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

हर व्याख्यान मैं गोल्डन हैमर के बारे में बात करता हूं - सीखें कि प्रत्येक पैटर्न का उपयोग कैसे करें और उन्हें अपने टूलबॉक्स में तब तक लॉक करें जब तक आपको उनकी आवश्यकता न हो!

मेरी पसंदीदा तकनीक है जिसे मैं "पैटर्न थिएटर" कहता हूं। मेरे प्रत्येक छात्र एक पैटर्न का शोध करता है और एक 2-3 पृष्ठ स्क्रिप्ट लिखता है जो वास्तविक दुनिया में पैटर्न का उपयोग करता है। उदाहरण के लिए, मैं पर्यवेक्षक का वर्णन करने के लिए पॉल रेवर की सवारी के बारे में एक थियेटर प्रस्तुत करता हूं। (रॉबर्ट न्यूमैन ब्रिटिश और रोशनी दीपक देखते हैं; पॉल रेवर दीपक देखता है और सवारी शुरू करता है और चिल्लाता है; कुछ नगरपालिका उसे सुनते हैं और छुपाते हैं; कुछ नगरपालिका उसे सुनते हैं और अपनी बंदूकें पकड़ते हैं - अलग उत्तेजना/प्रतिक्रिया जोड़े) सिनेमाघरों में कुछ भी प्रोग्रामिंग का उल्लेख नहीं करता है; व्याख्यान के प्रोग्रामिंग भाग को शुरू करने से पहले वे सभी अवधारणाओं को कम करने के बारे में हैं।

0

प्रचार कार्य नहीं करता है। मिसाल पेश करके।

जब आप किसी डिज़ाइन पर काम कर रहे हों, तो अपनी डिज़ाइन पैटर्न पुस्तकें लें और इसे खोलें। यहां तक ​​कि यदि आपने सभी पैटर्न याद किए हैं, तो पुस्तक खोलें।

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

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

संबंधित मुद्दे