यदि कोई आपको सॉफ़्टवेयर डेवलपमेंट प्रथाओं के संबंध में असत्यापित कथन प्रदान करता है, तो क्या आप "उद्धरण की आवश्यकता" के साथ प्रतिक्रिया करते हैं? [बन्द है]


14

हाल ही में मैंने ग्रेग विल्सन (सॉफ्टवेयर कारपेंटरी के मुख्य वैज्ञानिक) द्वारा दिए गए एक व्याख्यान में भाग लिया । अमूर्त से:

सॉफ्टवेयर विकास प्रथाओं के बारे में दावा करने वाला विचार अभी भी साक्ष्य डेवलपर्स के लिए विदेशी होना चाहिए, लेकिन यह अंततः सॉफ्टवेयर डेवलपर्स के लिए शुरू हो रहा है: कोई भी अकादमिक जो दावा करता है कि एक विशेष उपकरण या अभ्यास सॉफ्टवेयर विकास को तेज, सस्ता या अधिक विश्वसनीय बनाता है। किसी प्रकार के अनुभवजन्य अध्ययन के साथ उस दावे का बैकअप लेने की उम्मीद है।

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

यह स्पष्ट रूप से कहते हुए, मैं भोला हो रहा था

यहाँ एक उदाहरण व्याख्यान से लिया गया है:

"यदि 25% से अधिक कोड को रिफैक्टिंग की आवश्यकता है, तो इसे फिर से लिखना जल्दी है"।

प्रशंसनीय लगता है, लेकिन क्या यह सच है? इस अध्ययन का समर्थन कहां है? क्या यह सभी भाषाओं के लिए सही है? और इसी तरह।

ठीक है, यह एक चरम पर ले जाना काफी संभव है और किसी के द्वारा कुछ भी नहीं मानना ​​है जब तक कि आप इसे पहले सिद्धांतों से खुद को प्राप्त नहीं करते हैं। इस तरह से पागलपन (या शायद गणित ;-)) निहित है। लेकिन, अगर कोई आपके सामने "अरे, इस समय की भाषा चुनें", की तर्ज पर एक बयान के साथ आता है, तो हम उत्पादकता को बढ़ावा देने में सक्षम होंगे [10 से अधिक]% "क्या आप सिर्फ इसके लिए इच्छुक हैं इसे स्वीकार करें, या आप साबित सबूत के लिए पूछने जा रहे हैं?

यदि यह बाद का है (और मुझे आशा है कि यह है) तो

  1. आप इस सबूत को खोजने के लिए कहां जाएंगे?
  2. आप कितने कठोर होंगे?

संक्षेप में, यदि कोई आपको एक असत्यापित कथन प्रदान करता है, तो क्या आप "प्रशस्ति पत्र की आवश्यकता" का जवाब देंगे?


2
विज्ञान के बाहर कितने क्षेत्रों में, लोग अनुभवजन्य साक्ष्य मांगते हैं? मेरे अवलोकन में, लगभग उतना नहीं जितना मैं चाहूंगा।
डेविड थॉर्नले

1
करीबी वोटों पर कुछ टिप्पणियों के बारे में कैसे? "बहुत स्थानीयकृत" और "नहीं एक वास्तविक प्रश्न" इस संदर्भ में वास्तव में आत्म-व्याख्यात्मक नहीं है।
इनामाथी

1
हां, मैं भी करीबी वोटों के पीछे की वजह जानना चाहूंगा।
रॉबर्ट हार्वे

@Robert संपादन के लिए धन्यवाद। प्रतिबिंब पर बहुत कम भड़काऊ।
गैरी रोवे

1
बड़ा सवाल है। मैंने पिछले साल CUSEC में प्रो। विल्सन को बोलते देखा था और वह जो कहते थे उससे बहुत प्रभावित हुए थे। सबसे अच्छा हिस्सा तब था जब एक छात्र ने उसे अपने दावे का हवाला देते हुए दावा किया था कि दावों का हवाला दिया जाना चाहिए, और उसने एक भी हार को याद किए बिना किया।
मैथ्यू पढ़ें 19

जवाबों:


3

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

पेशे की लगभग हर चीज में एक कैविएट है, या कई तो एक ही स्थान पर हर सुधार में किसी अन्य जगह एक असंतुष्ट होने की संभावना है।

खाइयों में नीचे के लोग अनुभव के माध्यम से अंतर को जानते हैं और आम तौर पर वैज्ञानिक अध्ययन के माध्यम से इसे साबित करने की कोशिश करने के लिए धन / समय / संसाधन नहीं होते हैं।

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

यदि किसी ने आपको "यदि 2% से अधिक कोड की आवश्यकता है, तो इसे फिर से लिखने की जल्दी है" तो आपको पता चलेगा कि उतना ही झूठा होना चाहिए जितना कि किसी ने आपको बताया "केवल अगर 98% से अधिक कोड को फिर से तैयार करने की आवश्यकता है, तो यह है इसे फिर से लिखने की जल्दी "। जहां वास्तविक संख्या इस बात पर निर्भर करती है कि आप क्या कर रहे हैं और आदर्श से कितना दूर वर्तमान कोड है।

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


उदाहरण कथन के गहन विश्लेषण के लिए +1। क्या आपको वास्तव में लगता है कि सभी वैज्ञानिक अनुसंधानों में एक व्यावसायिक कोण है जिसका दोहन किया जाना है, हालांकि? (मेरी भोली को माफ कर दो, लेकिन मैं वास्तव में इस बारे में उत्सुक हूँ)
गैरी रोवे

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

8
यदि कोई आपको सॉफ़्टवेयर डेवलपमेंट प्रथाओं के संबंध में असत्यापित कथन प्रदान करता है, तो क्या आप "उद्धरण की आवश्यकता" के साथ प्रतिक्रिया करते हैं?

नहीं, मैं इसे यहां पोस्ट करता हूं और देखता हूं कि क्या इसे कोई अपवोट मिलता है। सामाजिक प्रमाण बिना प्रमाण से बेहतर है!


2
आप इस मॉडल के साथ कहीं मिल सकते हैं, लेकिन मैं प्रोग्रामर का हवाला देते हुए पेपर के बारे में सोचता हूं। एक स्रोत के रूप में।
इनामाथी 19

@ इमानाथी: यह कम से कम विकिपीडिया के रूप में विश्वसनीय है, यदि ऐसा नहीं है तो!
स्टीवन ए। लोव

सबूत मांगने के लिए +1 - हमेशा अच्छी सलाह। आपके मानने से पहले कितने उत्थान होते हैं? ;-)
गैरी रोवे

1
@ गैरी: एसओ पर, दस। इस साइट पर, बीस। मेटा पर, एक सौ - जब तक कि इसमें इकसिंगें और वेफल्स शामिल न हों, जिस स्थिति में यह सही होना चाहिए
स्टीवन ए। लोव

गेंडा संदर्भ से प्यार करें - मुझे उनमें से एक को प्राप्त करना चाहिए
गैरी रोवे

4

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

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

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

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

अंत में, "यदि 25% से अधिक कोड की आवश्यकता है, तो इसे फिर से लिखने की जल्दी है" जैसे बयान को सभी परिस्थितियों में काम करने के लिए साबित नहीं किया जा सकता है, इसलिए बयान [उद्धरण वांछित] वास्तव में हठधर्मी प्रोग्रामर को सूचित करने का एक तरीका है दूसरों पर अपने विचार रखने के लिए मजबूर करना चाहता है कि यह हमेशा "उसका रास्ता या राजमार्ग नहीं है।"


आह, अच्छी पुरानी मानव पूंजी और मानव संसाधन, हर जगह श्रमिकों के चल रहे अमानवीयकरण को बढ़ावा देने वाले उन अद्भुत जुड़वाँ वाक्यांशों ...
आरोहण

@ चेतावनी: एक अवधारणा का निष्पादन कभी-कभी इसका वर्णन करने के लिए उपयोग की जाने वाली उदात्त शब्दावली से कम हो सकता है। यही कारण है कि संदेहवादी लोग कभी-कभी सबूत मांगते हैं।
रॉबर्ट हार्वे

क्या उन विशेष अवधारणाओं के क्रियान्वयन के लिए यह एक अच्छी बात नहीं होगी कि वे कम पड़ जाएं?
हारून को

एक हठधर्मी प्रोग्रामर के खिलाफ "प्रशस्ति पत्र की जरूरत" रक्षा के एक अच्छे उपयोग के लिए +1 - बहुत उपयोगी
गैरी रोवे

4

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


+1 पूछने के लिए "आपको कुछ अपनाने की आवश्यकता क्यों है"। कभी-कभी अग्रणी किनारे से वापस कदम रखना एक अच्छी बात है।
गैरी रोवे

मुझे लगता है कि बहुत बार डेवलपर्स इसे विश्लेषण करने और समझने के बिना अगले सबसे अच्छी चीज में फंस जाते हैं और यह समझते हैं कि यह कैसे उन्हें लाभ और नुकसान पहुंचा सकता है। मैंने ऐसे हालात देखे हैं जहां Asp.Net वेबफॉर्म पर Asp.Net MVC जैसे संगठन कुछ अपनाते हैं लेकिन TDD को नहीं अपनाते हैं।
कार्लोसफॉकर

3

व्याख्यान से उदाहरण एक विधर्मी है, अंगूठे का एक नियम है और अधिक कुछ नहीं है। यह स्पष्ट रूप से स्पष्ट होना चाहिए।

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

क्या इसका मतलब है कि वे बिना मूल्य के हैं? मैं ऐसा बिल्कुल नहीं कहूंगा।

ह्यूरिस्टिक्स एक दृष्टिकोण है जिसे हम एनपी-पूर्ण समस्याओं को संबोधित करने की ओर ले जा सकते हैं, और कई मामलों में, सॉफ्टवेयर इंजीनियरिंग अपने आप में एक एनपी-पूर्ण समस्या है।


अच्छे अंक। =)
पाब्लो

1

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

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

दूसरे छोर पर, जब कोई वेंडर दावा करता है कि कुछ नया आईडीई 50% अधिक उत्पादक है, तो मेरी पहली प्रतिक्रिया $ $ ^ और है!


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

1
कोड पूरा उदाहरण के लिए +1 (एक ही लेखक स्टीव मैककोनेल द्वारा रैपिड डेवलपमेंट के लिए भी सही)।
गैरी रोवे

@ क्या यह दिलचस्प है कि जैसे-जैसे तकनीक उन समस्याओं को सुधारती है जो पहले गायब होने के लिए आवश्यक सबूत थीं। मुझे आश्चर्य है कि क्या यह एक ऐसा प्रभाव है जो प्रमाण मांगने की हमारी आवश्यकता को कम करता है?
गैरी रोवे

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

1

क्या ऐसा कुछ नहीं है जो पूरी तरह से अमूर्त चर पर निर्भर करता है (चर जो वैज्ञानिक रूप से मापा जाने का कोई तरीका नहीं है)?

मेरी राय में, वे भावनाओं को मापने के लिए एक अनुभवजन्य विधि के बारे में बात कर रहे हैं। कुछ ऐसा जो स्पोक भी पूरा नहीं कर सकता। =)


1
इस पर एक दिलचस्प ले के लिए +1। जानबूझकर (जानबूझकर) ऊनी उदाहरण को एक तरफ रख दें, अगर किसी ने आपसे कहा कि रेल स्प्रिंगवीवीसी से बेहतर ढांचा है तो आप इसकी वैधता का निर्धारण कैसे करेंगे?
गैरी रोवे

जैसा कि बेंजामिन ग्राहम अपनी क्लासिक पुस्तक में निवेश ("सुरक्षा विश्लेषण") के बारे में बताते हैं, उस (निवेश) उपकरण को दो अलग-अलग, लेकिन एकाकी पहलुओं में मापा जाना था: गुणात्मक (अमूर्त, भावनाएं), और मात्रात्मक (वास्तविक संख्या, गणित) , संगणना, तर्क)।
पाब्लो

मात्रात्मक वह है जो आप एक वैज्ञानिक विधि के माध्यम से माप रहे हैं। गुणात्मक वह है जो आप अपने स्वयं के वृत्ति के माध्यम से मापते हैं। विश्लेषण के बारे में भावनाओं के बिना भावना बनाम भावना का न्याय करना संभव नहीं है।
पाब्लो

कम से कम कहने के लिए, जब हम उनमें विचारों और मतभेदों के बारे में बात करते हैं, तो हम सार को मापने के लिए एक उचित, वैज्ञानिक और मूर्त विधि पर सहमत नहीं हो सकते हैं।
पाब्लो

मेरा उत्तर यह है कि हम केवल तकनीकी पहलुओं को माप सकते हैं, न कि अमूर्त विचारों / विचारों को। इसके अलावा, मुझे गधे की तरह आवाज लगाने का मतलब नहीं है। उन पदों का मतलब किसी तरह की मूर्खतापूर्ण प्रतिक्रिया के रूप में नहीं था।
पाब्लो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.