Ask HN: सॉफ़्टवेयर डिज़ाइन सीखने के लिए सबसे अच्छे कोडबेस कौन से हैं?

• मैं अपनी सॉफ़्टवेयर डिज़ाइन क्षमता बेहतर बनाने की कोशिश कर रहा हूँ, और मुझे सलाह दी गई कि मौजूदा अच्छी तरह डिज़ाइन किए गए कोडबेस का अध्ययन करूँ
• मैं जानना चाहता हूँ कि सार्वजनिक रूप से उपलब्ध कोडबेस में से किन्हें सॉफ़्टवेयर डिज़ाइन का गोल्ड स्टैंडर्ड माना जाता है

1. सिफारिश किए गए कोडबेस

• बड़े/प्रतिनिधि प्रोजेक्ट
  • Git, Postgres, CPython
  • Linux Kernel का "lieutenants model"
  • UNIX v6, BSDs
• फ्रेमवर्क/लाइब्रेरी
  • Spring Framework
  • Laravel
  • Rust std लाइब्रेरी
  • Codemirror 6
• सिस्टम/सर्वर
  • Postfix
  • Nginx
  • qmail
  • Varnish
• गेम/विशेष मामले
  • Doom 3
• शैक्षिक/सीखने की सामग्री
  • xv6 (MIT OS क्लास)
  • pytudes (Peter Norvig)
• अन्य
  • Monocypher (क्रिप्टोग्राफी लाइब्रेरी)
  • Tcl भाषा का implementation

2. कोड पढ़ना बनाम दस्तावेज़/डिज़ाइन सीखना

• सिर्फ कोड की सीमाएँ
  • कोडबेस implementation दिखाता है, लेकिन डिज़ाइन का इरादा या trade-offs छिपे रहते हैं
• डिज़ाइन दस्तावेज़ों का महत्व
  • ADR (Architectural Decision Records), Rust RFCs, Python PEPs जैसे decision records डिज़ाइन सीखने के लिए कहीं अधिक उपयोगी हैं
  • डिज़ाइन दस्तावेज़ लिखना खुद में एक अभ्यास हो सकता है
• किताबें/साहित्य की सिफारिश
  • The Architecture of Open Source Applications
  • Code Reading (Spinellis)
  • Beautiful Code (O’Reilly, ISBN-10: 0596510047)
  • Refactoring / Legacy Code से जुड़ी पुस्तकें

3. प्रैक्टिस-केंद्रित सीखने का दृष्टिकोण

• अनुभव और trial-and-error
  • डिज़ाइन बार-बार समस्याओं का सामना करके और उनसे बचना सीखकर आती है
  • सिर्फ कोड पढ़ने से सीख पूरी नहीं होती; खुद लिखने और विफलताओं को हल करने की प्रक्रिया में सीख मिलती है
• रुचि-आधारित सीखना
  • जिन प्रोजेक्ट्स में आपकी रुचि हो, उन्हें बनाने से आप गहराई से सीखते हैं
• विफलता की कम लागत
  • सॉफ़्टवेयर में भौतिक इंजीनियरिंग की तुलना में विफलता की लागत कम होती है, इसलिए कोशिश और असफलता के जरिए सीखना प्रभावी है

4. सॉफ़्टवेयर इंजीनियरिंग की प्रकृति पर बहस

• अपरिपक्व इंजीनियरिंग का तर्क
  • अगर पाँच इंजीनियर इकट्ठा हों और पाँच अलग समाधान दें, तो इसे इंजीनियरिंग के रूप में अपरिपक्वता का संकेत माना जा सकता है
• प्रयोग-अनुकूल प्रकृति का तर्क
  • सॉफ़्टवेयर में सीमाएँ कम होती हैं, इसलिए कई तरह के समाधान संभव हैं; भौतिक इंजीनियरिंग की तरह एक तय सही जवाब नहीं होता
• कला और इंजीनियरिंग की सीमा
  • डिज़ाइन सौंदर्य तत्वों वाली एक कलात्मक क्रिया भी है, लेकिन कार्यात्मक आवश्यकताओं को पूरा करने के पहलू में यह इंजीनियरिंग भी है
  • सॉफ़्टवेयर कलात्मक लचीलेपन और इंजीनियरिंग की कठोरता के बीच स्थित है

5. वैकल्पिक सीखने के तरीके

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

मुख्य इनसाइट्स

• अच्छी तरह डिज़ाइन किए गए कोडबेस मददगार होते हैं, लेकिन सीख तभी पूरी होती है जब डिज़ाइन के इरादे को समझा जाए और trial-and-error साथ चले
• सिर्फ कोड पढ़ने से ज्यादा डिज़ाइन दस्तावेज़ और decision records मुख्य सीखने की सामग्री हैं
• प्रमुख उच्च-गुणवत्ता वाले प्रोजेक्ट्स (Git, Postgres, CPython, Rust std आदि) सीखने के लिए बहुत मूल्यवान हैं
• सिर्फ अच्छे कोड ही नहीं, बल्कि कमज़ोर कोड और अपने खुद के कोड से सीखना लंबी अवधि में अधिक व्यावहारिक है

---

मुख्य टिप्पणियों का सार

प्रतिनिधि कोडबेस की सिफारिश (CraigJPerry)

• Postfix mail server
  • security-केंद्रित architecture, जो microservices की अवधारणा से पहले ही मिलती-जुलती संरचना दिखाता है
  • जहाँ आधुनिक microservices बड़े संगठनों में distributed systems पर ज़ोर देती हैं, Postfix को security और simplicity के लिए डिज़ाइन किया गया था
• Spring Framework
  • इसमें enterprise environment के Java developers की ज़रूरतों को गहराई से समझने वाली संस्कृति झलकती है
  • इससे user-centered design approach सीखी जा सकती है
• Git
  • object database (blob, tree, commit) और references की अवधारणा समझ लें, तो बाकी सब उसका क्रमिक विस्तार है
  • मुख्य अवधारणाओं का लगातार विस्तार अच्छे डिज़ाइन का उदाहरण है
• Varnish
  • high-performance reverse proxy होने के साथ-साथ इतना सुव्यवस्थित कोडबेस है कि इसे learning tool की तरह भी इस्तेमाल किया जा सकता है
• Linux Kernel Lieutenants Model
  • यह कोडबेस नहीं है, लेकिन बड़े पैमाने के सॉफ़्टवेयर प्रबंधन मॉडल के रूप में देखने लायक है
• ये सिर्फ "अच्छी तरह डिज़ाइन किया गया कोड" नहीं, बल्कि ऐसे उदाहरण हैं जहाँ डिज़ाइन निर्णय गहरी छाप छोड़ते हैं

व्यावहारिक कोडबेस से सीखने पर ज़ोर (crystal_revenge)

• सबसे बड़ा सीखने का मूल्य अपनी टीम के कोडबेस से मिलता है
• वास्तविक requirements और implementation के बीच के अव्यवस्थित जुड़ाव की प्रक्रिया में अच्छे और बुरे दोनों विकल्पों का अनुभव होता है
• वास्तविक constraints में सबसे बड़ा तत्व समय का दबाव है, और आदर्श डिज़ाइन व वास्तविकता के बीच संतुलन सीखना ही मुख्य बात है
• अच्छा सॉफ़्टवेयर वह है जो यूज़र की ज़रूरतें हल करे, और बार-बार के अनुभव से ऐसी डिज़ाइन सीखी जाती है जो सफलता की संभावना बढ़ाती है

पिछली चर्चाएँ और सामग्री लिंक (sprobertson)

• HN पर यही विषय कई बार उठ चुका है
  • Ask HN: What are some of the most elegant codebases in your favorite language?
  • Ask HN: Codebases with great, easy to read code?
  • Ask HN: Good Python codebases to read?

कोड बनाम डिज़ाइन दस्तावेज़ (alphazard)

• कोडबेस implementation का परिणाम है, स्वयं डिज़ाइन नहीं
• डिज़ाइन सीखने के लिए डिज़ाइन दस्तावेज़ लिखना अधिक प्रभावी है
  • दस्तावेज़ इतने स्पष्ट होने चाहिए कि कोई दूसरा व्यक्ति उन्हीं के आधार पर implementation कर सके
  • अगर विकल्पों की सूची बनाई जाए और यह भी दर्ज हो कि उन्हें क्यों छोड़ा गया, तो यह डिज़ाइन संबंधी विचार-विमर्श का प्रमाण बनता है
• अच्छा डिज़ाइनर वह है जो अधिक व्यापक design space पर विचार करे और उसमें सही बिंदु चुने

पूरे सिस्टम की समझ पर ज़ोर (RossBencina)

• पूरे कोडबेस को समझने की प्रक्रिया बेहद मूल्यवान है
  • इससे सिर्फ अच्छा कोड नहीं, बल्कि सिस्टम की बड़ी तस्वीर देखने का अभ्यास होता है
  • UML जैसे diagrams के जरिए संबंधों को visualise करना मददगार होता है
• सीखने का तरीका:
  • जिस तरह का सॉफ़्टवेयर आप बना रहे हैं, उससे मिलता-जुलता सॉफ़्टवेयर पढ़ना प्रभावी है
  • ऐसे डोमेन के कोड से शुरू करने की सलाह है जिन्हें आप पहले से जानते हों (web framework, web server, Python standard library, VSCode आदि)
  • शुरुआत में छोटे प्रोग्राम और परिचित डोमेन से शुरू करना बेहतर है

अच्छे डिज़ाइन का मानदंड (mamcx)

• अच्छा डिज़ाइन लक्ष्य और विचार है, और कोडबेस उससे जुड़ी implementation की गुणवत्ता दिखाता है
• अच्छा डिज़ाइन सिर्फ "तेज़ है, सुरक्षित है" जैसे विशेषण नहीं, बल्कि ठोस विचार और trade-offs का रिकॉर्ड भी होना चाहिए
• उदाहरण: Erlang, शुरुआती Pascal, और कई RDBMS डिज़ाइनों में यह विशेषता देखी जा सकती है
• Rust की std लाइब्रेरी security और consistency पर ज़ोर देती है, और उसका कोड व दस्तावेज़ इसे ईमानदारी से दर्शाते हैं; इसलिए यह सीखने की अच्छी सामग्री है

नज़र न आने वाले डिज़ाइन निर्णय (ben30)

• अच्छी तरह डिज़ाइन किए गए कोडबेस में सबसे महत्वपूर्ण हिस्सा वह होता है जो दिखाई नहीं देता
  • complexity को बाहर रखना, अनावश्यक abstraction से बचना, और कुछ patterns को अस्वीकार करना जैसी अनुपस्थिति में लिए गए निर्णय असली कुंजी हैं
• इसे पूरक करने के लिए ADR (Architectural Decision Records) उपयोगी हैं
  • इनमें विकल्प, उन्हें छोड़ने के कारण, और चयन के आधार दर्ज होते हैं, जिससे संदर्भ बचा रहता है
  • भविष्य के maintainers और AI tools, दोनों के लिए यह बहुत मददगार होता है
• सीखते समय सिर्फ कोड नहीं, बल्कि ADR, RFC, PEP जैसे डिज़ाइन decision documents वाले प्रोजेक्ट्स भी देखना प्रभावी है

[shaffr0n]

Evan You (Vue.js, Vite के निर्माता) के एक इंटरव्यू में सुना था कि TJ Holowaychuk द्वारा बनाया गया express.js बहुत साफ़-सुथरे और खूबसूरत तरीके से डिज़ाइन किया गया है, इसलिए मैंने उसका कोड कुछ बार पढ़ने की कोशिश की। मैं उसका पूरा बड़ा चित्र तो समझ नहीं पाया, लेकिन कुल मिलाकर यह महसूस हुआ कि कोड जटिल नहीं है और उसमें सिर्फ़ ज़रूरी logic ही बहुत साफ़ तरीके से लिखा गया है.

Comments भी अच्छे से लिखे गए हैं, इसलिए 10 साल पुराना कोड होने के बावजूद type inference या DTO format समझने में काफ़ी मदद मिली.

[wedding]

स्पैम टिप्पणियों से ढके हुए ब्लॉग की 2009 की पोस्ट को रेफरेंस मानना..

[GN⁺]

Hacker News राय

• शायद यह सिर्फ मेरे साथ नहीं है, लेकिन मुझे लगता है कि असल में बार-बार समस्याओं से टकराना और उनसे बचना खुद सीखना सबसे असरदार तरीका है। ऐसा करते-करते दिमाग में यह सिम्युलेट करना आसान हो जाता है कि आगे किस तरह की समस्या आ सकती है, और आखिरकार design भी यही है कि भविष्य की अलग-अलग समस्याओं का पहले से अनुमान लगाकर उनसे बचा जाए, किस समस्या से कितनी मेहनत में बचना है, और क्या एक ही design से कई समस्याएँ सुलझ सकती हैं—इन trade-offs पर सावधानी से निर्णय लेना

  • मेरा भी यही अनुभव है। "practice problems हल करना" या "codebase पढ़ना" जैसी चीज़ें मेरे लिए काम नहीं आईं। जब मैं वह चीज़ बनाता हूँ जिसमें मेरी सच में दिलचस्पी होती है, और examples में correctness व thoroughness पाने की कोशिश करता हूँ, तब मैं स्वाभाविक रूप से सीखता हूँ। लेकिन कभी-कभी अब भी लगता है कि मेरी skill कम है। अगर मैं किताब पढ़ने की तरह code को आसानी से पढ़ पाता और दिमाग में उसका behavior उभर आता, तो शायद पढ़ाई खुद भी ज़्यादा मज़ेदार होती

  • यह सुनकर कि लोग बार-बार समस्याओं से टकराकर सीखते हैं, मुझे यही लगता है कि software engineering अभी परिपक्व क्षेत्र नहीं है। ज़रा सोचिए, अगर पुल या घर ऐसे बनाए जाते, या surgeons ऐसे train होते, तो कितना ख़तरनाक होता। समय के साथ standards और norms बनेंगे, लेकिन अभी स्थिति बहुत fluid है। पाँच software engineers को एक समस्या दें, तो पाँच बिल्कुल अलग solutions मिलेंगे ही, साथ में इस पर भी कड़ा मतभेद होगा कि सही तरीका कौन-सा है। मुझे नहीं लगता कि सिर्फ "अच्छा solution दिखे तो पहचान लेंगे" वाला रवैया सही engineering कहलाएगा

  • मैं भी अब तक लगातार इसी तरीके से सीखता आया हूँ और आगे भी शायद ऐसे ही सीखूँगा। असली production code से सीखना मेरे लिए एक नई चुनौती होगी। यह कितना valuable होगा, पता नहीं, लेकिन मज़ेदार ज़रूर लग रहा है

  • यह कुछ वैसा है जैसे driving सीखने के लिए पहली बार गाड़ी चलाओ, accident कर दो, फिर उस पर सोचो और अगली बार accident न करने की कोशिश करो। असल में दोनों तरीकों की ज़रूरत होती है। आम सड़कों पर हम अक्सर limit push नहीं करते, इसलिए वहाँ यह बात तुरंत लागू नहीं होती, लेकिन racing जैसी चीज़ों में यह ठीक-ठीक जानना ज़रूरी है कि सीमा कहाँ तक है। बेशक, मैं यह नहीं कह रहा कि हमें अपने पेशे को खेल की तरह लेना चाहिए। लेकिन अगर आप किताबें नहीं पढ़ेंगे और पढ़ाई नहीं करेंगे, तो न सिर्फ बहुत ज़्यादा समय लगेगा बल्कि हादसे और breakdown भी लगातार होते रहेंगे। इसलिए मैं कहूँगा: पढ़ो, और बार-बार पढ़ो। अभी शायद उसकी ज़रूरत महसूस न हो, लेकिन आगे अनुभव बढ़ने पर वह ज्ञान कहीं न कहीं काम ज़रूर आएगा, और आप उस तरह नहीं घबराएँगे जैसे पहली बार ढलान पर engine braking के लिए low gear में shift करना सीखते समय घबराहट होती है

  • यही बिल्कुल मूल बात है

• यह सवाल सुनते ही मेरे दिमाग में सबसे पहले "आपकी टीम का codebase" आता है। असली समस्याओं पर अच्छे और बुरे solutions क्यों चुने गए, इसे गहराई से समझने जितना प्रभावी तरीका software design सीखने का शायद ही कोई और हो। Software अपने मूल में user requirements और machine behavior के बीच की जटिल मध्य-परत ही है। अगर यह उलझन होती ही नहीं, तो सब कुछ पहले ही automate हो चुका होता और software की ज़रूरत ही नहीं पड़ती। Software में अगर आप किसी ideal form के पीछे भागते रहें, तो अक्सर खराब decisions लेते हैं। असल सीख यह समझने में है कि "किन pressures के कारण यह चुनाव किया गया"। इसी से trial-and-error कम होता है। साथ ही तेज़ और असरदार ढंग से काम करने की practical methodology भी सीखनी पड़ती है। वास्तविक दुनिया की सबसे बड़ी चुनौती time constraint है। सैद्धांतिक software design में इस पर बहुत कम बात होती है, लेकिन व्यवहार में लगभग हमेशा code जल्दी ship करने का दबाव होता है। अक्सर आपके पास वह करने का समय नहीं होता जो आप करना चाहते हैं या जो technically सबसे अच्छा होता। अच्छा software वही है जो users की वास्तविक ज़रूरतें हल करे। आगे चलकर कुछ design solutions बार-बार सफल execution की संभावना बढ़ाते हैं, और उन्हें खोजने का सबसे अच्छा तरीका है अपने लिखे हुए code को गहराई से देखना

  • अगर सवाल पूछने वाला अपने team software को बहुत खराब मानकर बाहर से सलाह लेना चाहता हो, तो फिर क्या? या अगर सवाल सिर्फ किसी college student का हो तो?

  • मैंने कभी इस कोण से नहीं सोचा था कि implementation में लगने वाला समय भी design quality का एक measure हो सकता है, लेकिन यह बात वाकई सही लगती है। मैं भी अपनी team के codebase से बहुत कुछ सीख रहा हूँ। उसमें से काफी कुछ अच्छे designs से सीखा है, और जो हिस्से अच्छे नहीं हैं, उन्हें देखते हुए भी मैं लगातार Google करके सीखता रहता हूँ

• यह सामग्री कुछ साल पुरानी है, लेकिन कई open source project leaders के लेखों की एक series है, "The Architecture of Open Source Applications", जिसे online मुफ़्त पढ़ा जा सकता है
  https://aosabook.org/en/index.html

• यह सवाल पहले भी कई बार पूछा जा चुका है, इसलिए मैंने कुछ संदर्भ links इकट्ठा किए हैं

  • https://news.ycombinator.com/item?id=36370684
  • https://news.ycombinator.com/item?id=30752540
  • https://news.ycombinator.com/item?id=9896369 (Python-केंद्रित)

• Yanderedev source code

• मैं इतना योग्य नहीं हूँ कि अंतिम उत्तर दे सकूँ, लेकिन लगभग 15 साल पहले मैंने "Code Reading" नाम की एक किताब बहुत मज़े से पढ़ी थी। यह इस विषय पर बिल्कुल फिट बैठती है
  https://www.spinellis.gr/codereading/
  contents page: https://www.spinellis.gr/codereading/toc.html
  शायद इसी तरह के नाम की कोई और किताब भी थी, लेकिन ठीक से याद नहीं

• असल में codebase में अक्सर design से ज़्यादा implementation होता है। उदाहरण के लिए, अगर आप किसी चीज़ को पूरी तरह किसी दूसरी language में rewrite कर दें, तब भी design बना रह सकता है। मैं design documents लिखने की practice की सलाह दूँगा। Document कैसा दिखना चाहिए, इस पर ज़्यादा मत अटकिए, और किसी template से बँधने की ज़रूरत भी नहीं है। सबसे ज़रूरी बात यह है कि कोई दूसरा व्यक्ति उस document को लेकर सीधे implementation कर सके। साथ ही, यह document "सोच-विचार के प्रमाण" की तरह काम कर सकता है। आपने कौन-सा तरीका चुना, कौन-से alternatives थे, और उन्हें क्यों नहीं चुना—यह साफ़ लिख दीजिए। Alternatives को पहले से स्वीकार कर उनकी तुलना कर देने से पाठक को भरोसा होता है कि आपने पर्याप्त सोच-विचार किया है। एक "अच्छा" system designer वही करता है: वह दूसरों की तुलना में बड़े design space को देखता है और लगातार अच्छे points पहचानता है। एक समस्या चुनिए, अलग-अलग design spaces explore कीजिए, और उनमें से कौन-सा बेहतर है और क्यों—यह सब लिखकर दर्ज कीजिए

• सबसे पहले सवाल होना चाहिए: "मैं कौन-सी समस्या हल करना चाहता हूँ?" फिर उस समस्या को हल करने वाले codebase खोजिए और ध्यान से देखिए कि उसे वास्तव में कैसे implement किया गया है। यह याद रखना ज़रूरी है कि अच्छा design किसी खास domain context से बहुत गहराई से जुड़ा होता है। मुझे लगता है Wonham का Internal Model Principle code पर भी लागू होता है। उदाहरण के लिए, मैं embedded targets के लिए unit testing की समस्या हल करना चाहता था, इसलिए मैंने संबंधित open source projects का विश्लेषण किया और आलोचनात्मक नज़र से देखा कि code इस तरह क्यों लिखा गया। फिर अपना solution बनाते समय मैं बार-बार उन पुराने codebases की तरफ लौटता रहा, और जैसे-जैसे मेरी domain understanding गहरी हुई, मैं और ज़्यादा सीखता गया

• मेरे अनुभव (30 साल software में, 25 साल architecture practice में, MIT से systems architecture में master's) के अनुसार अमूर्त अर्थ में "अच्छा" design जैसी कोई चीज़ नहीं होती। हाँ, बुरे designs होते हैं—यानी ऐसे designs जो खराब परिणाम लाते हैं—लेकिन "अच्छा" होने का मापदंड context पर निर्भर करता है। आप क्या बना रहे हैं, safety/security जैसी requirements क्या हैं, और सबसे बढ़कर उसे implement करने वाली टीम और उसकी संरचना कैसी है—इनका बहुत असर पड़ता है। अगर टीम में सिर्फ juniors हों, तो वे किसी sophisticated design को गलत समझकर बिगाड़ भी सकते हैं। Conway's Law की तरह, development team की संरचना software में झलकती है

  • software design सीखते हुए मैंने भी पक्का यही समझा है कि कोई silver bullet नहीं है। काश ऐसा कुछ होता, लेकिन इतने सारे architectures और paradigms के बीच सबसे अच्छा विकल्प चुनना कभी-कभी बहुत frustrating लगता है। फिर भी, अगर requirements साफ़ हों तो विकल्प काफी कम हो जाते हैं। अभी मैं safety-critical embedded systems पर काम कर रहा हूँ, और इस environment की वजह से मुझे अक्सर ऐसे decisions लेने पड़ते हैं जिनका दूसरी परिस्थितियों में कोई उपयोग ही नहीं होता

  • आख़िरकार बात यही है कि पूरी तरह बेहूदा compromises से बचा जाए, और broad view से देखें तो सबसे खराब choices से भी बचा जाए। मैदान में लगातार यही महसूस होता है कि यह "best architecture" खोजने से ज़्यादा "मूल रूप से बुरे decisions से बचने" की लड़ाई है

• मैंने कभी एक बहुत simple recommendation list बनाई थी, और वह अब भी ठीक लगती है
  https://medium.com/@012parth/what-source-code-is-worth-studying-8755f88f8de5

[roxie]

बीच में एक जाल है..

[ffdd270]

क्या यह Yanderedev का source code है... lol