- आधुनिक software development culture में प्रोजेक्ट्स और लाइब्रेरीज़ के नाम उनके फ़ंक्शन से असंबंधित मनमाने शब्दों से भरे जा रहे हैं
- पहले grep, awk, sed, FORTRAN, COBOL जैसे नाम सीधे उनके फ़ंक्शन या उद्देश्य को समझाते थे, लेकिन अब अर्थहीन नामों की भरमार है
- यह प्रवृत्ति GitHub और startup culture के फैलाव के साथ तेज़ हुई, जिससे नाम और फ़ंक्शन का संबंध लगभग पूरी तरह टूट गया
- समझने की लागत और cognitive burden बढ़ जाता है, और डेवलपर्स को हर टूल की भूमिका समझने के लिए बार-बार अनावश्यक खोज करनी पड़ती है
- लेख स्पष्ट और फ़ंक्शन-केंद्रित naming rules की बहाली की मांग करता है और ज़ोर देता है कि तकनीकी टूल्स में branding से अधिक स्पष्टता और पेशेवरिता को प्राथमिकता मिलनी चाहिए
सॉफ़्टवेयर naming practices में बदलाव
- Richard Stallman ने 2022 के EmacsConf व्याख्यान में “याद रखने में आसान नाम” के महत्व का उल्लेख करते हुए ज़ोर दिया कि पैकेज का नाम यह दिखाना चाहिए कि वह क्या करता है
- Emacs ecosystem ने परंपरागत रूप से dired(directory editor), eshell(Emacs shell) जैसे फ़ंक्शन-आधारित naming practices को बनाए रखा है
- लेकिन आधुनिक डेवलपर्स टूल्स को random nouns, पौराणिक जीवों, काल्पनिक पात्रों जैसे नाम देने की प्रवृत्ति दिखाते हैं
- अन्य तकनीकी क्षेत्रों में इसे पेशेवरिता की कमी माना जाता
अर्थहीन नामों की समस्या
- उदाहरण के तौर पर “Viper”, “Cobra”, “Melody”, “Casbin”, “Asynq” जैसे टूल नामों से उनके फ़ंक्शन का कोई अनुमान नहीं लगाया जा सकता
- लेखक बताते हैं कि उन्हें एक दोस्त की infrastructure explanation समझने के लिए search तक करनी पड़ी थी
- अन्य engineering क्षेत्रों में नाम संरचना या फ़ंक्शन को समझाते हैं
- उदाहरण: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve आदि में उनका रूप या भूमिका स्पष्ट दिखती है
- chemistry में IUPAC nomenclature की तरह, नाम इस तरह तय किए जाते हैं कि वे ठीक एक ही वस्तु की ओर संकेत करें
- उदाहरण: 2,2,4-trimethylpentane सिर्फ़ एक ही molecule को दर्शाता है, उसे मनमाने ढंग से “Steve” नहीं कहा जाता
पुराने naming rules और आज का विच्छेद
- 1980 के दशक में grep, awk, sed, cat, diff जैसे फ़ंक्शन-आधारित संक्षेप मुख्यधारा में थे
- FORTRAN, COBOL, BASIC, SQL, Lisp जैसी programming languages के नाम भी उनके उद्देश्य को दर्शाते थे
- 2010 के बाद अर्थहीन नामों का फैलाव शुरू हुआ
- MongoDB जैसे कुछ नामों का फ़ंक्शन और व्युत्पत्ति से कुछ संबंध था, लेकिन बाद में GitHub और startup culture के बीच निरर्थक नामों में तेज़ वृद्धि हुई
- Google जैसे brand-centric success cases की नकल करने की प्रवृत्ति को इसका कारण बताया गया है
cognitive cost और development efficiency में गिरावट
- libsodium जैसे नामों से फ़ंक्शन का अनुमान लगाना मुश्किल होता है, और डेवलपर को बार-बार context switching करना पड़ता है
- “sodium क्यों?” समझने में अनावश्यक समय खर्च होता है
- जितनी अधिक project dependencies हों, यह cognitive tax उतना ही जमा होता जाता है
- इससे डेवलपर productivity में गिरावट आती है
- लेखक का कहना है कि “Viper, Cobra, Melody…” जैसे वाक्यों को समझते समय अर्थहीन tokens की व्याख्या में मानसिक संसाधन व्यर्थ होते हैं
आम तर्क और उनके जवाब
- “याद रखने में आसान नाम marketing के लिए बेहतर होते हैं” → डेवलपर टूल्स consumer products नहीं हैं, इसलिए फ़ंक्शन की स्पष्टता अधिक महत्वपूर्ण है
- “वर्णनात्मक नाम उबाऊ होते हैं” → उबाऊपन स्पष्टता की कीमत के रूप में स्वीकार्य है, surgical instruments भी उबाऊ होते हैं लेकिन सटीक होते हैं
- “यह मज़े के लिए किया जाता है” → उस ‘मज़े’ की कीमत हर उपयोगकर्ता चुकाता है, और इससे पूरे उद्योग का समय बर्बाद होता है
- “अच्छे नाम पहले ही इस्तेमाल हो चुके हैं” → namespace, prefix, compound words आदि से इसका समाधान संभव है, और कम से कम फ़ंक्शन से जुड़े नाम चुनने चाहिए
आगे की दिशा
- समस्या को दुर्भावना से अधिक सांस्कृतिक बदलाव का परिणाम बताया गया है
- programming के enterprise-centric माहौल से community-centric माहौल की ओर जाने पर social norms कमज़ोर हुए
- समाधान है naming rules की सांस्कृतिक बहाली
- regulation से अधिक पेशेवरिता की पुनर्बहाली, शिक्षा और social pressure के ज़रिए सुधार की ज़रूरत है
- लाइब्रेरी के नाम उसके फ़ंक्शन को दर्शाने चाहिए, और ज़रूरत पड़े तो compound words और लंबे expressions भी स्वीकार्य होने चाहिए
- उदाहरण: “http-request-validator” , “zephyr” की तुलना में कहीं अधिक स्पष्ट है
- mascot और नाम को अलग रखना चाहिए
- उदाहरण: PostgreSQL Slonik नाम के elephant mascot का उपयोग करता है, लेकिन उसका नाम स्वयं functional meaning बनाए रखता है
- अगर वह branding-प्रधान consumer product नहीं है, तो स्पष्टता और पेशेवरिता को प्राथमिकता देनी चाहिए
- “अपना पसंदीदा anime character का नाम” देने से पहले यह पूछना चाहिए: “क्या कोई civil engineer किसी bridge system को ऐसा नाम देगा?”
- निष्कर्षतः, निरर्थक नामों की बाढ़ को रोककर स्पष्ट पेशेवर भाषा की ओर लौटना चाहिए
- स्पष्टता उबाऊपन नहीं, बल्कि उपयोगकर्ता के समय और cognitive resources के प्रति सम्मान है
अभी कोई टिप्पणी नहीं है.