README Driven Development (2010)

 (tom.preston-werner.com)
44 पॉइंट द्वारा xguru 2024-06-25 | 9 टिप्पणियां | WhatsApp पर शेयर करें
  • README-चालित डेवलपमेंट: सॉफ़्टवेयर डेवलपमेंट में README को पहले लिखने का एक approach
  • TDD, BDD, Extreme Programming, SCRUM जैसी विभिन्न डेवलपमेंट methodologies और techniques के बारे में अक्सर सुनने को मिलता है
    • लेकिन, अगर हम जो सॉफ़्टवेयर बना रहे हैं वह user की ज़रूरतों को पूरा नहीं करता, तो बाकी सब बेकार है
    • implementation पूरी तरह सही हो, फिर भी अगर वह गलत specification का पालन करती है तो उसका कोई मूल्य नहीं, और बिना documentation वाली सुंदर library भी लगभग बेकार है
    • अगर सॉफ़्टवेयर गलत समस्या हल करता है या उसका उपयोग कैसे करना है यह पता न चले, तो गंभीर समस्या पैदा होती है

समाधान: README से शुरुआत करें

  • README पहले लिखने की वजह
    • code, test, story आदि लिखने से पहले README लिखें
    • README लिखना अच्छा सॉफ़्टवेयर बनाने की एक ज़रूरी step है
    • सॉफ़्टवेयर के बारे में लिखे बिना यह स्पष्ट नहीं होता कि क्या code करना है
    • README के ज़रिए project को व्यवस्थित ढंग से सोचा जा सकता है
  • README पहले लिखने के फायदे:
    • project पर व्यवस्थित रूप से सोचने का मौका:
      • code बदले बिना project के बारे में व्यवस्थित रूप से सोचा जा सकता है
      • coding से पहले project की structure और उसमें शामिल होने वाले API पर विचार किया जा सकता है
    • बेहतर documentation सुनिश्चित करना:
      • project की शुरुआत में, जब motivation और रुचि सबसे अधिक होती है, उसी समय documentation लिखा जा सकता है
      • बाद में README लिखना उबाऊ हो सकता है और महत्वपूर्ण details छूट सकती हैं
    • team के काम की efficiency बढ़ाना:
      • team के दूसरे developers project पूरा होने से पहले ही interface की जानकारी साझा पाकर अपना दूसरा काम भरोसे के साथ शुरू कर सकते हैं
      • स्पष्ट interface के बिना काम करने पर बड़े पैमाने पर code को दोबारा करना पड़ सकता है
    • ठोस चर्चा की नींव देना:
      • text में प्रस्तावित समाधान लिख देने भर से सभी लोग एक स्पष्ट idea के साथ चर्चा कर सकते हैं
  • README Driven Development (RDD) की विशेषताएँ:
    • RDD को Documentation Driven Development (DDD) का एक subset या सीमित version माना जा सकता है
    • RDD, design document को एक ही file तक सीमित रखकर अत्यधिक specification लिखने की समस्या को रोकता है
    • यह छोटे, modular libraries बनाए रखने के लिए प्रेरित करता है

निष्कर्ष

  • README लिखने की प्रक्रिया को एक सच्ची "रचनात्मक क्रिया" के रूप में देखें
  • आपके सभी शानदार ideas इस document में व्यक्त होने चाहिए, और यह document स्वयं आपकी creativity और अभिव्यक्ति का प्रमाण होना चाहिए
  • README codebase का सबसे महत्वपूर्ण document होना चाहिए, और उसे सबसे पहले लिखना ही सही approach है

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

9 टिप्पणियां

 
princox 2024-06-26

चाहे वह software हो, उपन्यास हो या फ़िल्म, किसी भी तरह की रचना बनाते समय
अगर कागज़ सामने रखकर design और planning के साथ बनाया जाए, तो शायद बारीक details को ज़्यादा आसानी से संभाला जा सकता है.. :)
 
markman 2024-06-26

मैं अब तक सबसे बुनियादी बात भूलकर जी रहा था, लेकिन अब इसे अमल में लाना होगा।
 
halfenif 2024-06-25

हमने तय किया कि इसे "बेसिक डिज़ाइन" कहेंगे।
 
gargoyle92 2024-06-25

अनजाने में यह मेरे काम करने के तरीके और संदर्भ से काफ़ी मिलता-जुलता है।
लगता है कि वह हिस्सा README के रूप में निकलकर सामने आता है।

मैं काम करते समय What, Why, How आदि को स्पष्ट रूप से लिखकर आगे बढ़ता हूँ, और साथ-साथ आगे किए जाने वाले काम की रूपरेखा बनाता जाता हूँ, इसलिए यह उससे मिलता-जुलता लगता है।
 
kandk 2024-06-25

README-आधारित डेवलपमेंट
 
dbs0829 2024-06-25

मैं एक research organization में काम करता/करती हूँ, इसलिए research किए गए नतीजों को code के रूप में release करने को लेकर काफी सोच-विचार रहा है। मुझे लगता है कि README-driven development हमारे लिए अच्छी तरह फिट हो सकता है। यह research की शुरुआत के चरण से ही विचार करने लायक तरीका लगता है।
 
jamsya 2024-06-25

इसी तरह, जब मैं backend पर काम करता हूँ तो स्क्रीन देखते हुए पहले API दस्तावेज़ का एक rough draft लिख लेता हूँ,
और इससे trial and error कम करने में काफ़ी मदद मिली है.
 
bbulbum 2024-06-25

देखा जाए तो यह पहले उस समस्या को ठीक-ठीक परिभाषित करने की अहमियत जैसा लगता है जिसे हल करना है।
 
xguru 2024-06-25

यह 2010 की पोस्ट है, लेकिन दूसरी पोस्ट पढ़ते हुए मिली तो सोचा यहाँ शेयर कर दूँ।