कोड स्थिरता और कोड सुधार के बीच सही संतुलन क्या है?

Question

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

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

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

तो, कोड शैली का पैटर्न किस सीमा तक है, और हमें लगातार रहने और सुधार करने के बीच की रेखा कहाँ खींचनी चाहिए?

Comments

तो कैसे कोड गुणवत्ता में सुधार होगा, अगर हर कोई खुद को "खराब" तरीके से प्रतिबंधित करता है?

— इज़काता

संभव डुप्लिकेट आपको कैसे पता चलेगा कि आपने पठनीय और आसानी से बनाए रखने योग्य कोड लिखा है?

— gnat

जब आप LINQ लिखते हैं तो आपको SQL से LINQ का मतलब नहीं है? यदि हाँ तो मैं आपके मित्र से सहमत हो सकता था। अगर आप LINQ के बारे में बात कर रहे हैं तो मैं उससे सहमत नहीं हूँ। हर किसी को इन दिनों LINQ से परिचित होना है। यह उनकी पसंद नहीं है। उन्हें परिचित होने के लिए भुगतान किया जाता है।

— पियोट्र पर्क

@Peri का मतलब सिर्फ बुनियादी LINQ था - मुझे लगता है कि मेरा उदाहरण IEnumerableDAO के बजाय s के साथ काम करने के बारे में होना चाहिए था ।

— रॉबर्ट जॉनसन

ICYMI - दिलबर कॉमिक इस विषय पर: dilbert.com/strips/2013-09-21

— जिम बेथनकोर्ट

Answer 1

अधिक सामान्य उत्तर देने के लिए:

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

• "सही" तरीका कितना फायदेमंद है?

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

• एक समस्या कितनी बड़ी असंगति पैदा करेगी?

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

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

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

Comments

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

— जियोर्जियो

@Giorgio, प्रतिक्रिया के लिए धन्यवाद; मैंने अंतिम बिंदु की भाषा को बदल दिया।

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

— मैट

+1। सहमत, एक संपूर्ण और संतुलित उत्तर - विभिन्न परिदृश्यों का अच्छा विचार। फिर, जियोर्जियो से अच्छी टिप्पणी।

— रॉबर्ट जॉनसन

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

— जियोर्जियो

Answer 2

लगातार बने रहना मेरे परिप्रेक्ष्य में बहुत कम है; लगातार सुधार करना बहुत जरूरी है।

आपके सहयोगी की स्थिति वास्तव में नवीनता को बाधित करती है। स्थिरता तर्क आपको एक ऐसी स्थिति में ले जाता है जहां आप उपयोग कर सकते हैं, उदाहरण के लिए, LINQ केवल यदि आप LINQ का उपयोग करने के लिए सभी कोड माइग्रेट करते हैं। और ठीक है, हमारे पास इसके लिए समय नहीं है, क्या हम?

मेरे पास असंगतता होगी जहां कुछ कोड अभी भी foreachArrayLists पर काम कर रहे हैं और अन्य भागों LINQ का उपयोग करते हैं IEnumerable<T>, समय के अंत तक चीजों को करने के सबसे पुराने तरीके से चिपके रहने के बजाय।

प्रासंगिक बने रहने और चीजों को करने के नए तरीके सीखने की जिम्मेदारी आपके सहयोगियों की है।

Comments

"यह आपके सहयोगियों की जिम्मेदारी है कि वे प्रासंगिक रहें और चीजों को करने के नए तरीके सीखें।": एक संभावना नए कोड (नए मॉड्यूल) में नए मुहावरों और पुस्तकालयों का उपयोग करने और विरासत कोड में एक सुसंगत शैली रखने की है।

— जियोर्जियो

Answer 3

API की स्थिरता बहुत महत्वपूर्ण है, दोनों सार्वजनिक और आंतरिक API के लिए।

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

नामकरण सम्मेलनों के अनुरूप होना चाहिए, स्थानीय चर आदि जैसी चीजों के लिए भी।

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

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

---

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

और कोड के साथ काम करने वाले प्रत्येक डेवलपर को अद्यतित रहना चाहिए, इसलिए किसी भी .NET डेवलपर को LINQ पता होना चाहिए, और यदि वे नहीं चाहते हैं तो उन्हें सीखने के लिए मजबूर किया जाना चाहिए, अपने स्वयं के अच्छे के लिए (आप कभी नहीं जानते कि आप कब एक नए की तलाश करेंगे इस व्यवसाय में नौकरी, एक कारण या किसी अन्य के लिए)।

Answer 4

इसका उत्तर सरल है।

संगति का सर्वाधिक महत्व है।

लेकिन यह एक चेतावनी के साथ आता है ...

आप और आप सहकर्मी के बीच गलत तरह की संगति की संभावना है

कार्यान्वयन डिस्पोजेबल हैं। टेस्ट सूट की गुणवत्ता और व्यापकता के आधार पर उन्हें आसानी से अलग-अलग डिग्री के साथ ओवरहाल किया जा सकता है। "क्या यह एक संपत्ति होनी चाहिए?" जैसी चीजों के बारे में चिंता करते हुए, "क्या निचले स्तर के निर्माण के बजाय thins कोड को LINQ का उपयोग नहीं करना चाहिए?" संदिग्ध मूल्य का है। कार्यान्वयन के स्तर पर स्थिरता के मूल्य के लिए किसी भी माप को टाई करने के लिए इसकी भिन्नता है। इस स्तर पर पूछने के लिए एक बेहतर सवाल है "क्या यह कोड विज्ञापन के रूप में काम करता है?"। टीएल; डीआर कार्यान्वयन स्थिरता वह है जहां "छोटे दिमाग" को अपनी हॉबोब्लिन मिलती है।

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

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

एपीआई डिस्पोजेबल नहीं हैं।

यह सभी API कोड स्तर, वेब सेवाएँ, SDKs आदि हैं। ये, MUST, सुसंगत होना चाहिए। इस विभिन्नता से उत्पादकता लाभ कई कारणों से बहुत अधिक हैं:

एकीकरण टेस्ट:

यदि आप अपने एपीआई के अनुरूप रहते हैं तो आप एकीकरण परीक्षणों के सूट बना सकते हैं। ये डेवलपर्स को कार्यान्वयन विवरणों को स्वतंत्र रूप से स्वैप करने और तत्काल सत्यापन प्राप्त करने की अनुमति देते हैं। LINQ पर अपने को-वर्क्स क्रैप को स्वैप करना चाहते हैं? क्या एकीकरण परीक्षण चलते हैं? यह उत्पादन में जाने की तैयारी करते समय सत्यापन भी प्रदान करता है। क्योंकि कंप्यूटर तेज हैं एक लैपटॉप एक हजार परीक्षकों के काम को रोक सकता है जो सांसारिक कार्यों को अंजाम दे रहा है। अपने संगठन के हेडकाउंट को बढ़ाने के लिए इसका टेंटमाउंट काफी है।

उत्पादकता

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

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

निष्कर्ष

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

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

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

Answer 5

LINQ से अपरिचित? यदि ऐसा है, तो क्या मेरा कोड मेरे साथी डेवलपर्स के लिए अधिक रखरखाव योग्य नहीं होगा अगर मैंने इसका उपयोग नहीं किया?

C # भाषा अभी भी विकसित हो रही है। यदि लोगों ने C # 1 से परिवर्तन नहीं सीखा, तो वे लापता हो जाएंगे:

• जेनेरिक्स
• partials
• अनाम तरीके
• iterators
• अशक्त प्रकार के
• ऑटो गुण
• अनाम प्रकार
• एक्सटेंशन के तरीके
• एक प्रकार का वृक्ष
• lambdas
• अतुल्यकालिक तरीके

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

लिनक जीवन को आसान बनाता है। जहां आप कर सकते हैं वहां इसका उपयोग करें। आप अपनी टीम के सदस्यों को प्रेरित कर सकते हैं।

तो, कोड शैली का पैटर्न किस सीमा तक है, और हमें लगातार रहने और सुधार करने के बीच की रेखा कहाँ खींचनी चाहिए?

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

Comments

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

— रॉबर्ट जॉनसन

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

— एंडी

Answer 6

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

इस तरह, आप निरंतरता के अधिकांश लाभों को पुनः प्राप्त करते हैं (विशेष रूप से, यह कोई फर्क नहीं पड़ता कि कोड कौन लिखता है), लेकिन टीम को दूसरे तरीके से काम करके स्पष्ट लाभ देखने पर भी सुधार हो सकता है।

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

Answer 7

मुझे लगता है कि एक परियोजना में कोड शैली का पालन करना महत्वपूर्ण है जैसे। नामकरण सम्मेलनों, मांगपत्र आदि।

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

बेशक इन चीजों का उपयोग करने के लिए अच्छे कारण होने चाहिए। यदि उपयुक्त हो, तो प्रदर्शन या संक्षिप्तता।

Comments

माइनस किस लिए था?

— ओज

Answer 8

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

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

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

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

Answer 9

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

Comments

के लिए downvote क्या था?

— चींटी

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

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

— एंट