26 पॉइंट द्वारा GN⁺ 2025-01-08 | 8 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े codebase में काम करना software engineers के लिए सबसे कठिन कामों में से एक है। व्यक्तिगत projects या open source projects से ऐसा अनुभव पाना मुश्किल होता है
    • लाखों lines of code, 100-1000 engineers एक साथ काम कर रहे हों, और codebase कम से कम 10 साल पुराना हो
    • इसके लिए जटिलता और समय के साथ जमा हुई स्थिति को समझने की अलग क्षमता चाहिए

सबसे बड़ी गलती है consistency की कमी

  • सबसे आम गलती यह है कि मौजूदा codebase को नज़रअंदाज़ करके अपनी feature implement कर दी जाए। इससे consistency बनी नहीं रहती और codebase की अव्यवस्था और बढ़ जाती है
    • आम तौर पर लोग मौजूदा codebase के साथ interaction कम से कम रखते हुए अपना साफ-सुथरा code बनाए रखना चाहते हैं, और मौजूदा "legacy" code से बचने के लिए चीज़ों को अलग से implement करते हैं
  • Consistency codebase की complexity कम करती है और भविष्य के improvements को आसान बनाती है
  • उदाहरण के लिए, API endpoint implement करते समय मौजूदा authentication तरीके का पालन करना ज़रूरी है। इससे codebase के minefield को सुरक्षित तरीके से पार किया जा सकता है
  • अगर consistent patterns नहीं होंगे, तो हर code को manually update करना पड़ेगा, और यह समय के साथ और मुश्किल होता जाएगा

अन्य महत्वपूर्ण तत्व

  • service वास्तव में कैसे इस्तेमाल होती है, इसे समझना
    • सबसे ज़्यादा इस्तेमाल होने वाले मुख्य API endpoints और महत्वपूर्ण paths (hot path) की पहचान करें
    • जिन code paths का usage बहुत अधिक है, उनमें बदलाव बहुत सावधानी से करें
  • testing और monitoring का महत्व
    • बड़े projects में हर state को test नहीं किया जा सकता, इसलिए केवल मुख्य paths को test किया जाता है
    • code को defensively लिखें और gradual rollout तथा monitoring पर निर्भर रहें
  • dependencies जोड़ने में संयम रखें
    • dependencies सुरक्षा समस्याएँ और maintenance cost में बढ़ोतरी ला सकती हैं
    • अगर सच में ज़रूरी हो, तो भरोसेमंद dependency चुनें
  • code हटाना सावधानी से, लेकिन सक्रिय रूप से करें
    • production data का विश्लेषण करके calls को सुरक्षित रूप से हटाने के बाद code delete करें
    • अनावश्यक code हटाने से codebase को maintain करना आसान हो जाता है
    • बड़े codebase में यह सबसे अधिक मूल्य देने वाले कामों में से एक है
  • छोटे PRs में काम करें और ऐसे बदलाव पहले संभालें जो दूसरी teams के code को प्रभावित करते हों
    • इससे domain experts समस्याओं को पहचानकर incidents को रोक सकते हैं

बड़े codebase क्यों महत्वपूर्ण हैं?

  • बड़े codebase का मूल्य
    • ज़्यादातर tech companies बड़े codebase से ही revenue कमाती हैं
    • "legacy codebase" पर काम करना ही अक्सर कंपनी के वास्तविक काम का मतलब होता है
  • code अलग करने से पहले समझ ज़रूरी है
    • बड़े codebase को अलग करने के लिए पहले यह पर्याप्त रूप से समझना होगा कि पूरा सिस्टम कैसे काम करता है
    • समझ के बिना बड़े पैमाने का redesign संभव नहीं है

सारांश

  • बड़े codebase महत्वपूर्ण business value रखते हैं
  • सबसे महत्वपूर्ण बात है consistency बनाए रखना
  • नई feature implement करने से पहले मौजूदा code की जाँच करें और उसके patterns का पालन करें
  • अगर मौजूदा patterns का पालन नहीं कर रहे हैं, तो उसके लिए बहुत अच्छा कारण होना चाहिए
  • समझें कि production environment में code वास्तव में कैसे इस्तेमाल होता है
  • हर case को test नहीं किया जा सकता, इसलिए testing पर ज़रूरत से ज़्यादा निर्भर न रहें; monitoring और gradual rollout पर निर्भर रहें
  • code हटाने के अवसरों का सक्रिय रूप से उपयोग करें, लेकिन सावधानी के साथ
  • छोटे PRs में काम करें ताकि domain experts review कर सकें

8 टिप्पणियां

 
kallare 2025-01-10

संगति महत्वपूर्ण है, लेकिन इसका मतलब यह नहीं कि code improvement टाल दिया जाए या मौजूदा गलत patterns को बार-बार दोहराया जाए... यह वास्तव में कठिन समस्या है। संगति बनाए रखने के चक्कर में वही technical debt बार-बार जमा होती जा सकती है।

 
regentag 2025-01-09

किसी भी चीज़ से बढ़कर, coding rules का पालन करना चाहिए।
खासकर indentation rules...

 
roxie 2025-01-10

क्या आप ऐसे डोमेन में हैं जहाँ ऐसे टूलिंग लागू नहीं किए जा सकते जो चीज़ों को अपने-आप पकड़ लें..? सिसकी

 
regentag 2025-01-10

हाँ.... सिसकी

 
roxie 2025-01-10

मैं आपके लिए रो दूँगा.. sob sob

 
bbulbum 2025-01-09

प्रोजेक्ट का आकार != परिपक्वता
मैं मानता हूँ कि consistency बहुत महत्वपूर्ण है, लेकिन इसे बहाना बनाकर codebase सुधार की प्राथमिकता को कम रखना ऐसी बात है जिससे बचना चाहिए।
क्योंकि प्रोजेक्ट हमेशा जीवित रहते हैं और बढ़ते रहते हैं, इसलिए अगर सही समय पर सुधार नहीं किए जाते, तो बाद में उसे पलटना कहीं अधिक समय और मेहनत मांगता है।

 
beoks 2025-01-09

मैं भी सहमत हूँ। मैं 20 साल से अधिक पुराने प्रोजेक्ट्स पर काम कर रहा हूँ, लेकिन उनमें आज के मानकों की तुलना में सचमुच कई अपरिपक्व हिस्से हैं.
संगतता का फायदा यह है कि वह कोड की समझ को बेहतर बना सकती है, लेकिन संरचना की सीमाएँ फीचर्स की सीमाएँ भी पैदा करती हैं और सेवा के विकास में बाधा बनती हैं, इसलिए मुझे लगता है कि कभी-कभी साहसिक बड़े बदलाव भी ज़रूरी होते हैं।

 
GN⁺ 2025-01-08
Hacker News राय
  • जब मौजूदा codebase में consistency नहीं होती, तो नए तरीके अपनाना, उन्हें document करना और feedback लेना महत्वपूर्ण होता है। मौजूदा code के साथ consistency बनाए रखने की कोशिश करनी चाहिए।

    • भले ही मौजूदा code खराब हो, फिर भी आसपास के code के साथ consistency बनाए रखते हुए काम करना महत्वपूर्ण है।
    • अगर team members सहयोगी न हों, तो मौजूदा code की समस्याओं को उजागर करना और यह समझाना मददगार होता है कि नया approach experimental है।
  • मौजूदा codebase के tools का उपयोग करना चाहिए, लेकिन नया codebase बनाना ज़्यादा आनंददायक हो सकता है।

    • codebase का coupling जितना ज़्यादा होगा, बदलाव उतने ही कठिन हो सकते हैं, और अगर test coverage कम हो तो समस्याएँ पैदा हो सकती हैं।
  • बड़े codebase को विभाजित करने के लिए पहले उसे समझना ज़रूरी है, और अगर अनुभवहीन team यह कोशिश करे तो असफलता की संभावना बहुत अधिक होती है।

    • अगर नई team मौजूदा system को समझ नहीं पाती, तो project असफल हो सकता है।
  • बड़े codebase में बिना स्पष्ट दिशा के सुधार करने की कोशिशें बहुत होती हैं।

    • किन हिस्सों में सुधार करना है, और किन बदलावों का वास्तव में सकारात्मक प्रभाव पड़ेगा, यह समझना महत्वपूर्ण है।
    • क्या सुधारना है और कब रुकना है, यह जानना महत्वपूर्ण है।
  • codebase के evolution को बनाए रखना कठिन है।

    • पूर्ण consistency प्रयोग की अनुमति नहीं देती, और प्रयोग न हों तो सफलता भी नहीं मिलती।
  • अगर codebase बड़ा हो और लोगों की कमी हो, तो नए व्यक्ति को productive बनने में बहुत समय लग सकता है।

    • ऐसे माहौल में काम करना career के लिए अच्छा नहीं हो सकता।
  • codebase को साफ़-सुथरा बनाए रखने का मतलब है कि feature release करने के लिए जितना न्यूनतम काम ज़रूरी हो, उतना ही किया जाए।

    • यह राजनीतिक रूप से चतुर engineers की एक tactical choice हो सकती है, जिनका लक्ष्य feature release होता है।
  • consistency सबसे महत्वपूर्ण चीज़ नहीं है; codebase के कुछ हिस्सों को बेहतर बनाना अधिक अच्छा हो सकता है।

    • "lava layer anti-pattern" consistency बनाए रखने की कोशिश से बेहतर system बना सकता है।
  • "consistency की कमी एक घातक गलती है" — यह बात 100% सही है।

    • "When in Rome, do as the Romans do" वाली philosophy अपनानी चाहिए।
  • एक engineer के रूप में तीन सूक्तियाँ:

    • clarity, consistency, conciseness
    • दर्द को सही जगह पर रखना
    • entropy से लड़ना