क्या DRY सॉफ्टवेयर प्रोजेक्ट मैनेजमेंट का दुश्मन है?

Question

सॉफ्टवेयर विकास के सबसे बुनियादी और व्यापक रूप से स्वीकृत सिद्धांतों में से एक DRY है (अपने आप को दोहराएं नहीं)। यह भी स्पष्ट है कि अधिकांश सॉफ्टवेयर परियोजनाओं के लिए किसी प्रकार के प्रबंधन की आवश्यकता होती है।

अब ऐसे कौन से कार्य हैं जिन्हें प्रबंधित करना आसान है (अनुमान, अनुसूची, नियंत्रण)? सही, दोहराए जाने वाले कार्य, बिल्कुल वही कार्य जिन्हें DRY के अनुसार टाला जाना चाहिए।

तो एक परियोजना प्रबंधन के नजरिए से, किसी मौजूदा कोड को 100 बार कॉपी करके किसी काम को हल करना और प्रत्येक कॉपी में कुछ मामूली अनुकूलन करना बहुत अच्छा है, जैसा कि आवश्यक है। हर समय, आप वास्तव में जानते हैं कि आपने कितना काम किया है और कितना बाकी है। सभी प्रबंधक आपसे प्यार करेंगे।

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

बेशक मैं अतिशयोक्ति कर रहा हूं, लेकिन स्पष्ट रूप से एक दुविधा है। मेरे प्रश्न हैं: यदि कोई डेवलपर DRY को ओवरडोज़ कर रहा है, तो यह तय करने के लिए मानदंड क्या हैं? हम एक अच्छा समझौता कैसे पा सकते हैं? या इस दुविधा को पूरी तरह से दूर करने का एक तरीका है, न कि केवल एक समझौता खोजने से?

नोट: यह प्रश्न मेरे पिछले एक विचार पर आधारित है, सॉफ्टवेयर विकास में नियमित काम की मात्रा और आकलन पर इसका प्रभाव , लेकिन मुझे लगता है कि यह मेरी बात को स्पष्ट करता है, इसलिए खुद को दोहराने के लिए खेद है :)।

Comments

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

— ब्लरफ्ल

दूसरी तरफ @Brfl, समय से पहले DRY-ing up कोड से पहले एक अच्छा अमूर्त स्पष्ट है वास्तव में उत्पादकता को भी नुकसान पहुंचा सकता है, क्योंकि एक साझा अमूर्त एक साझा निर्भरता है। मैं असहमत नहीं हूँ, btw, बस इशारा करते हुए निश्चित रूप से एक संतुलन पाया जाना है।

— GoatInTheMachine

जो सिद्धांत DRY को नियंत्रण से बाहर जाने से रोकता है, वह है YAGNI (आपको इसकी आवश्यकता नहीं है) सिद्धांत।

— फिलिप

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

— जैक्सबी

यदि आप अपने आप को दोहराते हैं, तो आपको अभी भी वह सब करना होगा जो अन्य कठिन-से-अनुमानित काम , और कुछ अतिरिक्त व्यर्थ काम है। तो कैसे इस परियोजना में मदद करता है?

— इबिबिस

Answer 1

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

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

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

यदि पीएम का एकमात्र उद्देश्य सटीक अनुमान लगाना था, तो यह आसान होगा। बस अनुमानों को 10X तक पैड करें, और अगर वे जल्दी खत्म होते हैं तो डेवलपर्स को बाकी के लिए गेम खेलने दें। यह वास्तव में समय को पैड करने के लिए कॉपी-पेस्ट व्यस्तता का उपयोग करने के आपके सुझाव से बेहतर होगा, क्योंकि गेम खेलने से उत्पाद की स्थिरता कम नहीं होगी।

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

किसी भी मामले में, मैं आपकी धारणा पर विवाद करता हूं कि दोहराए गए मैनुअल काम स्वचालित की तुलना में अधिक अनुमानित है। सभी अनुभव बताते हैं कि दोहराए गए मैनुअल काम में त्रुटियों की अधिक संभावना है। और क्या होगा अगर कॉपी-पेस्ट किए गए कोड में बग की खोज की जाए? अचानक बग को ठीक करने की लागत को पुनरावृत्ति की मात्रा से गुणा किया जाता है, जिससे अनिश्चितता का विस्फोट होता है।

Comments

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

— जिमीजैम

@FrankPuffer मैं वहाँ गया हूँ। कितनी देर लगेगी? एक विकल्प यहां एक सीमा प्रदान करना है। PERT पर विशेष रूप से 3-बिंदु अनुमानों पर पढ़ें क्योंकि उन्हें पहले से ही इसके बारे में पता होना चाहिए। प्रतिशत पूर्ण? यह सबसे कष्टप्रद है। इसे नजरअंदाज करने की कोशिश करें लेकिन अगर आपको याद नहीं है कि यह प्रतिशत का समय है, लाइनों का प्रतिशत नहीं है या जो भी हो। वे वास्तव में जानना चाहते हैं कि यह कब पूरा होगा? जल्दी, प्रत्येक कार्य पर रूढ़िवादी भविष्यवाणियां दें और जाते ही परिष्कृत करें। आपको अधिक समय कहने के लिए अंतिम मिनट तक प्रतीक्षा करना लोगों को पागल कर देगा।

— जिमीजैम

कितनी देर लगेगी? मैं 60% निश्चित हूं कि हम इसे x द्वारा समाप्त कर सकते हैं, लेकिन 10% संभावना है कि इसमें पांच गुना लंबा समय लगेगा।

— डेविड

@ डेविड: यह शायद पीएम को पागल कर देगा क्योंकि वह अनुभव से जानता है कि यह 10% संभावना एक्टुएल 80% बार होती है :)

— फ्रैंक पफर

वास्तविकता यह है कि कई स्थानों पर एक परियोजना को जमीन में ट्रैक करना अच्छा लगेगा, फिर अप्रत्याशित रूप से सफल होगा। पीएम को अक्सर सटीक अनुमान लगाने के लिए पुरस्कृत किया जाता है ताकि उनके पास प्रोत्साहन हो। यह प्रिंसिपल-एजेंट की समस्या है ।

— स्लेज

Answer 2

आप सही हैं - कॉपी-पेस्ट बढ़िया काम करता है, और DRY का कोई मतलब नहीं है जब आपका कार्य एक प्रोग्राम तैयार करना है जिसके लिए या तो कॉपी किए गए टेम्पलेट या कॉपी को भविष्य में बनाए या विकसित नहीं करना होगा। जब उन दो सॉफ़्टवेयर घटकों में एक पूरी तरह से अलग जीवन चक्र होता है, तो उन्हें एक साथ साझा करके समान कोड को एक आम काम में बदल दिया जाता है जो कि भारी विकास के अंतर्गत होता है, वास्तव में प्रयास के लिए अप्रत्याशित प्रभाव हो सकते हैं। दूसरी ओर, जब एक प्रोग्राम या प्रोग्राम सिस्टम के अंदर कोड सेक्शन को कॉपी करते हैं, तो इन सभी हिस्सों में आमतौर पर एक ही जीवन चक्र होता है। मैं नीचे बताऊंगा कि DRY और परियोजना प्रबंधन के लिए इसका क्या अर्थ है।

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

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

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

उदाहरण

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

कार्य: एक आवेदन के लिए 100 अलग-अलग रिपोर्ट बनाते हैं, प्रत्येक रिपोर्ट बहुत समान दिखती है, रिपोर्ट के बीच कुछ आवश्यकता अंतर, कुछ अलग तर्क, लेकिन सभी सभी में, कई अंतर नहीं।

जिस देव को यह कार्य मिलता है वह पहले एक बनाता है (यह कहने में 3 दिन लगते हैं), क्यूए और ग्राहक के निरीक्षण के कारण कुछ बदलाव या मामूली बग ठीक होने के बाद, यह ठीक चलता है। फिर उन्होंने कॉपी-पेस्ट करके और पूरी चीज़ को संशोधित करके अगली रिपोर्ट बनाना शुरू कर दिया, फिर अगली, और प्रत्येक नई रिपोर्ट के लिए उन्हें औसतन ~ 1 दिन की आवश्यकता थी। पहली नजर में बहुत ही अनुमानित ...

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

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

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

Comments

संभवत: एक अच्छा उत्तर लेकिन अन्य अच्छे उत्तरों की तुलना में बहुत अच्छा है।

— विंस ओ'सूलीवन

आप DRY को अनदेखा कर सकते हैं जब "प्रतिलिपि को भविष्य में बनाए नहीं रखा जाएगा या विकसित नहीं किया जाएगा", लेकिन कोड जो कभी भी फिर से उपयोग नहीं किया जाएगा, वैसे भी अक्सर फिर से उपयोग होने वाली हवाएं।

— एंडी लेस्टर

"कॉपी-पेस्ट बढ़िया काम करता है ..." - असहमत! यहां तक ​​कि अगर कार्यक्रम एक-बंद है और प्रारंभिक रिलीज से आगे कभी नहीं बढ़ने की गारंटी है, तो कॉपी-पेस्ट कोड अभी भी कार्यक्रम के प्रारंभिक संस्करण के विकास के दौरान पाए जाने वाले कीड़े को ठीक करने के लिए बहुत अधिक काम और जोखिम बनाता है। जब तक आप कभी गलती नहीं करते हैं, जिस स्थिति में आप भगवान हैं।

— जैक्सबी

@JacquesB: आपको मेरे उत्तर को और ध्यान से पढ़ना चाहिए, मैंने कुछ अलग नहीं लिखा।

— डॉक ब्राउन

कंप्यूटर प्रोग्रामिंग असेंबली लाइन के साथ समान मशीनों के निर्माण से बस अलग है। हुह। किसने सोचा था कि ऐसा होगा? शायद हमारे पास प्रोग्रामर पीएम के रूप में काम करने वाले होने चाहिए। लेकिन फिर हमें प्रबंधकों के रूप में प्रोग्रामर की आवश्यकता होगी। शेयरधारकों के रूप में प्रोग्रामर। ग्राहकों के रूप में प्रोग्रामर ... शूट करें, बस सभी को सिखाएं कि कैसे प्रोग्राम किया जाए और इसके साथ क्या किया जाए। (दूसरे शब्दों में: गैर-विशेषज्ञ विशेषज्ञों द्वारा ज्ञात

Answer 3

तो एक परियोजना प्रबंधन के नजरिए से, किसी मौजूदा कोड को 100 बार कॉपी करके किसी काम को हल करना और प्रत्येक कॉपी में कुछ मामूली अनुकूलन करना बहुत अच्छा है, जैसा कि आवश्यक है। हर समय, आप वास्तव में जानते हैं कि आपने कितना काम किया है और कितना बाकी है। सभी प्रबंधक आपसे प्यार करेंगे।

आपका आधार दावा गलत है।

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

आखिरकार कंपनी को एहसास होगा कि वे एक अच्छे प्रोग्रामर को काम पर रखने के साथ एक ही समय में एक ही काम कर सकते हैं। और अगर वे नहीं करते हैं, तो उनके प्रतियोगी करेंगे।

Comments

मैं तर्क देता हूँ कि अधिकांश इंजीनियरिंग पेशे "हर दिन कुछ नया करने" के बारे में हैं

— ब्लूराजा - डैनी पफ्लुगुफ़े

@ BlueRaja-DannyPflughoeft: वास्तव में नहीं। एक इलेक्ट्रॉनिक्स / इलेक्ट्रिकल इंजीनियर के रूप में काम करने के बाद, मैं इस बात की गवाही दे सकता हूं कि अधिकांश बड़े पैमाने पर इंजीनियरिंग प्रोफेशन (वे प्रोजेक्ट जिन्हें जहाज और पॉवरप्लांट बनाने में कमीशन की आवश्यकता होती है) यह सुनिश्चित करने के बारे में है कि लोग कुछ करने की कोशिश करें और ठीक से परीक्षण करें। यही व्यवसाय "इंजीनियरिंग" पर विचार करता है। कुछ नया बनाना "आर एंड डी" है

— स्लीवेटमैन

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

— लुआं

@ लुआँ: हाँ, लेकिन इसमें से कोई भी कुछ नया नहीं कर रहा है। वे सभी "कुछ ऐसा कर रहे हैं जिसे हम जानते हैं कि कैसे करना है"। सॉफ्टवेयर का विकास अलग है। मुख्य रूप से क्योंकि सॉफ्टवेयर में, भौतिक इंजीनियरिंग परियोजनाओं के विपरीत, हम उन चीजों को एनकैप्सुलेट करते हैं जिन्हें हम पहले से ही जानते हैं कि पुस्तकालयों में कैसे करना है, इसलिए हमें मैन्युअल रूप से "सर्वेक्षण नहीं करना" आदि है। हम सिर्फ उसके लिए एक पुस्तकालय आयात करेंगे और उसका उपयोग करेंगे। ।

— स्लीपबेटमैन

@slebetman लगभग सभी सॉफ्टवेयर लिखे जा रहे हैं "कुछ हम जानते हैं कि कैसे करना है"। पुस्तकालय भी ऐसे वातावरण में रहते हैं जो हमेशा बदलता रहता है। और आपके पास पूरे पुस्तकालय के साथ 100% ज्ञान और अनुभव नहीं है, और उस पुस्तकालय की सभी निर्भरताएं और आपके पास अन्य निर्भरताएं हैं, और बहुत सारे अजीब सिस्टम और हार्डवेयर कॉन्फ़िगरेशन हैं जो बस एक उचित प्रणाली को काम करने से इनकार करते हैं काम। एनकैप्सुलेशन महान है, लेकिन यह अभी भी नरक के रूप में महंगा है और सर्वेक्षण के टन की आवश्यकता है। और इंजीनियरिंग में इनकैप्सुलेशन भी है - पूर्वनिर्मित ब्लॉक, आईसीएस आदि

— लुआं

Answer 4

कट-एंड-पेस्ट प्रोग्रामिंग अंततः परित्यक्त सॉफ्टवेयर की ओर ले जाती है। मैं एक बहुत बड़ी फोन कंपनी से वायरलाइन सेवाओं के ऑर्डर के लिए एक ठेकेदार था। सिस्टम को कट-एंड-पेस्ट किया गया विज्ञापन nauseum था क्योंकि सभी परीक्षण मैनुअल थे और वे किसी भी कार्य कोड को बदलना नहीं चाहते थे। सबसे बड़ी वृद्धि कोड की सैकड़ों लाइनों की एक नई प्रति के रूप में हो सकती है। मूल रूप से बारह शारीरिक रेखाओं के खातों को संभालने के लिए आवेदन लिखा गया था। बेशक यह सीमा कोड में सैकड़ों स्थानों पर बनाई गई थी। लगभग चार साल के कारोबार के बाद टीम ने पूछा कि बड़े खातों को संभालने में क्या लगेगा। उन्होंने लगभग $ 18 मिलियन का अनुमान लगाया। उस समय परियोजना को न्यूनतम रखरखाव के लिए एक अपतटीय टीम में बदल दिया गया था। मौजूदा टीम को बंद कर दिया गया था।

इस तरह से सोचने वाले संगठनों को बेहतर प्रौद्योगिकी वाली कंपनियों द्वारा कुचल दिया जा रहा है।

Comments

यह बेहतर तकनीक के बजाय बेहतर दिमाग है। तकनीक दिमाग से आती है, है ना? जो कुछ भी "थिंक स्माइटर, कठिन नहीं" हुआ?

Answer 5

एक आम भूल अधिकतम कि यहां लागू होता है 3 का नियम है । यह बताता है, कि कोड को एक बार कॉपी करना ठीक है, लेकिन इससे परे इसे जेनेरिक कोड से बदल दिया जाना चाहिए।

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

जबकि DRY कोड का होना अच्छा है, ऐसे समय हो सकते हैं जब व्यापार तर्क एक अपवाद को निर्धारित करता है और इसलिए आपको स्रोत से दो या अधिक बिट कोड बनाने होंगे जो पहले सामान्य थे।

इसलिए क्या करना है? यथास्थिति (आखिरकार, YAGNI ) के लिए कोड । जबकि कोड को संशोधन में आसानी के लिए लिखा जाना चाहिए, घंटियों और सीटियों की एक पूरी बेड़ा लिखने के लिए, जिसकी जरूरत नहीं हो सकती है, वह सिर्फ पैसे की तंगी है।

Comments

ध्यान दें कि इसका मतलब है कि आपको टिप्पणी करनी चाहिए कि आपने कोड (दोनों स्थानों पर) कॉपी किया है ताकि आपको पता चल जाए कि क्या आप इसे फिर से कॉपी करने वाले हैं, तो आपको नहीं करना चाहिए!

— मार्क हर्ड

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

— Jeutnarg

@ मर्कहर्ड येप - महान बिंदु ...

— रोबी डी

Answer 6

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

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

Comments

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

— फ्रैंक पफर

@FrankPuffer मैं असहमत हूं कि परियोजना प्रबंधक की भूमिका व्यक्ति को विशेष निर्णय लेने में मजबूर करती है। यह एक शैक्षिक या संगठनात्मक बल की अधिक संभावना है। मैंने जो देखा है, उसमें से अधिकांश परियोजना प्रबंधन शिक्षा सॉफ्टवेयर परियोजना प्रबंधन तकनीकों की तुलना में अधिक परंपरागत परियोजना प्रबंधन तकनीकों (शायद इसलिए कि वे अधिक परियोजनाओं पर लागू होती हैं) पर केंद्रित है। यह उन संगठनों में खून बहा सकता है जो इसकी अपेक्षा करते हैं और सॉफ्टवेयर विकास जैसे ज्ञान कार्य परियोजनाओं के प्रबंधन के लिए अन्य तकनीकों को नहीं देखते हैं।

— थॉमस ओवेन्स

@FrankPuffer निश्चित रूप से यह कठिन है, लेकिन यह अधिक मूल्य प्रदान करता है। यदि आपके मालिक का बॉस काफी स्मार्ट है, तो वह उस प्रबंधक से छुटकारा पा लेगा जो "खुद के लिए चीजों को आसान बनाने" की कोशिश करता है और किसी ऐसे व्यक्ति को ढूंढता है जो वास्तव में अपना काम कर सकता है। , मुझे गलत मत करो अगर चीजें बनाने आसान मूल्य प्रदान करता है, इसके लिए जाना - लेकिन आप जो वर्णन में, यह करने के लिए लगभग निश्चित रूप से है हानि अंत मूल्य की।

— लुआं

Answer 7

नया कोड लिखना कार्य का एक छोटा सा हिस्सा है

आपके सुझाव से शुरू में नए कोड लिखने के हिस्से का अनुमान लगाना आसान हो जाएगा। हालांकि, वास्तव में कुछ भी नया लाने के लिए (कोई फर्क नहीं पड़ता कि यह एक बिल्कुल नई प्रणाली है, फीचर का एक अतिरिक्त या कार्यक्षमता का एक परिवर्तन) ऐसा करना पर्याप्त नहीं है और सिर्फ काम का अल्पसंख्यक है - साहित्य में देखे गए अनुमान बताते हैं कि व्यवहार में यह हिस्सा कुछ ऐसा है जैसे कुल काम का 20% -40%।

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

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

Comments

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

— फ्रैंक पफ़र

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

Answer 8

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

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

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

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

Comments

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

— फ्रैंक पफ़र

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

— ब्रैड थॉमस

हो सकता है कि प्रोग्रामर को प्रबंधकों से अधिक परिमाण के आदेश का भुगतान किया जाना चाहिए?

Answer 9

मुझे लगता है कि आप DRY को गलत समझ रहे हैं।

आइए एक उदाहरण का उपयोग करें:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

बनाम

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

C के साथ वर्ग B को बदलकर हमने DRY सिद्धांत का पालन किया है और कोड दोहराव को कम किया है। लेकिन हमने परियोजना के लिए अज्ञात या जोखिम नहीं बढ़ाया है (जब तक कि आपने पहले कभी विरासत में नहीं किया है)।

मुझे लगता है कि जब आप DRY के बारे में बात करते हैं तो आपका मतलब कुछ और होता है जैसे कि डिजाइन का काम। अर्थात:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! नई आवश्यकता! कुछ ग्राहकों को दोगुना गुणा करने में सक्षम होना चाहिए !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

बनाम

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

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

तो, क्या हमें इस मामले में बी या ए 2 संस्करण लेना चाहिए?

• बी कम साइड इफेक्ट के साथ वास्तविक अनुरोधित परिवर्तन के लिए अधिक विशिष्ट होने जा रहा है और अनुमान लगाने में आसान और करने में तेज है।

• एक संस्करण 2 के परिणामस्वरूप कम समग्र कोड आगे बढ़ेगा और अधिक सुरुचिपूर्ण समाधान होगा

फिर से मैं कहने जा रहा हूं कि यह विनिर्देश और आवश्यकताओं की गुणवत्ता के लिए नीचे आता है।

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

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

Comments

मैं सहमत नहीं हूँ। वंशानुक्रम वह चीज नहीं है जिसे आप एक बार करते हैं और फिर उसमें महारत हासिल करते हैं। बहुत सारे नुकसान हैं। ऐसे कारण हैं कि रचना को वंशानुक्रम पर प्राथमिकता दी जानी चाहिए। तो हमें एक निर्णय करना होगा: विरासत? संरचना? कुछ और? यह निर्णय वास्तविक दुनिया में शायद मुश्किल होगा। दूसरे उदाहरण में भी बहुत सारे विकल्प हैं। जेनरिक / टेम्प्लेट के बारे में क्या? ओम्ब्रे शायद लैम्बदास का उपयोग कर कुछ कार्यात्मक दृष्टिकोण? फिर से: संभावनाओं के बहुत सारे जिनमें से प्रत्येक विशिष्ट प्रभाव होगा।

— फ्रैंक पफर

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

— इवान

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

Answer 10

अनुच्छेद द्वारा अनुच्छेद

सॉफ्टवेयर विकास के सबसे बुनियादी और व्यापक रूप से स्वीकृत सिद्धांतों में से एक DRY है (अपने आप को दोहराएं नहीं)। यह भी स्पष्ट है कि अधिकांश सॉफ्टवेयर परियोजनाओं के लिए किसी प्रकार के प्रबंधन की आवश्यकता होती है।

सही बात।

अब ऐसे कौन से कार्य हैं जिन्हें प्रबंधित करना आसान है (अनुमान, अनुसूची, नियंत्रण)? सही, दोहराए जाने वाले कार्य, बिल्कुल वही कार्य जिन्हें DRY के अनुसार टाला जाना चाहिए।

दोहराए जाने वाले कार्य स्वचालित, अनिवार्य होने चाहिए । वे उबाऊ हैं, त्रुटि प्रवण, जब हाथ से बनाया जाता है।

तो एक परियोजना प्रबंधन के नजरिए से, किसी मौजूदा कोड को 100 बार कॉपी करके किसी काम को हल करना और प्रत्येक कॉपी में कुछ मामूली अनुकूलन करना बहुत अच्छा है, जैसा कि आवश्यक है। हर समय, आप वास्तव में जानते हैं कि आपने कितना काम किया है और कितना बाकी है। सभी प्रबंधक आपसे प्यार करेंगे।

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

• पहले मूल स्रोत में कोड को ठीक करें;
• हर दूसरी जगह कोड को ठीक करें;
• सुनिश्चित करें कि वे सभी स्थान थे। जब आप कहते हैं कि यह प्रबंधक को किया जाना था, तो वह शायद कम से कम किसी से नफरत करेगा।

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

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

बेशक मैं अतिशयोक्ति कर रहा हूं, लेकिन स्पष्ट रूप से एक दुविधा है। मेरे प्रश्न हैं: यदि कोई डेवलपर DRY को ओवरडोज़ कर रहा है, तो यह तय करने के लिए मानदंड क्या हैं? हम एक अच्छा समझौता कैसे पा सकते हैं? या इस दुविधा को पूरी तरह से दूर करने का एक तरीका है, न कि केवल एक समझौता खोजने से?

बहुत सारे लोगों ने बताया कि यहां कोई दुविधा नहीं है। हां और ना।

यदि आपके पास कुछ अत्यधिक प्रयोगात्मक है जो किए जाने से पहले कभी नहीं हुआ है - कोई दुविधा नहीं है। अन्यथा यदि आपके पास कुछ ऐसा है जो फिर से किया जाना है, जैसे नई बुकिंग प्रणाली में आपके पास पहले से ही सार है, तो बस यह निर्भर करता है कि आपको क्या चाहिए।

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

Comments

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

Answer 11

यह भविष्य के पुन: उपयोग के लिए या YAGNI सिद्धांत के बारे में डिजाइन करने के बारे में बिल्कुल नहीं है। यह वर्तमान कार्य पैकेज में कोड को दोहराने के बारे में है।

यह बिल्कुल डिजाइन के बारे में है। शायद फिर से प्रति उपयोग नहीं , लेकिन फिर भी डिजाइन।

यदि कोई डेवलपर DRY को ओवरडोज़ कर रहा है, तो यह तय करने के लिए मानदंड क्या हैं?

अनुभव और अपने मौजूदा वातावरण / स्थिति। दी गई समस्या के लिए आपको प्राडो सिद्धांत का एक मजबूत अर्थ मिलेगा क्योंकि आप DRYness के अधिक से अधिक डिग्री का प्रयास करते हैं। फिर अचानक प्रबंधन के विचार खेलने के लिए आते हैं। समय, लक्ष्य, ग्राहक, दीर्घकालिक कोड प्रबंधन (किसी ने तकनीकी ऋण कहा ), आदि आपके हमले की योजना को सूचित करेंगे।

हम एक अच्छा समझौता कैसे पा सकते हैं?

उह ... डिजाइन? Refactoring डिजाइन है, अच्छी तरह से यह माना जाता है। DRYing का दायरा आसानी से लूप से सुपर नोवा की तरह विस्तार कर सकता है, विधि से, क्लास (एस) तक। वहाँ किया गया था कि। लेकिन आप वास्तव में तब तक नहीं जान सकते जब तक आप समस्या का अध्ययन नहीं करते - यह डिजाइन है।

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

उपसंहार

... संदर्भित प्रश्न और इसके उत्तर परियोजना प्रबंधन पहलू को कवर नहीं करते हैं।

विशिष्ट प्रबंधन, डिजाइन समय की अनदेखी। हमारे पास आदर्श रूप से, कोडिंग से पहले सुपरफ्लुंडली निरर्थक दोहराव को तैयार किया जाएगा। इसके बजाय, प्रबंधन को लगता है कि विकास (और बग फिक्स) एक एकल ओलंपिक घटना है - कोडिंग - जब यह वास्तव में एक डिकैथलॉन है। और वे एक सेकंड का 1/1000 मापते हैं क्योंकि उन्हें लगता है कि यह सब एनालॉग है।

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

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

अधिकांश समय, आप वास्तव में यह नहीं कह सकते कि कितना काम बाकी है। आप एक प्रोजेक्ट मैनेजर के बुरे सपने हैं।

मैं या तो नहीं जानता था, लेकिन मुझे विश्वास था कि सामने वाला डिजाइन प्रयास बंद कर देगा। हम सभी यह कहते हैं, लेकिन प्रबंधन विशेष रूप से इस पर भरोसा नहीं करता है। प्रबंधन ने सोचा होगा कि मैं चारों ओर से पंगा ले रहा हूं। "दो दिन और आपके पास अभी तक इसका 2% भी कोड नहीं है!"

एक मामले में हम अपनी बंदूकों से चिपक गए जब प्रबंधन ने कहा "आप डिजाइन में बहुत समय बिता रहे हैं, जा रहे हैं।" और सह-कार्यकर्ता कह रहे हैं "यह बहुत अधिक कक्षाएं हैं।" खैर, एक कम जटिल उप-परियोजना के बारे में 1 महीने लगने वाला था (मुझे लगा कि यह ठीक है बॉलपार्क का अनुमान था) लेकिन 5 महीने लग गए। 3 महीने का यह परीक्षण / फिक्सिंग में था क्योंकि यह एक ऐसी स्थिति थी। "लेकिन हमारे पास डिजाइन करने का समय नहीं था!"। उन्होंने वास्तव में ऐसा कहा था।

मेरे प्रश्न हैं: यदि कोई डेवलपर DRY को ओवरडोज़ कर रहा है, तो यह तय करने के लिए मानदंड क्या हैं? हम एक अच्छा समझौता कैसे पा सकते हैं? या इस दुविधा को पूरी तरह से दूर करने का एक तरीका है, न कि केवल एक समझौता खोजने से?

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

Comments

"एक माइक्रोमीटर से मापें, चाक के साथ चिह्नित करें, एक कुल्हाड़ी के साथ काटें।"