समझ अभिव्यंजक नामों से शुरू होती है

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

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

डोनाल्ड नूथ ने प्रसिद्ध रूप से कहा था:

प्रोग्राम मनुष्यों द्वारा पढ़े जाने के लिए बनाए गए हैं और केवल संयोगवश कंप्यूटर द्वारा निष्पादित होने के लिए। – डोनाल्ड नूथ

नामकरण

नामकरण कठिन है क्योंकि इसमें लेबलिंग और परिभाषित करना आवश्यक है कि एक टुकड़ा एप्लिकेशन में कहाँ और कैसे फिट होता है।

फिल कार्लटन ने नेटस्केप में रहते हुए देखा:

कंप्यूटर साइंस में केवल दो कठिन चीजें हैं: कैश इनवैलिडेशन और चीजों का नामकरण।
— फिल कार्लटन

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

लुडविग विट्गेंस्टाइन, 20वीं सदी के पूर्वार्ध के एक दार्शनिक ने कहा था:

मेरी भाषा की सीमाएं मेरी दुनिया की सीमाएं हैं। – लुडविग विट्गेंस्टाइन

हमारे सॉफ्टवेयर की भाषा केवल उतनी ही वर्णनात्मक है जितने नाम हम उपयोग करते हैं और अस्पष्ट नामों का उपयोग सॉफ्टवेयर के उद्देश्य को धुंधला कर देता है; वर्णनात्मक नामों का उपयोग स्पष्टता और समझ लाता है।

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

इस भावना का सबसे अच्छा अनुभव होता है।

अनुभव

कोड के पहले स्निपेट की जांच करें, यह कोड क्या करता है? क्यों क्या है?

अपना समय लें।

public class StringHelper
{
    public string Get(string input1, string input2)
    {
        var result = string.Emtpy;
        if(!string.IsNullOrEmtpy(input1) && !string.IsNullOrEmtpy(input2))
        {
            result = $"{input1} {input2}";
        }
        return result;
    }
}

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

आइए कोड पर फिर से नज़र डालें, लेकिन थोड़ा सा “क्यों” छिड़कने के साथ।

फिर से, अपना समय लें, इस कोड को पढ़ते समय आप जो अंतर महसूस करते हैं उसे देखें।

    public class FirstAndLastNameFormatter
    {
        public string Concatenate(string firstName, string lastName)
        {
            var fullName = string.Emtpy;
            if(!string.IsNullOrEmtpy(firstName) && !string.IsNullOrEmtpy(lastName))
            {
                fullName = $"{firstName} {lastName}";
            }
            return fullName;
        }
    }

“क्यों” कोड को जीवंत बनाता है, पढ़ने के लिए एक कहानी है।

संवाद

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

अगले इंजीनियर का एहसान करें और अपने कोड में अभिव्यंजक बनें। वर्णनात्मक नामों का उपयोग करें और “क्यों” को कैप्चर करें क्योंकि कौन जानता है, अगला इंजीनियर आप ही हो सकते हैं।