मैं वेब फ्रेमवर्क का उपयोग करने के लिए टीम के सदस्य को कैसे मना सकता हूं? [बन्द है]

Question

सवाल यह है और विस्तार से इस प्रकार है: क्या कुछ ऐसा है जो मैं कह सकता हूं / एक प्रोग्रामर के रूप में, उसे मेरी तरफ लाने के लिए?

मैं इस एक पर दोनों पक्षों के लिए वैध तर्क सुनना पसंद करूंगा, लेकिन ज्यादातर उसे कैसे बात करना है इसके लिए सुझाव।

---

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

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

एक समूह के रूप में, हम यह तय करने के लिए आ रहे हैं कि वेबसाइट के कार्यान्वयन में किन तकनीकों का उपयोग किया जाए; विशेष रूप से, PHP फ्रेमवर्क (कोड इग्नाइटर) का उपयोग करना है या नहीं।

मैं हवाला देते हुए पक्ष में बहस कर रहा हूं:

1. पहिए को फिर से नहीं लगाना
2. काम करने के लिए अच्छी तरह से लिखित और परीक्षण कोड आधार
3. हो रही है (समय सीमा हम चाहते हैं की तुलना में करीब है)
4. विकास की गति
5. ध्वनि और अनुरक्षण डिजाइन पैटर्न और अच्छे अभ्यास

वह उस तरीके से काम करने के पक्ष में बहस कर रहा है जिस तरीके से उसका उपयोग किया जाता है:

• Bespoke लिखना, एक "पुस्तकालय" फ़ाइल में एक बार कार्य करता है जब उसे उनकी आवश्यकता होती है
  • डेटा एक्सेस करने और उस डेटा को पेज तक पहुँचाने के लिए कार्य, सत्र से और करने के लिए / सेटिंग और डेटा प्राप्त / पोस्ट करना आदि
• प्रति पृष्ठ 1 फ़ाइल होना (नियंत्रण, प्रस्तुति और डेटा के बीच चिंताओं को अलग नहीं करने के परिणामस्वरूप)

उपयोग करने के खिलाफ उनके कारण अधिकतर फ्रेमवर्क हैं जो उस बिंदु को देखने में सक्षम नहीं हैं: वह उन सभी चीजों को पहले से ही कर सकता है। ढांचा नहीं बदलता है, यह सिर्फ इसे कठिन बनाता है क्योंकि उसे रूपरेखा सीखना है; वह कोड का उपयोग नहीं करना चाहता है जिसे उसने व्यक्तिगत रूप से नहीं लिखा है।

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

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

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

TL, डॉ। अनुभवहीन टीम के सदस्य जिद्दी हो रहे हैं, मैं उसे कैसे जीत सकता हूं?

Comments

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

— yannis

इसके कुछ हिस्सों के लिए शायद बेहतर होगा: area51.stackexchange.com/proposals/30887/professional-matters

— कार्लसन

he doesn't want to use code he hasn't personally written.उसने अपने ऑपरेटिंग सिस्टम, आईडीई, फोन, ट्रैफिक लाइट आदि को बेहतर तरीके से फेंक दिया था

— स्टुपेरयूसर

@AndyBursh I want to know exactly how everything worksसीखने के दौरान एक मान्य तर्क है, पहिये का फिर से आविष्कार करना वास्तव में स्वीकार्य था। हो सकता है, बस हो सकता है, आप पढ़ सकते हैं कि मदद के लिए रोना और हठ के रूप में नहीं।

— यनीस

since the project is only a prototype and will never be maintained अंतिम अंतिम शब्द :) काश मेरे पास एक डॉलर होता जो मैंने इस धारणा को बनाया था और यह पाया कि उच्च उतार-चढ़ाव के अधीरता और अल्पावधि लालच ने फैसला किया कि प्रोटोटाइप अब उत्पाद है।

— maple_shaft

Answer 1

आप उससे बात करने में सक्षम नहीं होंगे। इसे Dunning-Kruger प्रभाव कहा जाता है । वह यह जानने के लिए बहुत अनभिज्ञ है कि वह क्या नहीं जानता है, और एक लाभ के रूप में जो वह शर्तों को खोने से डरता है।

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

Comments

+1 चूंकि यह कभी-कभी वास्तविक दुनिया में होता है। मैं उन नौकरियों में गया हूँ जहाँ मैं एक और देव के साथ सहमत नहीं हो सकता था जिस पर सबसे अच्छा दृष्टिकोण था। इसलिए हम दोनों ने एक पीओसी को क्रैंक किया और फिर प्रत्येक के पेशेवरों और विपक्षों की जांच की। 10 में से 9 बार हम एक समाधान को अपनाना चाहेंगे जो दो POCs का मैशअप था, और सभी ने प्रक्रिया से कुछ सीखा।

— टिमोथी बाल्ड्रिज

Dunning-Kruger के बारे में पढ़ाने के लिए +1! हर किसी को इसके बारे में जानने की जरूरत है ..

— स्टीफन ग्रॉस

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

— कॉर्बिन मार्च

@Corbin, Dunning-Kruger बुद्धि की कमी के बारे में नहीं है, यह अनुभवहीनता के बारे में है। दो बहुत अलग चीजें। मैं मानता हूं कि आपके कारण मान्य हो सकते हैं, लेकिन ओपी ने कहा कि वे तर्क नहीं थे जो वह कर रहे थे। इसके बजाय वह चौखटों का उपयोग करने के "बिंदु" को नहीं देखता है क्योंकि वह कम समय में खरोंच से खुद को अच्छा लिख ​​सकता है। एक अनुभवहीन व्यक्ति ने एक समाधान की तुलना में अपनी खुद की क्षमता को कम करके आंका है कि वह स्वीकार करता है कि लगभग कुछ भी नहीं है जो कि डिंगिंग-क्रूगर का एक पाठ्यपुस्तक उदाहरण है। ऐसे लोगों को "कुछ" में बात नहीं की जा सकती है, उन्हें दिखाया जाना चाहिए।

— कार्ल बेज़ेलफेल्ट

Answer 2

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

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

एक और - जैसा कि आपने उल्लेख किया है - कोड गुणवत्ता है। वेब पेज तैयार होने के बाद, प्रत्येक पर स्वीकृति परीक्षणों का एक ही सेट चलाएं, और बग घनत्व की तुलना करें।

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

Comments

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

— एंडी हंट

विज्ञान, यह काम करता है: xkcd.com/54

— स्टुपरयूजर

Answer 3

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

मुझे लगता है कि आप में से प्रत्येक अपने संबंधित समाधानों के लाभों को रेखांकित करने के लिए एक अच्छा दृष्टिकोण होगा, और टीम के अन्य सदस्यों को दिखाएगा कि आपको क्यों लगता है कि यह सबसे अच्छा तरीका है। फिर उन्हें फैसला करने दें। उनमें से 3 हैं तो यह टाई ब्रेकर होगा।

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

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

Comments

मैंने इस बारे में नहीं सोचा था कि यह समूह में दूसरों पर ईमानदारी से कैसे प्रतिबिंबित होता है। मुझे लगता है कि बाहर बिंदु करने के लिए सुनिश्चित हो जाएगा।

— एंडी हंट

Answer 4

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

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

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