क्या मुझे अपने कार्यस्थल पर स्थापित सम्मेलनों का पालन करने के लिए एक खराब कोडिंग शैली का पालन करना चाहिए?

Question

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

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

क्या मुझे मौजूदा फ़ंक्शन की शैली के अनुसार एक विशाल फ़ंक्शन में सब कुछ रखना चाहिए, या क्या मुझे अपने स्वयं के कार्यों में अलार्म को इनकैप्सुलेट करना चाहिए?

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

संक्षेप में, मैं तुलना कर रहा हूं

showAlarms(){
    // tons of code
}

विरुद्ध

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

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

अद्यतन करें: वे वास्तव में कोड के साथ खुश थे और एक से अधिक लोगों ने इस मिसाल को स्थापित करने के लिए मुझे धन्यवाद दिया।

Comments

यह अत्यधिक संदेहास्पद है कि जिस कंपनी के लिए आप काम करते हैं, वह स्थिति लेती है कि आपके कार्य 300 रेखाओं के लंबे होने चाहिए क्योंकि "यही तरीका है जो हमने हमेशा किया है।" यह "कोडिंग स्टाइल कन्वेंशन नहीं है;" यह सिर्फ खराब शैली है।

— रॉबर्ट हार्वे

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

— सेवाकाल

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

— सेवाकाल

अच्छी या बुरी शैली के बारे में अक्सर तर्क दिया जाता है और अक्सर सहमति व्यक्त की जाती है। विश्वविद्यालय शिक्षण यह है कि कार्य कम होना चाहिए लेकिन यदि यह अर्थ अस्पष्ट है, तो ऐसा न करें। नियमों के एक सेट के बिना परीक्षण के बजाय परीक्षण स्पष्टता होना चाहिए।

— जल्‍दी से जल्‍दी से जल्‍दी

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

— जैक्सबी

Answer 1

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

मैं व्यक्तिगत रूप से मिशन-क्रिटिकल कोडिंग में अपने पहले कदम पर, व्यक्तिगत रूप से इसमें भाग गया। मैंने इस तरह कोड देखा:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

उज्ज्वल और चमकदार OO C ++ डेवलपर होने के नाते, मैंने तुरंत उन्हें RAII का उपयोग करने के बजाय म्यूटेक्स को मैन्युअल रूप से लॉक और अनलॉक करके बग जोखिमों पर बुलाया था । मैंने जोर देकर कहा कि यह बेहतर था:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

बहुत आसान है और यह सुरक्षित है, है ना ?! जब सभी कंपाइलर आपके लिए यह कर सकते हैं तो डेवलपर्स को अपने म्यूटेक्स को सभी नियंत्रण प्रवाह पथ पर अनलॉक करने की आवश्यकता क्यों है!

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

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

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

Comments

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

— केल्विन

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

— डॉक्टर ब्राउन

@DocBrown सिर्फ इसलिए कि वे तकनीकी नहीं हैं इसका मतलब यह नहीं है कि वे कारण नहीं हैं। डेवलपर्स के लिए यह याद रखना महत्वपूर्ण है कि वे एक बड़ी मशीन का एक हिस्सा हैं। (मैं उस पाठ को पुनः प्राप्त करने के लिए जितनी बार मैंने गणना की है, वह गिन नहीं सकता)

— Cort Ammon

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

— कोरट अमोन

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

— Cort Ammon

Answer 2

ईमानदारी से, क्या आपको लगता है कि ऐसे फ़ंक्शंस हैं जिनका उपयोग करना मुश्किल है, 300 लाइनों के साथ, क्या यह केवल स्टाइल की बात है? तो खराब उदाहरण के बाद समग्रता बेहतर होने के कारण समग्र कार्यक्रम को बेहतर स्थिति में रख सकते हैं? मुझे लगता है कि आप ऐसा नहीं मानते हैं, अन्यथा आपने यहां यह सवाल नहीं पूछा होता।

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

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

Comments

यहां तक ​​कि सक्षम प्रोग्रामर इन अपराधों को तब करते हैं जब तंग समय सीमा के तहत।

— बागीचा

@gardenhead, मैं समझ सकता हूँ कि समय बचाने के लिए 300-लाइन फ़ंक्शन को फिर से तैयार नहीं किया जा सकता है, लेकिन ऐसा कोई संभव तरीका नहीं है कि 300-लाइन फ़ंक्शन लिखने से आपका समय बच जाएगा।

— डांग

@gardenhead: जब मैं किसी सर्जन के पास जाता हूं, क्योंकि मुझे तत्काल मदद की जरूरत होती है, तब भी मैं उससे उम्मीद करता हूं कि वह मुझ पर प्रदर्शन करने से पहले हाथ धोने के लिए समय निकाले। यह कुछ ऐसा है जो बहुत से लोगों को वास्तविक योग्यता हासिल करने के लिए हमारे व्यवसाय में सीखना है : हमेशा पहले से बेहतर स्थिति में कोड छोड़ दें, और यह भी समय सीमा रखने की क्षमता में सुधार करेगा। 300 लाइनें फ़ंक्शन आम तौर पर दिन-प्रतिदिन बढ़ते हैं, उन लोगों द्वारा, जो परवाह नहीं करते हैं, और वे हमेशा एक बहाने के रूप में "समय सीमा" का उपयोग करेंगे।

— डॉक्टर ब्राउन

@ डैंग्फ यह समय बचाता है जब आप फ़ंक्शन को केवल 5 पंक्तियों को जोड़ने के बजाय इसे फिर से चालू करते हैं। वे आमतौर पर तब बढ़ते हैं जब प्रारंभिक फ़ंक्शन लंबी (30+ लाइनें) होती है और अगला प्रोग्रामर सोचता है कि "यह मेरा कोड नहीं है, मैं इसे तोड़ने के लिए नहीं मना करूंगा, बस यहां और वहां कुछ लाइनें जोड़ें"।

— दंड

@ न्याय, जैसा कि मैं इसे समझता हूं, सवाल एक नया कार्य बनाने के बारे में है, मौजूदा लोगों को फिर से तैयार करने का नहीं। यदि आप एक नया फ़ंक्शन लिख रहे हैं, तो आप इसे एकल मॉन्स्टर फ़ंक्शन में बनाकर समय नहीं बचाएंगे।

— १६

Answer 3

नहीं।

प्रोगैमैटिक प्रोग्रामर पुस्तक में लेखक ब्रोकन विंडो थ्योरी के बारे में बात करता है ।

यह सिद्धांत स्थिति:

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

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

पुस्तक में लेखक इस सिद्धांत और कोड के बीच एक समानांतर लिखता है। एक बार जब आपको इस तरह का कोड मिल जाता है तो आप रुक जाते हैं और अपने आप से सवाल करते हैं कि बहुत ही सवाल

और जवाब नहीं है।

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

और एक दिन कोड को कोलाज होगा।

हर किसी को क्लीन कोड और क्लीन कोडर की कॉपी दें ।

और जब आप विषय में होते हैं, तो TDD की एक प्रति भी एक अच्छी होती है।

Comments

क्या होगा अगर कोडबेस कुछ भी नहीं बल्कि टूटी खिड़कियों के साथ एक ग्रीनहाउस है?

— एलन शटको

@AlanShutko फिर सुनिश्चित करें कि आपका रिज्यूमे चालू है? अब एक अलग नियोक्ता खोजें ।

— डेविड मोंटगोमरी

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

— डॉक्टर ब्राउन

वाह, क्या एक मनमाना सादृश्य "टूटी खिड़की" सिद्धांत लगता है।

— समर्थ

टीडीडी का इससे कोई लेना-देना नहीं है। चाहे आप बिजनेस / डोमेन / टेस्ट / नॉनवेज ड्राइवर डिज़ाइन पर जा रहे हों, जो क्लीन कोड की मूल बातों का पालन करने के बारे में कुछ भी नहीं बदलता है। क्षमा करें, लेकिन 'TDD' को हर जगह उद्धृत करते देखना वाकई थका देने वाला है, जहां यह विषय में भी नहीं है

— Walfrat

Answer 4

हाँ, इसके लिए जाओ। संरचना! = शैली

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

सावधान रहे

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

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

नेक बनो

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

Comments

"एक प्रवाह से चिपकने की कोशिश करें जो उन लोगों को समझ में आएगा जो पुरानी शैली के अभ्यस्त हैं।" - तो, ​​क्या आपकी सलाह उसी तरह से प्रोग्राम करने की है जैसी कि पहले जो भी अक्षम व्यक्ति करता था? 300 लाइनों के फंक्शन को जोड़ना आसान बनाने वाला नहीं है।

— B47овиЈ

मैंने ऐसा प्रवाह करने के लिए नहीं कहा जो समान हो। मैंने कहा कि एक प्रवाह के लिए छड़ी जो वे समझेंगे।

— जॉन वू

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

— पीटर ए। श्नाइडर

Answer 5

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

Comments

" कोई कारण नहीं है, यह सिर्फ हमारी नीति है। "

Answer 6

इसका जवाब कोड समीक्षा में है।

असली सवाल यह है कि यदि आप अच्छी तरह से फैक्टर कोड में बदल जाते हैं, तो क्या आप इसके साथ काम करने के लिए तैयार हैं?

मैं, यहां के अधिकांश लोगों की तरह, विश्वास करता हूं कि 300 पंक्ति कार्य एक घृणा है। हालाँकि, विंडेक्स को लैंडफिल पर ले जाना बहुत अच्छा नहीं है। समस्या कोड नहीं है, यह कोडर्स है।

बस सही होना ही काफी नहीं है। आपको इस शैली पर लोगों को बेचने की आवश्यकता है। कम से कम इसे पढ़ने पर। यदि आप इस गरीब आदमी की तरह अंत नहीं करते हैं: निकाल दिया क्योंकि आपके कौशल अपने सहकर्मियों से बहुत ऊपर हैं

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

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

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

Comments

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

— ब्रैंडन

मैं आपको बता सकता हूं कि अगर मुझे प्रति समारोह सीमा की लाइनों पर चर्चा करने के लिए बैठकों की एक श्रृंखला के लिए आमंत्रित किया गया था, तो मुझे ऐसी बैठकों से बचने का एक तरीका मिलेगा। कोई सही संख्या नहीं है और आप कभी भी लोगों से सहमत नहीं होंगे। कभी-कभी, लोगों को बेहतर तरीके से दिखाने की आवश्यकता होती है ।

— ब्रैंडन

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

— JDługosz

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

— कैंडिड_ऑरेंज

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

— ब्रैंडन

Answer 7

कभी-कभी आपको प्रवाह के साथ जाना पड़ता है।

जैसा कि आपने कहा था कि आपको मौजूदा कार्यशील कोडबेस में एक फ़ंक्शन को लागू करने का काम सौंपा गया है।

गंदगी के बावजूद, और मैं समझता हूँ कि यह साफ करने के लिए आकर्षक है। लेकिन व्यापार की दुनिया में आपके पास कोड को रिफलेक्टर करने का मौका नहीं होता है।

मैं कहूंगा कि आप वही करें जो आपको करने और आगे बढ़ने के लिए कहा गया है।

यदि आपको लगता है कि यह टीम के साथ चर्चा के लिए इसे वापस लाने की आवश्यकता है, तो इसे फिर से बेचना या पुनर्लेखन के लायक है।

Comments

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

— ब्रैंडन

ओपी को एक फ़ंक्शन लिखने के लिए कहा गया है जो कोड की सैकड़ों लाइनों को संशोधित नहीं कर रहा है

— मेडा

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

— roetnig

"अगर यह नहीं टूटा है, तो इसे ठीक न करें।" मेरे पास 20 साल पुरानी कार है जो थोड़ा सा तेल लीक करती है। पैसे खर्च करने के लायक? सं विश्वसनीय? हाँ।

Answer 8

यह कथन बनाने से पहले कि प्रथाएं खराब हैं, मैं सबसे पहले बड़े तरीकों और अन्य प्रथाओं के कारण को समझने की दिशा में एक कदम उठाऊंगा, जो बुरे हो सकते हैं।

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

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

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

Comments

Im वर्तमान कोड को पुनःप्राप्त नहीं कर रहा हूं, मैं सिर्फ एक नया फ़ंक्शन लिख रहा हूं, यह सुनिश्चित नहीं है कि अगर मुझे सिर्फ 'सम्मेलन' का पालन करना चाहिए और इसे 300+ लाइन की एकरूपता में कोड करना चाहिए या इसे तार्किक विखंडू में तोड़ देना चाहिए जैसे मैं सामान्य रूप से करता हूं, लेकिन कोड बेस के इस भाग में नहीं किया गया है।

— जस्टिन

क्या आपके पास यह सुनिश्चित करने के लिए नियम हैं कि आप 300+ लाइनों में नए तरीके लिखें? यदि नहीं, तो मैं इसे सही तरीके से लिखूंगा। लेकिन मैं यह सुनिश्चित करने के लिए अपने रास्ते से बाहर जाऊँगा कि मैं शाखाओं सहित उनका परीक्षण करूँ। मैं इसी तरह के अनुभवों से गुजरा हूं और आमतौर पर आप उन्हें जीतते हैं। चाल समय के साथ यह करना है और तालमेल का निर्माण करना है।

— १६:१६ को

Answer 9

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

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

1. क्या यह एक जानबूझकर डिजाइन निर्णय आपकी वर्तमान टीम द्वारा समर्थित है?
2. क्या वे चाहते हैं कि आप इस शैली का अनुसरण करें?

इसे ढूंढने का केवल एक तरीका है। पूछो ।

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

Comments

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

— रोब

Answer 10

"शैली" के विभिन्न स्तर हैं।

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

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

फिर परियोजना द्वारा उपयोग में आने वाले पुस्तकालय और ढांचे हैं।

कभी-कभी फ़ंक्शन आकार पर अधिकतम सीमा होगी। लेकिन शायद ही कोई न्यूनतम सीमा हो! इसलिए, आपको यह पता लगाना चाहिए कि इनमें से कौन सी शक्तियाँ महत्वपूर्ण मानी जाती हैं, और इसका सम्मान करने का प्रयास करें।

आपको यह पता लगाने की आवश्यकता है कि क्या टीम मौजूदा कोड को फिर से तैयार करने के लिए प्रतिकूल है, जिसे संभव होने पर नए कोड को जोड़ने के लिए स्वतंत्र रूप से किया जाना चाहिए।

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