- सॉफ्टवेयर डिज़ाइन लेक्चर की तुलना में वास्तविक प्रोजेक्ट्स में ज़िम्मेदारी लेने और समस्या सचमुच अपनी होने पर अधिक गहराई से सीखा जाता है
- Conway’s Law यह दृष्टिकोण है कि सॉफ्टवेयर संगठन की सामाजिक संरचना को दोहराता है, और scientific code तथा industry code के बीच का अंतर incentives से भी पैदा हो सकता है
- rust-analyzer तेज़ build, stable support, C dependency हटाने, और कुछ सेकंड में चलने वाले tests के ज़रिए उच्च-प्रभावी contributors के लिए फोकस करना आसान बनाता है
- rust-analyzer ने स्वतंत्र features को
catch_unwind से सुरक्षित किया और PR के मानदंड कम किए, लेकिन मुख्य spine पर कहीं अधिक सख्त quality standards लागू किए
- प्रयोगात्मक संरचना लंबे समय की वास्तविकता बन सकती है, और rust-analyzer भी LSP architecture prototype से आगे बढ़कर एक और compiler को maintain करने तक पहुँचा
सॉफ्टवेयर डिज़ाइन मैदान में सबसे अच्छी तरह सीखा जाता है
- सॉफ्टवेयर डिज़ाइन औपचारिक लेक्चर से अधिक तब सीखा जाता है जब आप वास्तविक प्रोजेक्ट में ज़िम्मेदारी लेते हैं और समस्याओं को खुद हल करते हैं
- यूनिवर्सिटी डिज़ाइन क्लास और course projects में “architect” की भूमिका निभाने की तुलना में, दूसरे वास्तविक प्रोजेक्ट IntelliJ Rust में जब डिज़ाइन समस्याएँ सचमुच अपनी बन गईं, तभी सीखना गंभीर रूप से शुरू हुआ
- IntelliJ Rust में कुछ गलतियाँ हुईं, लेकिन वे विनाशकारी नहीं थीं, और उसी प्रक्रिया में बहुत कुछ सीखा जा सका
- Software engineering का एक पक्ष इतना सरल भी है कि जिज्ञासु लोग सिद्धांतों से सोचकर और कई लेख पढ़कर इसे सीख सकते हैं
incentive structure और Conway’s Law
- Conway’s Law यह दृष्टिकोण है कि सॉफ्टवेयर उसे बनाने वाले संगठन की सामाजिक संरचना को दोहराता है
- industrial software और scientific code के बीच का अंतर स्वयं software construction knowledge से अधिक, उन incentive structures से उत्पन्न हो सकता है जो लोगों को सॉफ्टवेयर बनाने के लिए प्रेरित करती हैं
- “3 महीने के भीतर paper publish करना है” जैसी PhD स्थिति scientific code के रूप को तय करने वाला एक महत्वपूर्ण कारक हो सकती है
- incentive structure का सामना मोटे तौर पर दो तरीकों से किया जा सकता है
-
प्रोजेक्ट के incentives को डिज़ाइन करना या बदलना
- प्रोजेक्ट की incentive structure को डिज़ाइन या समायोजित करने का अवसर कम ही मिलता है, लेकिन जब मिलता है तो उसका प्रभाव बड़ा होता है
- TIGER_STYLE का सार केवल rules की सूची में नहीं, बल्कि उस social context में है जो उन rules को अच्छे चुनाव में बदलता है
-
अगर बदल नहीं सकते, तो constraints के अनुसार ढलें
- incentive structure शायद ही कभी मनचाहे रूप में मिलती है, और यदि आप उसे बदल नहीं सकते तो उसके अनुसार खुद को ढालना पड़ता है
- industrial software projects में भी “ठीक से करने का समय” लगभग कभी नहीं होता, और दिए गए constraints के भीतर जितना संभव हो उतना अच्छा करना पड़ता है
rust-analyzer में structure और participants को मिलाने का तरीका
- rust-analyzer एक ऐसा प्रोजेक्ट है जिसमें depth और breadth दोनों हैं
- गहरे पक्ष में, compiler होने की प्रकृति के कारण यह उत्कृष्ट और समर्पित contributors को आकर्षित कर सकता है
- चौड़े पक्ष में, पारंपरिक IDE में उद्देश्य-विशेष के कई features होते हैं, इसलिए Rust सीखने वाले या लगातार योगदान न दे पाने वाले weekend contributors के लिए अपनी असुविधा दूर करने में एक-दो घंटे लगाना उपयुक्त होता है
- rust-analyzer ने
rustc build की आवश्यकता न रखने, stable पर build होने, C dependency न होने, और पूरी test suite को कुछ ही सेकंड में पूरा करने पर इसलिए ज़ोर दिया ताकि उच्च-प्रभावी contributors को आकर्षित किया जा सके
- build system को इस तरह तराशने की कोशिश की गई कि लोग दूसरी बातों की चिंता किए बिना borrow checker पर काम करने पर ध्यान दे सकें
- weekend contributors को आकर्षित करने के लिए rust-analyzer के अंदरूनी हिस्से को कई स्वतंत्र features में बाँटा गया, और हर feature को runtime पर
catch_unwind से सुरक्षित किया गया
- feature PR के लिए मानदंड को “happy path काम करे और test मौजूद हों” तक कम किया गया, और यह भी स्वीकार्य माना गया कि संबंधित code crash कर सकता है
- हालांकि, इसके लिए दो शर्तें ज़रूरी थीं
- quality problems व्यक्तिगत features के भीतर अलग-थलग रहें और दूसरे हिस्सों में न फैलें
- runtime crashes उपयोगकर्ता को दिखाई न दें; इसके लिए rust-analyzer features immutable snapshots पर काम करते हैं और data को दूषित नहीं कर सकते
- इसके उलट, features को सहारा देने वाली केंद्रीय spine पर कहीं अधिक कठोर quality standards लागू किए गए
प्रयोगात्मक संरचना के लंबी अवधि की वास्तविकता बन जाने का जोखिम
- incentive structure को ठीक करने के बजाय उसके अनुरूप ढलते समय सावधान रहना चाहिए कि भविष्य अनिश्चित होता है, और अक्सर सबसे असुविधाजनक तरीके से वास्तविकता बन सकता है
- rust-analyzer की मूल प्रेरणा IntelliJ Rust के भीतर एक और parallel compiler लिखने से बचना, और LSP के लिए बेहतर architecture को prototype के रूप में सत्यापित कर उस सीख को
rustc में वापस ले जाना था
- इसलिए core तक का code बहुत प्रयोगात्मक था
- परिणामस्वरूप, अंत में एक और compiler को maintain करना पड़ा
- इसी तरह uutils project भी Rust सीखने वालों के प्रमुख गंतव्य के रूप में शुरू हुआ था, और Ubuntu के coreutils implementation तक पहुँच गया
देखने लायक सामग्री और किताबें
- सही जवाबों वाली कोई एकल किताब नहीं है, और वास्तविक अभ्यास एक अनिवार्य तत्व लगता है
- Boundaries by Gary Bernhardt
- इसमें ठोस व्यावहारिक सलाह है, और इसने अधिक उच्च-स्तरीय खोजबीन को प्रेरित किया
- How to Test
- tests की महत्ता तुरंत समझ में आ गई थी, लेकिन व्यापक रूप से उद्धृत कई testing सलाहें व्यवहारिक नहीं हैं—यह मानने और जो वास्तव में काम करता है उसे अवधारणात्मक रूप देने में बहुत समय लगा
- ∅MQ guide और Pieter Hintjens के लेख
- इनसे Conway’s Law जैसी सोच से परिचय हुआ
- rust-analyzer का feature development architecture optimistic merging का एक अनुप्रयोग है
- Reflections on a decade of coding by Jamii
- यह बहुत meta विषयों को छूता है, और इतना उत्कृष्ट है कि इसे लिंक संग्रह की पहली प्रविष्टि बनाया गया
- Ted Kaminski ब्लॉग
- एक ऐसी किताब के नोट्स के रूप में जिसका अस्तित्व ही नहीं है, यह software development पर एक सुसंगत theory के सबसे करीब पहुँचता है
- Software Engineering at Google और Ousterhout की The Philosophy of Software Design
1 टिप्पणियां
Hacker News की राय
अगर इसे चीटशीट की तरह संक्षेप में कहें, तो अच्छा डिज़ाइन वह है जिसमें एक ही विचार पूरे सिस्टम में व्याप्त हो और आश्चर्य को न्यूनतम करे
अगर सिस्टम अनुमति देता है, तो लोग आखिरकार उसी तरह उसका इस्तेमाल करेंगे, और “अगर सब लोग बस X कर दें” से शुरू होने वाला समाधान, समाधान नहीं है
डेटा को transform करने वाले हिस्से और उसे उपयोग करने वाले हिस्से को अलग रखना चाहिए, data model कोड से ज़्यादा लंबे समय तक टिकता है, और coupling कई समस्याओं की जड़ है
versioning से बचा नहीं जा सकता, state को स्पष्ट रूप से दिखना चाहिए, और हर जानकारी के लिए एक single source of truth होना चाहिए
naming पर ज़्यादा समय लगाओ, अगर testing मुश्किल है तो डिज़ाइन गलत है, और जो निर्णय document नहीं किए जाते उन पर बाद में पछताना पड़ता है
communication की लागत होती है, इसलिए उसे चुकाने से पहले उसका औचित्य होना चाहिए, और engineer का काम अधूरी जानकारी में heuristic के सहारे समस्याएँ हल करना है
लेख खुद भी software architecture के नज़रिए से बहुत सुसंगत नहीं था
4+1 architecture view, UML को छोड़ भी दें, तो बड़े चित्र के बारे में सोचने का एक अच्छा conceptual framework है, और Pattern-Oriented Software Architecture series भी उन अलग-अलग architectures को अच्छे से व्यवस्थित करती है जहाँ लोग पहुँचते हैं
एक समय Grady Booch software architecture handbook बना रहे थे, लेकिन अब वह लगभग रुका हुआ लगता है, और तब mailing list में कंपनियों या बड़े open source projects की बड़ी system architectures को document किया जाता था
ऐसे स्रोतों में गहराई से जाएँ तो दिखता है कि architecture अलग-अलग फोकस—जैसे scale, safety, performance, interoperability, fail-safe—के अनुसार बनती है, और हर लक्ष्य के अपने यथार्थवादी trade-off होते हैं
इस कसौटी पर अगर कुछ बेहतर है, तो वह खराब डिज़ाइन जैसा दिखने पर भी वास्तव में अच्छा डिज़ाइन है
interface ऐसा होना चाहिए कि सही तरह से इस्तेमाल करना आसान हो और गलत इस्तेमाल करना कठिन, और यह सोचना चाहिए कि कोई ऐसा व्यक्ति जो project को नहीं जानता, वह इसका उपयोग कैसे करेगा
सही code लिखना आसान होना चाहिए, संदिग्ध code तुरंत दिखना चाहिए, और bugs को जितना हो सके उतना left shift करना चाहिए
एक bug ठीक करने से बेहतर है पूरी bug class को खत्म कर देना, और interface implementation से बदलना कठिन होता है, इसलिए अगर interface सही है तो बदसूरत implementation भी स्वीकार्य है
comments और documentation को यह बताना चाहिए कि code ऐसा क्यों है, और अगर ऊपर-ऊपर देखने पर कोई और सरल तरीका दिखता है लेकिन किसी constraint की वजह से वह संभव नहीं है, तो वह बात दर्ज रहनी चाहिए
data के नज़रिए से duplication नहीं होना चाहिए; वही तथ्य कई जगह store करोगे तो अंततः mismatch होगा और bugs आएँगे
well-trodden path से हटने की लागत होती है, और कभी-कभी वह वाजिब होती है, लेकिन उस लागत को कम नहीं आँकना चाहिए
कई बार जो उबाऊ technology बदतर लगती है वही बेहतर technology साबित होती है, और सवाल “क्या यह करने लायक है?” नहीं बल्कि “क्या यह दूसरी चीज़ करने की तुलना में करने लायक है?” होना चाहिए
चाहे आपको लगे कि आप दूसरों से ज़्यादा बुद्धिमान हैं, कुछ समस्याएँ सिर्फ बुद्धि से नहीं सुलझतीं, और कुछ समस्याएँ वास्तव में फटने तक दिखती ही नहीं, इसलिए दूसरों की गलतियों से सीखना चाहिए
friction एक शांत हत्यारा है
planning अच्छी है, लेकिन कभी-कभी चीज़ों को खुद करके देखना पड़ता है, और हर चीज़ की कीमत होती है
अगर लागत को सोचे बिना डिज़ाइन करोगे, तो बाद में कठिन चुनाव करने पड़ेंगे
अकेले बनाए जा रहे project में भी engine की constraints यह मार्गदर्शन देती हैं कि “testing के दौरान निकली अजीब नई feature को इस तरह जोड़ो”
इससे हर बार “अगर किसी खास state transition में कई बार चलने वाला नया sound effect बनाना हो तो ऐसे करो” जैसी विशाल documentation साथ लेकर चलने की ज़रूरत नहीं पड़ती
system designer को industry समझनी चाहिए; उनके terms और modeling habits को पूरी तरह अपनाना ज़रूरी नहीं, लेकिन वे dataset को किस कारण और किस नज़रिए से देखते हैं, यह समझना चाहिए
हमने medical market की जटिलता को जानबूझकर सरल किया है ताकि अनावश्यक over-definition हटे और एक अधिक unified model मिल सके, लेकिन ऐसे बदलाव हम आत्मविश्वास से इसलिए कर पाए क्योंकि problem domain को अच्छी तरह समझते थे
खासकर नाम लगभग कभी नहीं मरते
कभी-कभी बदलते हैं, लेकिन किसी नाम को बदलने के लिए बेहद भारी प्रयास चाहिए, इसलिए domain experts से naming proposals की लंबे समय तक समीक्षा करवाना, ताकि कुछ छूटा न हो, वाकई बहुत मूल्यवान है
कुछ concepts को आगे बढ़ाया जा सकता है, लेकिन sales·marketing जैसे business पक्ष बार-बार industry terms की माँग करते हैं और model को मौजूदा industry view के अनुरूप रखने का दबाव डालते हैं
अगर आपने उस प्रवाह को तोड़ने का फैसला किया है, तो वह विच्छेद इरादे और उद्देश्य के स्तर पर स्पष्ट होना चाहिए
software में सबसे अधिक ज़ोर maintainability पर होना चाहिए
इसे बनाने में कितना खर्च आता है यह भी सवाल है, लेकिन इसे चलाने की लागत—जो सिर्फ infrastructure नहीं बल्कि समय के साथ जमा होने वाली feature requests, code refactoring, और third-party software version maintenance भी शामिल करती है—कहीं ज़्यादा असर डालती है
सिफारिशों की सूची अक्सर Ousterhout की A Philosophy of Software Design जैसी अच्छी होती है, लेकिन कुल मिलाकर यह खुद software architecture से ज़्यादा software development की सामान्य समझ के करीब है
architecture देखनी हो तो Shaw/Garlan की Software Architecture: Perspectives on an Emerging Discipline जैसे classics और Mary Shaw के लेख सुझाऊँगा
software architecture क्षेत्र अपेक्षित दिशा में क्यों नहीं बढ़ा, इस पर Myths and Mythconceptions: What Does It Mean to Be a Programming Language, Anyhow? और Revisiting Abstractions for Software Architecture and Tools to Support Them जैसे हालिया papers भी अच्छे हैं
व्यावहारिक रूप से, Unix pipe and filter, REST क्यों सफल हुए और कहाँ व क्यों टूटते हैं, यह देखना उपयोगी है, और Hexagonal Architecture भी केंद्रीय महत्व रखता है
व्यक्तिगत रूप से, software architecture और metaobject protocol को जोड़कर programming languages और programming की नई बुनियाद की तरह देखने वाला Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status भी है
यह Mary Shaw के Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status के जवाब की तरह है, और पूछता है कि अगर procedure call assembly language है, तो high-level language कैसी दिखेगी
शायद software architecture का भविष्य और उज्ज्वल तथा अधिक व्यावहारिक हो सकता है
कुछ data structures, types, और छोटे primitive functions के संग्रह हों, तो उन्हें compose किया जा सकता है
Lisp में मुझे यह पसंद है कि अधिक जटिल types, खासकर FFI से आए types, हमेशा opaque रहते हैं
मैं ऐसा CLOS implementation देखना चाहूँगा जिसमें C-जैसी भाषा में struct define करने पर standard functions का एक set मिल जाए
architecture सीखने का सबसे अच्छा तरीका पर्याप्त बड़ा project बनाना नहीं, बल्कि उसका maintenance करना है
और वह भी कम से कम दो-तीन projects में
अगर project बहुत छोटा हो तो कोई भी architecture काम कर जाती है, और “बड़ा” project code lines से नहीं बल्कि उस पर काम कर चुके लोगों की संख्या, या उससे भी बेहतर teams की संख्या से आँकना चाहिए
तुलना के लिए कम से कम दो अलग projects होने चाहिए, और मैंने ऐसे लोगों को देखा है जो दशकों तक एक ही project में फँसे रहे और आधुनिक समस्या-समाधान के तरीकों से अनजान रहे
लेकिन व्यवहार में अक्सर वही लोग architect बनते हैं जिन्होंने project बनाया था; maintenance करने वाले लोग कम ही बनते हैं
Google में यह और भी स्पष्ट है: promotion के लिए नई चीज़ ship करनी पड़ती है, maintenance से promotion नहीं मिलता, और संभव हो तो launch के तुरंत बाद निकल जाना ज़्यादा फायदेमंद होता है
विडंबना यह है कि architect बनने के लिए सबसे अच्छी स्थिति शायद बाहरी contractors की होती है जिन्हें कंपनी के भीतर कोई नहीं लेना चाहता ऐसे legacy projects के maintenance में लगाया जाता है
उन्हें architecture को बनाए रखना पड़ता है और वे कई projects से गुजरते हैं, इसलिए तुलना कर सकते हैं
लेकिन अगर वे घंटे के हिसाब से billing करते हैं, तो architecture को ज़रूरत से ज़्यादा जटिल बनाने का जोखिम रहता है ताकि अधिक समय bill किया जा सके
इस संदर्भ में मैं Architecture of Open Source Applications की सचमुच सिफारिश करूँगा
यह किताबों की एक series है जिसमें हर chapter उस project के maintainer ने लिखा है, इसलिए examples के ज़रिए architecture सीखी जा सकती है
इससे सिर्फ यह नहीं पता चलता कि architecture क्या है, बल्कि वे constraints भी समझ आते हैं जिन्होंने उसे बनाया—अक्सर history और project vision में बदलाव भी
कई authors वाली किताबों की सीमा के कारण हर chapter समान रूप से अच्छा या दिलचस्प नहीं है, और सब कुछ पुराना भी हो चुका है, फिर भी यह पढ़ने लायक है
http://aosabook.org/
मैं जिस project पर काम कर रहा हूँ उसकी mental model को बेहतर समझने में ज़्यादा समय देना चाहता हूँ, लेकिन programming language, किसी खास architecture choice, या ऐसे हिस्से जो इतने जटिल हो गए हों कि उन पर समय लगाना ही बेकार लगे, उनसे चिढ़ शुरू होते ही मेरी प्रेरणा बहुत गिर जाती है
project पर निर्भर करता है, लेकिन “full-stack developer” की तरह काम करना programming का मज़ा खत्म कर देता है
मैं पहले ही हफ्ते में 40 घंटे शायद सबसे उबाऊ project को देखते हुए बिता रहा हूँ जिसकी कल्पना की जा सकती है
एक भी flawless project नहीं होता
और अगर programming language इतनी बड़ी समस्या है, तो ship बदल लेना बेहतर है
मेरा मानना है कि सबको कई भाषाएँ संभालनी आनी चाहिए, लेकिन आख़िरकार चुनाव आपका है
यह सुनिश्चित करना चाहिए कि जिस निर्णय पर आप सबसे ज़्यादा समय लगा रहे हैं वही वास्तव में सबसे महत्वपूर्ण निर्णय है
अच्छी तरह डिज़ाइन किए गए data structures का performance और maintainability पर framework, language, या platform की तुलना में कहीं ज़्यादा असर होता है
व्यक्तिगत रूप से, मैं हर दिन ADHD के साथ काम करता हूँ, इसलिए मुझे लगातार खुद को आगे बढ़ाना पड़ता है ताकि progress होती रहे; इसका मतलब है कम महत्वपूर्ण फैसलों को चुनकर निपटाना और बची हुई समस्या-भूमि पर ध्यान केंद्रित करना जहाँ सावधानी से सोचना ज़रूरी है
“clean code” या “beautiful code” जैसे शब्द juniors को software architecture best practices सीखने में खास मदद नहीं करते
अगर कोई junior पूछे कि ORM क्यों इस्तेमाल करते हैं और senior जवाब दे “क्योंकि यह ज़्यादा clean है”, तो हाथ सिर्फ सवाल ही आता है
इसकी जगह स्पष्ट goals की सूची define करना बेहतर है
maintainability, performance और scalability, efficiency, resilience, observability, testability और tested होना, security, और नए developers के लिए readability जैसे मानदंडों के बीच संतुलन बनता है
जितने अधिक मानदंड जोड़ोगे, हिचकिचाहट की स्थिति में बेहतर चुनाव करना उतना आसान होगा, और ये development team के बाहर के लोगों के लिए भी सार्थक होते हैं, ताकि ग्राहक के साथ इस बात पर सहमति बन सके कि वे किस चीज़ के लिए भुगतान कर रहे हैं
एक project अपने जीवन का अधिकांश हिस्सा maintenance mode में बिताता है, और यह सफलता का अच्छा संकेत है, इसलिए maintainability को परिभाषित भी किया जा सकता है
नई features को architecture तोड़े बिना, बल्कि आदर्श रूप से एक भी method signature तोड़े बिना जोड़ पाने की क्षमता एक अच्छा शुरुआती बिंदु है
abstraction के साथ बहुत सावधान रहना चाहिए
“abstraction अक्सर यह छिपा देती है कि आप जो चाहते हैं वह कितना सरल है” — यह बात सही है, और ORM इसका सटीक उदाहरण है
ज़्यादातर मामलों में data को first-class citizen की तरह treat करना चाहिए, और इससे DBA के साथ collaboration भी बेहतर होता है
premature optimization में फँसे बिना happy path के बाहर सोचना भी एक चुनौती है, और यह बिना trade-off देखे किसी अच्छे विचार के implementation में कूद पड़ने से रोकता है
अगर मैं यह कल्पना करूँ कि मेरे code को संभालने वाला व्यक्ति बहुत बुरा दिन झेल चुका है, तो इससे code को पढ़ने में सुखद बनाने में मदद मिलती है
जगह-जगह comments, local variables जिन्हें हटाया जा सकता था पर फिर भी छोड़ा गया है, और variable names जैसी चीज़ें इसमें आती हैं
frameworks को बहुत सोच-समझकर चुनना चाहिए; वे अच्छे servant लेकिन बुरे master होते हैं
“frameworker नहीं, engineer बनो” वाला वाक्य सही बैठता है
मुझे strong opinions से अपने-आप में दिक्कत नहीं है; libraries या tools में तो यह बेहतरीन गुण भी हो सकता है
ऐसे library या tool के पास अपने क्षेत्र का गहरा domain expertise होने की संभावना अधिक होती है
लेकिन framework में strong opinion आसानी से “हाथ में हथौड़ा है तो सब कुछ कील दिखता है” में बदल सकती है
ऐसा हमेशा हो, या हमेशा समस्या बने, ज़रूरी नहीं, लेकिन किसी एक domain की orthodox approach को व्यापक रूप से लागू करने पर यह जोखिम रहता है कि उसकी justification domain-specific थी और बड़े संदर्भ में टूट जाए
इसलिए framework में modularity पसंद है जहाँ आप दूसरा ORM या persistence integration layer लगा सकें, और router, validator, या समस्या के लिए अनुपयुक्त किसी अन्य component को बदल सकें
framework ecosystem के भीतर कई paradigms के alternatives हों तो वह खास तौर पर मूल्यवान होता है
क्योंकि तब आप लगभग सही ready-made tool ढूँढ सकते हैं, उसकी कमियाँ स्पष्ट देख सकते हैं, और ज़रूरत पड़ने पर उन्हें पूरा करने वाले विकल्प चुन सकते हैं
maintainability के लिए NIH syndrome से लड़ना बेहद महत्वपूर्ण है
यह एक लगातार मौजूद जोखिम है जो हैरान कर देने वाली गति से resources खींच लेता है
उसी समय, कुछ components ऐसे भी हो सकते हैं जिनमें direct tuning या full ownership से बड़ा लाभ मिलता है, और कठिन बात यह तय करना है कि कौन-सी चीज़ किस तरफ आती है
maintainability को सूची में सबसे ऊपर रखने वाली बात से मैं गहराई से सहमत हूँ
systems engineering के नज़रिए से software architecture plumbing design जैसी है
यह बहुत महत्वपूर्ण है, लेकिन लोग pipes के अंदर नहीं रहते, वे उस घर में रहते हैं जिसमें plumbing है
अगर plumbing घर के बाकी हिस्सों को ध्यान में रखे बिना की गई हो, तो उसे ठीक करने की लागत बहुत भारी हो सकती है
अच्छा लेख है
“software architecture सीखना” का मतलब यह समझना है कि इसका कोई एक सही उत्तर नहीं है
यह कला भी है और विज्ञान भी
पढ़ने के लिए Simplify IT - The art and science towards simpler IT solution की सिफारिश है
https://nocomplexity.com/documents/reports/SimplifyIT.pdf
Gary Bernhardt की talks वाकई खास हैं
उनमें ऐसे बहुत से विचार हैं जो आगे और रोचक दिशाओं तक ले जा सकते हैं