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

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;
        }
    }

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

संवाद करें

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

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