क्या "स्वच्छ संहिता" वास्तव में स्वच्छ और उपयोगी है? [बन्द है]


11

मैं वर्तमान में एक बड़े निगम में इंटर्नशिप कर रहा हूं और वे सॉफ्टवेयर डिलीवरी संरचना (एजाइल में स्थानांतरित) में कई बदलावों से गुजर रहे हैं।

पिछले कुछ महीनों में मैंने Clean Codeप्रथाओं के लिए इस धार्मिक लगाव पर ध्यान दिया है और पुस्तक डेवलपर्स के लिए एक बाइबिल की तरह है।

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

मैं समझता हूं कि यह स्वच्छ कोड एक दीर्घकालिक निवेश है जो कोड रखरखाव और सुधार के बाद आसान होगा, लेकिन ... क्या यह वास्तव में इस सभी उपद्रव के लायक है?

क्या कोई अपना अनुभव क्लीन कोड और किसी राय पर साझा करेगा कि क्या मैं अभी बहुत रूढ़िवादी हूं या यह सिर्फ एक अस्थायी प्रवृत्ति है।


1
कई अच्छे प्रश्न विशेषज्ञ अनुभव के आधार पर कुछ हद तक राय उत्पन्न करते हैं, लेकिन इस सवाल के जवाब तथ्यों, संदर्भों या विशिष्ट विशेषज्ञता के बजाय लगभग पूरी तरह से राय पर आधारित होंगे।
gnat

4
मेरे पास उस पुस्तक (इसके लेखक के बावजूद) की बहुत उच्च राय नहीं है। सामान्य तौर पर यह बहुत अधिक हठधर्मी नहीं होने का भुगतान करता है। अधिकांश प्रोग्रामिंग सिफारिशें हैं क्योंकि उन्हें अभ्यास में काम करने के लिए दिखाया गया है, लेकिन वे पूर्ण सत्य नहीं हैं, इसलिए बहुत चिंता न करें। पढ़ते रहें और जो आपको लगता है वह अधिक सही है, लेकिन पहिए को फिर से मजबूत न करें। संभावना है कि कोई हमसे ज्यादा चालाक हो जो पहले से ही हमारे खुद से बेहतर समाधान का अनुमान लगा चुका हो।
DPM

2
70 चरित्र नाम वाली एक विधि संभवतः एक से अधिक काम करती है। SRP का उल्लंघन क्या मैं सही हूँ?
टॉम्बट्रॉन

1
यहाँ पर एक और विचार है, अब से 5 या 10 साल बाद जब आप किसी कंपनी के डेवलपर होंगे जो साफ कोड की कम देखभाल कर सकते हैं, तो आप वास्तव में इस हठधर्मिता की सराहना करेंगे।
टॉम्बट्रॉन

3
"कोई टिप्पणी नहीं" के तहत काम किया (संक्षेप में), मैं इसे एक नियम से एक मजबूत दिशानिर्देश के रूप में बहुत पसंद करता हूं । ऐसे समय होते हैं जब टिप्पणियों की आवश्यकता होती है - आमतौर पर अस्पष्ट व्यावसायिक तर्क में। एक विधि CalculateFoonicityMetric()आपको बताती है कि वास्तव में यह क्या कर रही है, और अच्छी तरह से लिखा कोड आपको दिखाएगा कि कैसे ... लेकिन इनमें से कोई भी आपको यह नहीं बताता कि क्यों । कोड में क्या स्पष्ट हो सकता है (इसे इस से गुणा करें, दूसरी चीज़ से विभाजित करें, इसे वर्ग करें, इस बिट पर जोड़ें ...) लेकिन इसमें अस्पष्ट क्यों (कारक = a * b / c; नकारात्मक foo के लिए खाते का वर्ग; समायोजित करें) बहाव के लिए ...)। मैं एक त्वरित टिप्पणी की सराहना करता हूं जो बताती है कि क्यों।
अनएक्सिमैंडर

जवाबों:


17

मैं समझता हूं कि यह स्वच्छ कोड एक दीर्घकालिक निवेश है जो कोड रखरखाव और सुधार के बाद आसान होगा, लेकिन ... क्या यह वास्तव में इस सभी उपद्रव के लायक है?

पूर्ण रूप से।

पुन: फैक्टरिंग बहुत महत्वपूर्ण है, लेकिन अपना 75% समय खर्च करने के तरीके और समय के भार को खर्च करके इसका उचित शीर्षक तय करना उतना उपयोगी नहीं लगता है।

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

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


4

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

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

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

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

सही विधि नाम चुनने में लगने वाला समय संभवतः बेहतर तरीके से यह समझने में मदद करेगा कि विधि का उद्देश्य क्या है। विधि के नाम "iterateOverCustomers" की तुलना "FindActiveCustomers" से करें। कौन सा फ़ंक्शन का आशय बताता है? यदि आवश्यक हो तो कौन सा रिफ्लेक्टर करना आसान होगा?


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

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

हाँ, यह मुझे बहुत चरम लगता है।
एरिक किंग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.