Frontend Fundamentals

Toss के फ्रंटएंड चैप्टर ने एक साइट प्रकाशित की है, जिसमें अच्छे फ्रंटएंड कोड के मानदंडों के बारे में बताया गया है।

• फ्रंटएंड डेवलपर्स द्वारा मुख्य रूप से इस्तेमाल किए जाने वाले TypeScript के आधार पर समझाया गया है
• Readability/Predictability/Cohesion/Coupling इन 4 दृष्टिकोणों से best practice प्रस्तुत की गई हैं
• वास्तविक फ्रंटएंड में अक्सर इस्तेमाल होने वाली लाइब्रेरीज़ का उपयोग करने वाले उदाहरण दिए गए हैं

4 मानदंड

1. पठनीयता
   पठनीयता (Readability) का मतलब है कि कोड को पढ़ना कितना आसान है। कोड को बदलना आसान होने के लिए पहले यह समझ पाना ज़रूरी है कि वह कौन-सा व्यवहार करता है।

2. पूर्वानुमेयता
   पूर्वानुमेयता (Predictability) का मतलब है कि साथ काम करने वाले सहयोगी किसी function या component के व्यवहार का कितना अनुमान लगा सकते हैं। उच्च पूर्वानुमेयता वाला कोड एकसमान नियमों का पालन करता है, और केवल function या component का नाम, parameters और return value देखकर भी यह समझा जा सकता है कि वह क्या करता है।

3. सुसंगति
   सुसंगति (Cohesion) का मतलब है कि जिन कोड हिस्सों को बदला जाना चाहिए, क्या वे हमेशा साथ में बदले जाते हैं। उच्च सुसंगति वाला कोड ऐसा होता है कि कोड के एक हिस्से को बदलने पर अनजाने में किसी दूसरे हिस्से में त्रुटि नहीं आती। ऐसा इसलिए क्योंकि जिन हिस्सों को साथ बदलना चाहिए, उन्हें संरचनात्मक रूप से साथ बदलने के लिए समर्थित किया गया होता है।

4. युग्मन
   युग्मन (Coupling) का मतलब है कि कोड में बदलाव करने पर उसका प्रभाव-क्षेत्र कितना है। ऐसा कोड जिसमें बदलाव का प्रभाव-क्षेत्र कम हो और परिवर्तन के असर की सीमा का अनुमान लगाया जा सके, उसे बदलना आसान होता है।

[savvykang]

मुझे यह जानना है कि components और hooks की न्यूनतम management unit के रूप में file का इस्तेमाल क्यों किया जाता है। मैं अंदाज़ा लगा सकता हूँ कि शायद यह IDE support या tree shaking की कमी की वजह से हो, लेकिन पक्का नहीं हूँ, इसलिए पूछ रहा हूँ.

कोड पढ़ते समय जब एक function वाली file या सिर्फ import/export statements वाली index.ts file दिखती है, तो याद रखने वाली चीज़ें बढ़ जाती हैं। एक ही file के भीतर hook और component को मिलाकर रखने के तरीके की तुलना में, यह मुझे ज़रूरत से ज़्यादा cognitive load बढ़ाने वाली संरचना लगती है। फिर भी, ऐसी संरचना इस्तेमाल करने के क्या फायदे या कारण हैं?

[firea32]

आमतौर पर ऐसी जगहों पर जिस "अच्छे development" की बात की जाती है, उसकी बड़ी पूर्वधारणा यह होती है कि बहुत सारे developers काम कर रहे हैं.
जैसा आपने कहा, याद रखने वाली चीज़ों का बढ़ना = इसका मतलब है कि आपके ऊपर पूरे project की ज़िम्मेदारी है, लेकिन
जहाँ developers ज़्यादा होते हैं, वहाँ लोग सिर्फ अपने हिस्से का development करते हैं.
अगर कोई समस्या आती है, तो सिर्फ उसी हिस्से को देखना काफ़ी होता है; उससे जुड़े हर हिस्से को देखने की ज़रूरत नहीं होती.
एक तरह से देखें तो यह अत्यधिक optimization के बजाय productivity को चुनने जैसा है.

[savvykang]

आपकी बात के अनुसार, जिन परिवेशों में काम का बँटवारा अधिक बारीकी से किया जा सकता है, वहाँ मुख्य लेख की बात सही विकल्प है। मेरा मानना है कि यदि code separation करते समय होने वाले tradeoff और निर्णय के मानदंड भी समझाए गए होते, तो यह लेख और अधिक पूर्ण होता।

[beenzinozino]

मेरे मामले में, फ्रंटएंड development करते समय component या hook की न्यूनतम management unit के रूप में file का इस्तेमाल करने के कारण नीचे दिए गए हैं.

1. testability.

यानी, एक module के साथ एक unit test को match करना आसान होता है.

मेरा मानना है कि फ्रंटएंड development में pure function आधारित paradigm प्रमुख होता है, लेकिन अगर एक ही file के भीतर कई functions मौजूद हों, तो unit test लिखते समय 1:1 matching मुश्किल हो जाती है.

अगर remark-plugin.js नाम की एक file के अंदर कई utility functions हों, तो test कैसे लिखना चाहिए? क्या remark-plugin.test.js नाम की सिर्फ एक file बनाकर कई utility functions के tests एक साथ लिख देना अच्छा विकल्प होगा?

ऐसी स्थिति में remark-plugins नाम की directory बनाकर उसके अंदर utility functions को एक-एक करके अलग करें और उनके tests लिखें, तो बाद में functions की भूमिकाएँ और स्पष्ट हो सकती हैं, और GitHub commit tracking भी कहीं ज़्यादा साफ़ हो जाती है—ऐसा मुझे लगता है.

2. directory structuring

server development में commonjs, या client side पर webpack जैसे module bundlers अक्सर index.js file को किसी specific directory की entry file के रूप में तय करते हैं. यह पहले से लंबे समय से इस्तेमाल होती आई एक convention भी है, इसलिए कुछ हद तक हम इसे स्वीकार करके इस्तेमाल करते हैं.

लेकिन मेरी राय में सबसे महत्वपूर्ण कारण यह है कि functional programming के pure function paradigm में external state पर निर्भर नहीं होना चाहिए, इसलिए अगर एक ही file में कई functions भरे हों, तो external state को reference कर देने की गलती होने की संभावना बढ़ जाती है. (ES6 में module scope आने के कारण के बारे में सोचें, तो यह बात समझ में आ सकती है.)

3. commit tracking में आसानी.

मेरे हिसाब से, एक ही file के भीतर कई utility functions के मिले-जुले होने की तुलना में, अगर functions अलग-अलग files में बँटे हों, तो commit history track करना बहुत आसान हो जाता है.

जब किसी module में feature जोड़ा जाता है या bug fix किया जाता है, तब दूसरे modules को देखने की ज़रूरत नहीं पड़ती और सिर्फ उसी module पर ध्यान केंद्रित किया जा सकता है.

---

लिखते-लिखते लेख काफ़ी लंबा हो गया, इसलिए थोड़ा बेतरतीब लिखा गया है. (अभी tree shaking के बारे में मेरी समझ कम है, इसलिए उस पर ज़्यादा कुछ नहीं कहूँगा...) बेशक, मेरी बात ही अंतिम उत्तर हो यह ज़रूरी नहीं है, इसलिए इसे reference के तौर पर देखें तो अच्छा होगा!

[thkimdev]

यह अच्छा है।

[illiil1lii]

इसे बहुत सहज और प्रवाहपूर्ण तरीके से लिखा गया है। मैं इसकी सिफारिश करता हूँ।

[tsboard]

शेयर करने के लिए धन्यवाद! मुझे भी इसे ध्यान से पढ़ना होगा।

[bbulbum]

यह Frontend तक सीमित होकर लिखा गया है, लेकिन मुझे लगता है कि अगर इसे सिर्फ software के नज़रिए से देखें तो भी ये बातें काफ़ी उपयोगी हैं। इतनी अच्छी insights साझा करने के लिए धन्यवाद।