डिज़ाइन दस्तावेज़ों की तुलना में Throwaway Code को प्राथमिकता देने की प्रवृत्ति

 (softwaredoug.com)
3 पॉइंट द्वारा GN⁺ 2024-12-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • हम कल्पना करते हैं कि software development एक साफ़-सुथरे और व्यवस्थित flow का पालन करेगा

    • design document लिखा जाता है, और छोटे बदलावों को PR के ज़रिए roll out करके feature implement किए जाते हैं
    • Git history साफ़ और सुव्यवस्थित दिखती है
    • लेकिन वास्तविकता अलग है

  • design document और वास्तविक implementation के बीच अंतर

    • design document को ज्यों का त्यों implement करना एक भ्रम है
    • coding शुरू करते ही design document की सामग्री बदलनी पड़ती है
    • योजनाएँ दुश्मन के संपर्क में आते ही टिक नहीं पातीं

  • नई design methodology: coding में डूबकर काम करना

    • draft PR का उपयोग करके prototype implement किया जाता है
    • शुरुआत में feedback लेकर approach को समायोजित किया जाता है
    • draft PR को ऐतिहासिक design ideas के documentation के रूप में रखा जाता है
    • draft PR को पूरी तरह छोड़ देने के लिए तैयार रहा जाता है
    • draft PR से धीरे-धीरे PR को चरणबद्ध तरीके से आगे बढ़ाया जाता है
    • हर PR को चरणबद्ध तरीके से test किया जाता है और उसकी robustness को मजबूत किया जाता है

  • परिपक्वता का महत्व

    • लिखे गए code ideas को छोड़ सकने की क्षमता महत्वपूर्ण है
    • code lines नहीं, बल्कि organizational knowledge का हस्तांतरण अधिक महत्वपूर्ण है
    • महत्वपूर्ण हिस्सों पर शुरुआत में ही alignment कर लिया जाता है ताकि prototype work बेकार न जाए

  • documentation के रूप में PR का उपयोग कैसे करें

    • PR, developers के लिए documentation के सबसे अच्छे रूपों में से एक है
    • PR किसी खास समय की स्थिति को दर्शाने वाला एक historical artifact है
    • design document अक्सर वास्तविकता से अलग जानकारी देता है

  • prototype का महत्व

    • एक prototype, 1000 design documents से अधिक मूल्यवान है
    • बदलाव को आगे बढ़ाना है तो दस्तावेज़ों से नहीं, code से करना चाहिए
    • संगठन को prototype को जवाब नहीं, बल्कि सवाल के रूप में देखना चाहिए

  • design document की उपयोगिता

    • विभिन्न stakeholders के feedback को व्यवस्थित करने और archive करने में उपयोगी है
    • जब कोई idea बहुत conceptual या long-term हो, तब उपयोगी है
    • जब coding की तुलना में लिखकर idea व्यक्त करना अधिक efficient हो, तब उपयोगी है
    • जब संगठन में पहला solution छोड़ देने का discipline न हो, तब उपयोगी है
    • यह ऐसा वातावरण देता है जहाँ junior staff, senior developers के ideas पर सुरक्षित तरीके से सवाल पूछ सकते हैं

  • design document का गलत उपयोग

    • कम अनुभवी developers के लिए process को धीमा करने के लिए इसका उपयोग किया जाता है
    • documentation के रूप में उपयोग होता है, लेकिन जल्दी outdated हो जाता है
    • यह हर design problem को हल करने की कोशिश करता है, जबकि असली समस्याएँ coding के दौरान सामने आती हैं

  • अगर टीम में discipline हो, तो hacking design से कहीं अधिक efficient है

    • संगठन के भीतर ऐसा discipline बनाने की सिफारिश की जाती है
    • अंततः code, शब्दों से ज़्यादा ताकत रखता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-16
Hacker News राय

  • प्रोटोटाइपिंग design प्रक्रिया का एक महत्वपूर्ण हिस्सा है, और समस्या को परिभाषित करना तथा समाधान को स्पष्ट करना ज़रूरी है

    • कभी-कभी एक साधारण दस्तावेज़ ही काफ़ी होता है, लेकिन कभी-कभी बहुत सारा feedback और कई बार के iteration की ज़रूरत होती है
    • एक कहावत है: "कुछ हफ़्तों की coding, कुछ घंटों की planning बचा सकती है"

  • लिखना समस्या को explore करने में उपयोगी है, और ऐसा अनुभव रहा है कि लगा था समस्या समझ ली है, लेकिन लिखते समय नए सवाल पैदा हुए

    • इससे वह उदाहरण याद आता है जहाँ एक mentor ने Lucidchart का उपयोग करके 6 महीनों के काम को समझाया था

  • project को deadline के भीतर पूरा करने के लिए temporary solution इस्तेमाल करने का अनुभव रहा है

    • temporary solution को production support tool के रूप में भी इस्तेमाल किया गया, और अगर permanent version रुक जाए तो उसे fallback path की तरह उपयोग किया गया

  • design document की सबसे बड़ी समस्या यह है कि उसे कोई पढ़ता ही नहीं

    • prototyping की समस्या यह है कि लोग उसे final code मान लेते हैं
    • hybrid approach पसंद है, जिसमें planning और documentation अच्छी तरह की जाती है और prototype code ऐसी quality का लिखा जाता है जिसे final product में इस्तेमाल किया जा सके

  • code और design पर मिलने वाले feedback में बड़ा अंतर होता है

    • design document समस्या-क्षेत्र के "क्यों" वाले सवाल उठाने के लिए प्रेरित करता है
    • prototype काम करने लगे तो ऐसे सवाल उठाना मुश्किल हो जाता है

  • अगर बहुत सारा code लिखकर यह देखना ही job description है कि क्या काम करता है, तो GPT उसे ज़्यादा तेज़ और सस्ते में replace कर सकता है

    • क्या बनाना चाहिए, इस पर सहमति बनाना हमेशा चुनौती रहता है

  • बहुत कम लोग यह कल्पना करते हैं कि software development किसी साफ़-सुथरे और व्यवस्थित flow का पालन करता है

    • code लिखना writing जैसा है; पहला draft हमेशा ख़राब होता है, और अच्छी writing में बहुत revision होता है

  • ऐसे मामले देखे हैं जहाँ code Jenga की तरह जम जाता है और फिर कोई उसे छूना नहीं चाहता

  • design decisions को document करने के लिए लगातार चलने वाले comment thread का उपयोग करने वाली प्रक्रिया पसंद है

    • इस प्रक्रिया के लिए GitHub issues का उपयोग किया जाता है

  • इस approach पर विचार कर रहे हैं, और सबसे बुरे मामले में बहुत समय बर्बाद हो सकता है

    • जब समस्या पर काफ़ी सोच-विचार करके सही implementation के लिए ज़रूरी गुणों को स्पष्ट रूप से बताया जा सकता था, तब design document लिखना सबसे अधिक उपयोगी लगा
    • आंशिक समाधान implement करके उसे धीरे-धीरे बेहतर बनाना भी सफल रहा है