अगले डेवलपर के लिए कोडिंग के 5 चरण

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

अच्छे प्रोग्रामर्स पर केंट बेक:

कोई भी मूर्ख ऐसा कोड लिख सकता है जिसे कंप्यूटर समझ सके। अच्छे प्रोग्रामर ऐसा कोड लिखते हैं जिसे इंसान समझ सकें।

अच्छे कंप्यूटर प्रोग्राम्स पर डगलस क्रॉकफोर्ड:

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

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

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

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

सामान्य सॉफ्टवेयर समस्याओं के लिए ज्ञात सॉफ्टवेयर पैटर्न हैं। 1995 में, Design Patterns: Elements of Reusable Object-Oriented Software प्रकाशित हुई जो सामान्य सॉफ्टवेयर पैटर्न का वर्णन करती है। यह पुस्तक अधिकांश सॉफ्टवेयर एप्लिकेशन में आने वाली सामान्य समस्याओं का वर्णन करती है और इन समस्याओं को हल करने का एक सुरुचिपूर्ण तरीका प्रदान करती है। डेवलपर्स उन समस्याओं को हल करते समय अपने स्वयं के पैटर्न भी बनाते हैं जिनका वे नियमित रूप से सामना करते हैं। हालांकि वे कोई पुस्तक प्रकाशित नहीं करते, यदि आप पर्याप्त रूप से देखें तो आप उन्हें पहचान सकते हैं।

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

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

अगले डेवलपर्स के लिए संकेत छोड़ने के 5 सुझाव

1. पैटर्न
ज्ञात पैटर्न का उपयोग करें, अपने स्वयं के पैटर्न बनाएं। पूरे कोड में एक सुसंगत प्रतिमान के साथ बने रहें। उदाहरण के लिए, डेटा एक्सेस के लिए 3 दृष्टिकोण न रखें।

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

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

3. विस्तृत नामकरण
यह आपकी भाषा है। ये आपकी कहानी के शब्द हैं। इन्हें अच्छी तरह से बुनें।

इसमें क्लास नाम, मेथड नाम, वेरिएबल नाम, प्रोजेक्ट नाम और प्रॉपर्टी नाम शामिल हैं।

न करें:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

करें:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

पहले उदाहरण में if स्टेटमेंट में 3 हार्ड कोडेड है। यह कोड वाक्यविन्यास की दृष्टि से सही है, लेकिन संख्या 3 का इरादा आपको कुछ नहीं बताता। जिस प्रॉपर्टी के विरुद्ध इसका मूल्यांकन किया जा रहा है उसे देखते हुए, आप अनुमान लगा सकते हैं कि यह वास्तव में 3 घंटे है। वास्तव में हम नहीं जानते। हम एक धारणा बना रहे हैं।

दूसरे उदाहरण में, हमने 3 को ‘feedInterval’ नामक एक वेरिएबल में सेट किया है। इरादा वेरिएबल नाम में स्पष्ट रूप से बताया गया है। यदि पिछले भोजन के बाद से 3 घंटे हो गए हैं, तो बंदर को खिलाने का समय है। वेरिएबल सेट करने का एक साइड इफेक्ट यह है कि अब हम लॉजिक को बदले बिना फीड इंटरवल को बदल सकते हैं।

यह एक कृत्रिम उदाहरण है, एक बड़े सॉफ्टवेयर में इस प्रकार का कोड स्व-दस्तावेजीकरण है और अगले डेवलपर को कोड समझने में मदद करेगा।

4. टिप्पणियां
टिप्पणियां दोधारी तलवार हैं। बहुत अधिक टिप्पणी करना रखरखाव की लागत बढ़ाता है, पर्याप्त नहीं होने से डेवलपर्स को यह समझने में कठिनाई होती है कि कोड कैसे काम करता है। एक सामान्य नियम यह है कि जब औसत डेवलपर कोड को नहीं समझेगा तो टिप्पणी करें। यह तब होता है जब धारणाएं स्पष्ट नहीं होतीं या कोड सामान्य से हटकर होता है।

5. सरल कोड
मेरी व्यावसायिक राय में जटिल कोड लिखना डेवलपर्स के बीच सबसे बड़ी मूर्खता है।

सरलता पर स्टीव जॉब्स:

सरल जटिल से कठिन हो सकता है: आपको अपनी सोच को साफ करने के लिए कड़ी मेहनत करनी होगी ताकि इसे सरल बनाया जा सके। लेकिन अंत में यह इसके लायक है क्योंकि एक बार जब आप वहां पहुंच जाते हैं, तो आप पहाड़ हिला सकते हैं।

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

साफ सरल कोड लिखने के बारे में अधिक जानकारी के लिए, अंकल बॉब की पुस्तक Clean Code और मैक्स कनात-अलेक्जेंडर की Code Simplicity देखें

समापन

कोड पढ़ना कठिन है। कुछ सरल चरणों के साथ आप यह सुनिश्चित कर सकते हैं कि अगला डेवलपर आपके कोड को समझ जाएगा।