2010 में प्रकाशित "Just Enough Software Architecture"
(georgefairbanks.com)- George Fairbanks की Just Enough Software Architecture इस सोच से शुरू होती है कि केवल भाषा के syntax या UML की जानकारी से अच्छे object-oriented systems और architecture डिज़ाइन करना मुश्किल है
- इसका मूल विचार risk-driven architecting है: जोखिम कम हो तो ज़रूरत से ज़्यादा design से बचें, और जो जोखिम सफलता को खतरे में डालते हैं उन पर अधिक सख्त techniques लागू करें
- यह architecture को कुछ विशेषज्ञों की निजी domain नहीं, बल्कि हर developer के समझने योग्य क्षमता के रूप में देखती है, और बताती है कि constraints और छोटे changes system properties को कैसे प्रभावित करते हैं
- Development process या संगठन चलाने के बजाय engineering techniques पर ध्यान देती है, ताकि modeling और architecture analysis के जरिए मध्यम-बड़े problems के design trade-offs को संभाला जा सके
- इसकी संरचना दो हिस्सों में है: risk-driven software architecture और architecture modeling; यह domain model, design model, code model, encapsulation, components और connectors जैसी abstractions को कवर करती है
भाषा और UML ज्ञान भर से design क्षमता पूरी नहीं होती
- लेखक इस समस्या-बोध से शुरू करते हैं कि वे वह किताब बनाना चाहते थे जिसकी उन्हें software development शुरू करते समय जरूरत थी
- उस समय programming languages या object-oriented programming पर किताबें थीं, लेकिन design को कवर करने वाली किताबें कम थीं
- C++ language features जान लेने भर से अच्छा object-oriented system design नहीं किया जा सकता, और UML जान लेने भर से अच्छा system architecture design भी नहीं किया जा सकता
जोखिम के अनुसार adjust की जाने वाली architecting
- किताब का केंद्र risk-driven architecting है
- जोखिम कम हो तो बहुत बारीक design की जरूरत नहीं होती, और जब सफलता को खतरे में डालने वाला जोखिम हो तो ढीला-ढाला design पर्याप्त नहीं होता
- कई Agile समर्थक मानते हैं कि कुछ upfront design मददगार हो सकता है, और यह किताब “जितनी जरूरत हो उतनी architecture” करने का तरीका बताती है
- यह “one size fits all” वाली process से बचते हुए सामने मौजूद जोखिमों के अनुसार architecture और design effort को adjust करने की राह दिखाती है
- अधिकतर techniques को quick-and-dirty स्तर से लेकर बेहद rigorous स्तर तक scale किया जा सकता है
Architecture को सभी developers की भाषा बनाना
- किताब का लक्ष्य architecture को democratize करना है
- किसी संगठन में software architect हो सकता है, और पाठक खुद भी architect हो सकते हैं
- कई architects चाहते हैं कि हर developer architecture को समझे
- अगर developers constraints के कारण और छोटे changes का system properties पर असर नहीं समझते, तो design judgement डगमगा सकता है
- Architecture केवल architects का विषय नहीं, बल्कि सभी software developers से जुड़ा विषय है
Procedural knowledge और declarative knowledge
- किताब declarative knowledge विकसित करने पर केंद्रित है
- Tennis ball मार सकने की क्षमता और यह जानना कि आप उसे क्यों मार सकते हैं, अलग चीजें हैं; यही procedural knowledge और declarative knowledge का अंतर है
- अगर आप पहले से systems design और build करने वाले expert हैं, तो संभव है कि आप किताब की कई techniques इस्तेमाल करते रहे हों
- किताब आपको अब तक किए काम को बेहतर ढंग से पहचानने और concepts को नाम देने में मदद करती है
- ऐसा declarative knowledge junior developers को mentor करने की क्षमता बढ़ाने में मददगार होता है
Process के बजाय engineering पर फोकस
- Software systems design और build करने वाले लोगों को schedule, resource commitments, stakeholder needs जैसी कई समस्याओं को साथ-साथ संभालना पड़ता है
- Software architecture पर कई किताबें development process और organizational structure को पहले ही कवर करती हैं
- इसके उलट, यह किताब software development के technical हिस्से और system को काम कराने वाली engineering पर केंद्रित है
- यह models बनाने और architecture analyze करने के जरिए principled design trade-offs करने में सक्षम बनाती है
- यह मध्यम-बड़े problems पर reasoning के लिए इस्तेमाल होने वाली techniques समझाती है, और specialized techniques को अधिक विस्तार से सीखने की दिशा भी दिखाती है
कई abstraction levels के बीच चलने वाला practical design
- किताब architecture को practical design activity के रूप में देखती है
- Software architecture, software design का ही एक प्रकार है; design decisions architecture को प्रभावित करते हैं और architecture भी design को प्रभावित करती है
- बेहतरीन developers obstacles को detail में समझते हैं, फिर उन obstacles की प्रकृति को पूरी architecture से जोड़ते हैं
- इसी drill-down/pop-up व्यवहार को दर्शाते हुए, किताब architecture से लेकर data structure design तक कई abstraction levels के models को कवर करती है
संरचना और उपलब्ध formats
- किताब दो हिस्सों में बनी है
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- कुछ sample chapters को एक PDF के रूप में download किया जा सकता है
- e-book Google Play पर बिकती है; इसमें DRM-free ePub, Mobi, PDF तीनों formats शामिल हैं और कीमत $9.99 है
- Hardback Amazon पर उपलब्ध है
- Google Books और Amazon Search Inside full-text searchable versions देते हैं
क्या कवर है और क्या नहीं
- किताब software निर्माण से जुड़ी software architecture पर केंद्रित है
- यह बताती है कि software engineering requirements को पूरा करे, इसके लिए कौन-सी techniques इस्तेमाल हों
- चूंकि engineering techniques स्वयं आम तौर पर process-independent होती हैं, इसलिए किताब भी अधिकतर process से बंधी नहीं है
- यह निम्न तरह की management activity सलाह को कवर नहीं करती
- Architect की political responsibilities
- किसी खास तरह की meetings कब करनी चाहिए
- Stakeholders से requirements कैसे collect करें
Part I: Risk-Driven Software Architecture
- Software architecture को सटीक रूप से define करना कठिन है, लेकिन उसकी कुछ विशेषताएं स्पष्ट हैं
- Software developers, अन्य engineering fields के engineers की तरह, बड़े और complex problems हल करने के लिए abstractions और models का उपयोग करते हैं
- Software architecture system के skeleton की तरह काम करती है और quality attributes को प्रभावित करती है; यह functionality से orthogonal होती है और constraints के जरिए system properties पर असर डालती है
- Architecture खास तौर पर इन स्थितियों में महत्वपूर्ण होती है
- जब solution space छोटा हो
- जब failure risk अधिक हो
- जब कठिन quality attribute requirements सामने हों
- Design approach को architecture-indifferent design, architecture-focused design, architecture hoisting में से चुना जा सकता है
- Risk-based model की core procedure सरल है
- Risks identify करना और priority देना
- Techniques का set चुनकर लागू करना
- Risk reduction का assessment करना
- Chapter 4 Home Media Player system example से risk-based model का application दिखाता है
- Team communication
- COTS component integration
- Metadata consistency सुनिश्चित करना
- Part I models और software architecture इस्तेमाल करने की सलाह के साथ समाप्त होता है
- Problem solving में models का उपयोग करें
- Constraints सावधानी से जोड़ें
- Risk पर focus करें
- Architecture capability को पूरी team में distribute करें
Part II: Architecture Modeling
- Part II software architecture का conceptual model बनाने में मदद करने पर केंद्रित है
- Basic model structures तीन हैं
- Domain model: real world की चीजों से मेल खाता है
- Design model: बनाए जा रहे software का design दर्शाता है
- Code model: source code से मेल खाता है
- चुनी हुई details दिखाने वाले additional models, यानी views, बनाए जा सकते हैं, और ऐसी views को viewtype में group किया जा सकता है
- Encapsulation boundaries बनाना software architecture की महत्वपूर्ण skill है
- Component या module users internal behavior को ignore करके अन्य कठिन समस्याओं पर focus कर सकते हैं
- Encapsulated component या module के authors users को प्रभावित किए बिना implementation बदलने की freedom पाते हैं
- यह freedom तभी संभव है जब encapsulation effective हो, इसलिए किताब इसे सुनिश्चित करने वाली techniques को कवर करती है
- यह कई sources की software architecture techniques को integrate करती है
- Quality attributes पर जोर देने वाली techniques
- Functionality पर जोर देने वाली techniques
- Effective models बनाने के practical तरीके
- Models debug करने के तरीके
- Part II models को प्रभावी ढंग से इस्तेमाल करने की सलाह के साथ-साथ इस skill में सामने आ सकने वाले pitfalls भी कवर करता है
- अंतिम लक्ष्य abstractions और relationships का समृद्ध conceptual model रखना, और software system को वैसे देख पाना है जैसे coach मैच को देखता है
1 टिप्पणियां
Hacker News की राय
कहा जाता है कि अगर project management risk “मुख्य developer का बस से टकरा जाना” है और software engineering risk “server शायद 1000 users तक scale न कर पाए” है, तो दोनों में फर्क करना चाहिए, लेकिन मेरे अनुभव में ये इतने अलग-अलग नहीं होते
code quality और structure, tests और documentation, standard और well-known tools का इस्तेमाल—ये दोनों तरफ मदद करते हैं
इसलिए मैंने सहकर्मियों या managers के सामने कई बार “अगर बस से टकरा गए तो?” वाली कल्पना रखी, और यह reproducible और समझ में आने वाला software बनाने के लिए pressure mechanism बन गया
चोट या मौत की negative nuance से बचना हो तो “अगर lottery लग गई तो?” कहना बेहतर है
“बस से टकरा जाना” का असली point यह है कि personality से अलग, तैयारी के लिए बिल्कुल भी समय नहीं होता, और इसलिए जानकारी आज ही share करने का pressure बनता है
अफसोस, उसी implication वाला कोई positive expression अभी तक नहीं मिला
दोनों करीब एक हफ्ते बाद वापस आ गए, इसलिए किसी और standard disaster example की जरूरत पड़ गई
बात समझाने के लिए मैं “next person” expression ज्यादा इस्तेमाल करता हूं
उससे भी खराब स्थिति burnout है, जहां headcount तो वही रहता है लेकिन मानसिक रूप से व्यक्ति पहले ही जा चुका होता है
बहुत-सी कंपनियां देखी हैं जो permanent exit नहीं, इतना भी नहीं झेल पातीं
या “bus factor बढ़ाना” जैसे expression से single point of failure हटाने की motivation पर focus किया जा सकता है
root cause analysis करते समय “Larry बस से टकरा गया / lottery जीत गया” पर रुकना नहीं चाहिए, क्योंकि असली समस्या वह नहीं है
architecture के लिए architecture सबसे खराब है, क्योंकि यह बेवजह complexity बढ़ाता है
अच्छी architecture का ultimate goal cost कम करना है
अगर architecture की वजह से code develop और maintain करने में ज्यादा समय लगता है, तो वह architecture fail है
यह हमेशा balance बनाने का मामला है
इसलिए कोई एक सही architecture नहीं है; choice context पर निर्भर करती है और कभी-कभी उसका फिर से evaluation करना पड़ता है
flexibility खास तौर पर useful है, क्योंकि बदलती परिस्थितियों में भी यह architecture को कुछ हद तक adjust करके efficiency बनाए रखने देती है
cost reduction उनमें से एक हो सकता है
“risk-driven model developers को सबसे urgent risks घटाने के लिए architecture techniques की minimum मात्रा apply करने की ओर ले जाता है। यह लगातार पूछने की प्रक्रिया है: ‘मेरे risks क्या हैं? इन्हें घटाने की best technique क्या है? क्या risk कम हो गया है और अब coding शुरू या resume की जा सकती है?’ risk-driven model को तीन steps में summarize किया जा सकता है: 1. risks identify करें और prioritize करें 2. techniques का set चुनकर apply करें 3. risk reduction evaluate करें”
हम low-impact techniques पर समय बर्बाद नहीं करना चाहते, और न ही project को threat करने वाले risks को ignore करना चाहते हैं
successful system बनाने के लिए समय का सबसे effective इस्तेमाल करने वाला रास्ता चुनना चाहिए, जिसका मतलब है कि risk से motivated होने पर ही architecture और design techniques apply करके risks handle किए जाएं
उदाहरण के लिए “architecture” में client-server style इस्तेमाल करना भी शामिल है, जहां server पहले action नहीं करता और सिर्फ client requests का जवाब देता है
यह तरीका problem के लिए fit हो भी सकता है और नहीं भी
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
खूब पैसा पाने वाले technical architects खास कुछ नहीं करते, लेकिन deadlines जैसी unreasonable constraints के बीच software engineers पर ऐसे भयानक patterns थोपते हैं जिन्हें उन्हें solve करना पड़ता है
अच्छी architecture ज्यादा लोगों को product में contribute करने देती है
अगर यह 2010 में प्रकाशित हुई थी, तो जानने की उत्सुकता है कि उसके बाद से यह कितनी टिक पाई है
“Design It” मुझे इसलिए पसंद है क्योंकि इसमें उन तकनीकी लोगों के लिए अच्छे workshops और activities हैं जिन्हें stakeholders या customers के साथ interact करना पड़ता है
Consulting role होने की वजह से यह और भी relevant है, और यह भी अच्छा है कि यह अक्सर बदलने वाले किसी खास technical architecture style पर बहुत ज्यादा निर्भर नहीं करती
मैं फैशन नहीं, असली principles के आधार पर कह रहा हूँ
लेखक mindset पर essays में काफी समय लगाते हैं और specific techniques को हल्के में लेते हैं, लेकिन आगे पढ़ने के लिए material देते हैं
यह टीम को concrete activities के जरिए architecture ideas पर काम करवाती है, और अंत में सामने ला देती है कि असल में क्या महत्वपूर्ण है
मेरी किताब ने ऐसे बड़े ideas को सीधे tackle करने की कोशिश की, लेकिन विषय इतना abstract है कि educational रूप से यह मुश्किल निकला
2010 के बाद कौन-से ideas बचे रहे? कुछ operating systems microkernel होते हैं, और कुछ operating systems monolithic होते हैं
कुछ databases relational होते हैं, और कुछ document-oriented होते हैं
कुछ applications client-server होती हैं, और कुछ peer-to-peer होती हैं
ये distinctions शायद स्थायी हैं, और 100 साल बाद लौटने पर Windows, Oracle, Salesforce जैसे examples भले गायब हो जाएँ, फिर भी ऐसे design वाले systems दिखेंगे
और हम modifiability या latency जैसी qualities के बारे में भी अब भी बात करेंगे
Software architecture का क्षेत्र ऐसी स्थायी abstractions की पहचान करने का काम है
[2] में इसका concise explanation है
“Abstract: Software architecture उन abstractions का set है जो हमें उस software के बारे में reason करने में मदद करता है जिसे हम बनाने की योजना बना रहे हैं या पहले ही बना चुके हैं। हमारे field में बहुत पहले से छोटी abstractions मौजूद थीं, लेकिन quality attributes, information hiding, components और connectors, multiple viewpoints, architectural styles जैसी बड़ी abstractions को जमा होने में दशकों लगे। Systems design करते समय हम इन abstractions को पिरोकर intentionality की chain को बचाए रखते हैं, और design किए गए system से वही काम करवाते हैं जो हम चाहते हैं। 20 साल पहले इसी magazine में Martin Fowler ने प्रभावशाली लेख ‘Who Needs an Architect?’ प्रकाशित किया था। अब समय है कि developers software architecture को फिर से देखें, और उसे abstractions के ऐसे set के रूप में देखें जो software के बारे में reason करने देता है”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
John Ousterhout की A Philosophy of Software Design उपयोगी लगी
इसमें समझने में आसान, मजबूत advice बहुत है और examples भी बहुत हैं
इस किताब के बारे में तो नहीं जानता, लेकिन लेखक का Intellectual Control से जुड़ा लेख जानता हूँ और वह बहुत insightful है
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
पिछली कंपनी में Simon Brown की Software Architecture for Developers किताब circulate हुई थी: https://leanpub.com/b/software-architecture
वह अभी भी मेरी reading list में ही है और मैं उस कंपनी से आगे बढ़ चुका हूँ, लेकिन उसकी strong recommendation मिली थी
उस कंपनी ने C4 model से architecture भी document किया था
जानना चाहता हूँ कि यहाँ किसी ने इसे पढ़ा है या नहीं
उनके architecture talks [1] और workshops खास तौर पर effective हैं, और C4 architecture modeling language [2] भी सचमुच momentum पकड़ रही है
मेरे YouTube videos भी हैं [3], लेकिन वे उतने effective नहीं हैं
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
इस methodology के लिए “risk-dependent” नाम कहीं बेहतर होता
Programmers को “[X]-driven” expression इतना पसंद क्यों आता है?
जैसे यह shaft उस gear को drive करता है, और वह gear wheel को drive करता है
यह “इस जटिल thought machine में सबसे powerful mechanism क्या है” को छोटा करके कहने वाला expression है
कुछ साल पहले कंपनी में हमने इस किताब पर reading group किया था, और यह बहुत दोहरावदार लगी
सोच रहा हूँ कि किसी non-trivial open-source project को शुरू करने वाले के लिए यह किताब अच्छा resource है या नहीं
या किसी solo founder को इससे value मिलेगी या नहीं; solo developer के लिए उपयोगी किताबों या दूसरे resources की recommendations चाहिए
सॉफ़्टवेयर architecture सामान्य building architecture जैसा है, लेकिन सॉफ़्टवेयर में अभी तक Isaac Newton जैसा कोई व्यक्ति नहीं हुआ है, इसलिए लगता है कि civil engineering जैसी कोई चीज़ मौजूद ही नहीं है
अब तक इसके सबसे क़रीब व्यक्ति मुझे Claude Shannon लगते हैं
क्योंकि हमारे पास measurement units तक नहीं हैं
हम अभी भी software engineering में “बस उम्मीद है कि यह ढहेगा नहीं” वाले चरण में हैं
इसका self-reported productivity पर गहरा असर पड़ता है
उदाहरण के लिए, खिड़कियाँ ऊपर रखकर 30 मील प्रति घंटा की रफ़्तार से stop signs वाली छोटी suburban सड़क पर कार चलाने की तुलना में साइकिल ज़्यादा तेज़ लग सकती है
लेकिन आम तौर पर ड्राइवर 20 blocks दूर कहीं बहुत जल्दी पहुँच जाता है
अगर measurement units न हों, तो हर कोई इस पर बहस कर रहा होगा कि साइकिल ज़्यादा तेज़ है
software engineering अभी इसी स्थिति में है
सॉफ़्टवेयर बनाना पुल या high-rise building बनाने जैसा बिल्कुल नहीं है; यह बल्कि उन्हें design करने के ज़्यादा क़रीब है
बड़े construction projects में पहले design किया जाता है और फिर बनाया जाता है, और यह design अपने आप में बहुत बड़ा काम होता है
हर चीज़ के बारे में सोचना, simulations चलाना, stakeholders से चर्चा करना, requirements और constraints समझना, material cost और weight वगैरह पर विचार करना पड़ता है
बड़े construction projects में सिर्फ़ वास्तविक design बनाने में ही महीनों या वर्षों का समय निकल सकता है, और नतीजा एक बेहद detailed blueprint होता है जो construction के लगभग हर पहलू को कवर करता है
सच कहें तो यह सॉफ़्टवेयर बनाने से काफ़ी मिलता-जुलता है
ऐसे design projects में uncertainty और risk बहुत ज़्यादा होते हैं
फिर भी, बहुत सारे लोगों, concrete और steel जैसे महँगे resources का इस्तेमाल शुरू करने से पहले यह पता चल जाना बेहतर है कि सब कुछ ग़लत है
लेकिन क्या आपने कभी किसी architect को यह कहते सुना है कि वह इसे कम करने के लिए design के लिए design बनाएगा? ऐसा कुछ नहीं होता
ज़्यादा से ज़्यादा किसी समय कोई sketch या napkin drawing रही होगी
SpaceX ने engineering में agile के कुछ elements अपनाए, जो उसने software development से सीखे थे
सॉफ़्टवेयर में पूरा हुआ blueprint executable होता है
blueprint बनाने की प्रक्रिया manual होती है, लेकिन उस blueprint से software बनाने की प्रक्रिया आम तौर पर compiler और दूसरे tools से automated और बहुत सस्ती होती है, इसलिए developers इसे लगातार करते रहते हैं
बेशक पहले हमेशा ऐसा नहीं था
executable blueprint बनाने की प्रक्रिया में स्वाभाविक रूप से बहुत risk होता है, और जगह-जगह napkin या whiteboard designs हो सकते हैं
लेकिन पहले पूरा design और फिर पूरी implementation करने की धारणा, यानी waterfall method, सॉफ़्टवेयर में भी कभी ठीक से काम नहीं कर पाई
कुछ exceptions छोड़ दें तो आम तौर पर blueprint के लिए blueprint नहीं होता
Royce का waterfall वाला original paper पढ़ें तो असल में उसमें waterfall शब्द बिल्कुल नहीं आता, और वह धुंधले तौर पर सुझाव देता है कि iteration एक अच्छा विचार हो सकता है
कम-से-कम एक बार से ज़्यादा करके देखें, इस तरह
वह पूरी तरह समझता था कि पहला design ग़लत होने की संभावना बहुत अधिक है
Agile ने blueprint के लिए design बनाने वाले उस low-value step को optimize करके हटा दिया, जो बहुत सारे iterations करने पर साफ़ दिखने लगता है
बस कुछ specific domains के बाहर हम उन्हें आम तौर पर नज़रअंदाज़ करते हैं
उदाहरण के लिए, इस summary और table of contents को मोटे तौर पर देखें तो performance metrics का उल्लेख बहुत कम या शायद बिल्कुल नहीं दिखता
अगर computer असल में क्या करता है, इस पर विचार ही नहीं किया जाए, तो architecture का क्या उपयोग है?
development productivity या user interface के लिहाज़ से भी, software को develop, बदलने, extend करने और उससे भी ज़रूरी, use करने के लिए ज़रूरी mental stack को explain करने वाला mathematical model क्यों नहीं है?
इंसान हों या मशीनें, computational resources का software के साथ developer या user के तौर पर interact करने पर वास्तविक और measurable असर होता है, फिर भी उन पर शायद ही कभी विचार क्यों किया जाता है?
उदाहरण के लिए, Westminster Palace में निश्चित रूप से civil engineering elements हैं, लेकिन इसकी ornate textures, symbolic clock tower और internal layout जैसी decisive features ज़्यादातर functional और aesthetic choices से तय होती हैं
सॉफ़्टवेयर के बड़े हिस्से के साथ भी ऐसा ही है