ADR क्यों लिखने चाहिए

 (github.blog)
30 पॉइंट द्वारा xguru 2020-08-17 | 3 टिप्पणियां | WhatsApp पर शेयर करें

ADR = Architecture Decision Records

आर्किटेक्चर से जुड़े फैसले इस तरह कोडबेस के भीतर दर्ज करना कि वे क्यों लिए गए थे।
GitHub अपनी iOS/Android मोबाइल टीमों में इसका उपयोग कर रहा है, और यह लेख बताता है कि इसकी ज़रूरत क्यों है।

यह आपके लिए नहीं, बल्कि भविष्य के आपके लिए है

ADR मेरे द्वारा लिए गए फैसले पर आत्मचिंतन की प्रक्रिया नहीं है, बल्कि यह 6~12 महीने बाद उस समय की mindset को याद रखने में मदद करता है जब यह आर्किटेक्चर तय किया गया था।
ADR उस क्षण को कैप्चर करता है जब निर्णय लिया जाता है, और इसमें meetings/Zoom meetings/Slack/code में हुए PoC तक सब शामिल हो सकते हैं।
दिमाग में मौजूद इस context को शब्दों में बाहर निकालकर दर्ज करना, ताकि बाद में जब इस आर्किटेक्चर को फिर से देखा जाए तो वही context दोबारा दिमाग में डाला जा सके।

असल बोनस तब दिखता है जब कुछ महीनों बाद कोई आपसे नाराज़गी के साथ पूछे कि GitHubAPIClient module इस तरह क्यों काम करता है।
30 मिनट pair programming करके कोड समझाने की बजाय, आप यह ADR दे सकते हैं और उस module को बनाते समय लिए गए फैसलों को समझा सकते हैं।

यह आपके लिए नहीं, बल्कि आपके साथियों के लिए है

ADR में एक पंक्ति की "यह feature feature-#3128 का implementation है" जैसी बात से अधिक विस्तार होना चाहिए।
यह एक थोड़ा लंबा explanation format है, जो साथियों को यह समझने में मदद करता है कि यह feature किसी और तरीके से नहीं बल्कि इसी तरीके से क्यों बनाया गया।
(ADR में इसे "विचारित विकल्प", "फायदे और नुकसान" आदि के रूप में लिखा जा सकता है।)

जो बात आपको सरल लगती है, वह आपके साथियों को जटिल लग सकती है।
थोड़ा समय निकालकर, निर्णय लेते समय आपके सोचने की प्रक्रिया को लिख देने से टीम के लोगों को आपके दिमाग के अंदर आने का मौका मिलता है।
ADR लिखने से "Decision Socialization" संभव हो जाता है।
इससे अलग-अलग लोग अपने-अपने फैसले लेने के बजाय, टीम ऐसे फैसले लेती है जिनकी maintenance की ज़िम्मेदारी भी वही उठाती है।

Pull Request उठाने से पहले ADR लिखने पर, इसकी समीक्षा करने वाली टीम से बेहतर PR review मिल सकता है।

यह आपके लिए नहीं, बल्कि भविष्य के साथियों के लिए है

ADR का उद्देश्य यह दिखाना नहीं है कि आप कितने स्मार्ट हैं, या लोगों को आपके बनाए आर्किटेक्चर को देखकर उलझन में डालना नहीं है।
ADR नए team members को यह समझने में मदद करता है कि मौजूदा codebase क्या है और समय के साथ यह कैसे विकसित हुआ है।

जैसे-जैसे टीम फैलती और बढ़ती है, team members के बीच communication के रास्ते बढ़ते जाते हैं।
ऐसे फैसलों को लिखकर रखना, टीम के बढ़ने पर बाद में जुड़ने वाले लोगों के साथ communication में भी मदद करता है।

सबसे अच्छा scenario यह है कि आपका कोई teammate नया ADR लिखे, जो आपके पुराने फैसले की जगह ले ले, और भविष्य में आप अपने साथियों से सीख सकें।

"और अधिक ADR लिखिए। जैसे-जैसे हमारी टीम बढ़ती है और codebase जटिल होता जाता है, ADR भविष्य के हमारे, वर्तमान टीम के लोगों और भविष्य में जुड़ने वाले साथियों की मदद करने का एक शानदार तरीका है।"

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

3 टिप्पणियां

 
xguru 2020-08-25

ई-गवर्नमेंट के मामलों में प्रसिद्ध Gov.UK के पास अपनी AWS cloud architecture से संबंधित ADR को व्यवस्थित करने वाला एक repository भी है.

https://github.com/alphagov/govuk-aws/…
 
beatblue 2020-08-20

यह एक अच्छा संदर्भ साबित हुआ।
 
xguru 2020-08-17

ADR के उदाहरण

CSS framework का निर्णय

https://github.com/joelparkerhenderson/architecture_decision_record/…

  • मुद्दा : वेबऐप के लिए CSS framework चुनना ज़रूरी है। यह प्रमुख browsers और अलग-अलग screen sizes से परे तेज़ और स्थिर होना चाहिए। design/layout/UI/UX में तेज़ iteration हो। responsive design भी हो
  • निर्णय : Bulma इस्तेमाल करने का निर्णय लिया गया

  • आधारधारणा : हम modern, तेज़ और responsive web app बनाना चाहते हैं, इसलिए jQuery इस्तेमाल नहीं करना चाहते

  • बाधा : ऐसा framework होना चाहिए जिसे jQuery के बिना इस्तेमाल किया जा सके

  • विचार किए गए विकल्प : कुछ भी न इस्तेमाल करना, या Bootstrap/Bulma/Foundation/Materialize/Semantic UI में से चुनना; Bulma और Semantic UI पर गहराई से विचार किया गया

Monorepo vs Multirepo

https://github.com/joelparkerhenderson/architecture_decision_record/…

  • मुद्दा : हमारे प्रोजेक्ट की तीन मुख्य categories हैं - frontend UI, middleware, backend server

→ SCM के रूप में git इस्तेमाल हो रहा है, इसलिए monorepo vs polyrepo vs hybrid का निर्णय लेना है

  • निर्णय :

→ जब संगठन/टीम/प्रोजेक्ट छोटा हो और तेज़ iteration चाहिए, तब Monorepo

→ जब संगठन/टीम/प्रोजेक्ट बड़ा हो और स्थिरता अधिक महत्वपूर्ण हो, तब Polyrepo

  • आधारधारणा : हम जो code बना रहे हैं वह संगठन के लिए है, बाहरी (public) उपयोग के लिए नहीं

Programming language का निर्णय

https://github.com/joelparkerhenderson/architecture_decision_record/…

  • मुद्दा : software development के लिए language तय करनी है। web frontend और backend के लिए
  • निर्णय :

→ frontend के लिए TypeScript

→ backend के लिए Rust

  • आधारधारणा :

→ frontend सामान्य हो, लेकिन development, deployment और iteration तेज़ होने चाहिए। legacy compatibility की ज़रूरत नहीं है

→ backend सामान्य अपेक्षा से थोड़ा ऊपर का होना चाहिए। quality, stability और security पर ध्यान होना चाहिए। लगभग real-time स्तर की आवश्यकता है (GC की वजह से रुकावट नहीं होनी चाहिए)। functional programming / parallel processing और multicore processing, memory safety भी महत्वपूर्ण हैं

  • सीमा : major cloud services की serverless सेवाओं (Amazon Lamba) पर यह ज़रूर चल सकना चाहिए

  • विचार किए गए विकल्प : C/C++/Clojure/Elixir/Erlang/Elm/Flow/Go/Haskell/Java/Javascript/Kotlin/Python/Ruby/Rust/TypeScript

  • बहस :

→ C : कम safety के कारण बाहर; Rust ज़्यादातर चीज़ें इससे बेहतर कर सकता है

→ C++ : बहुत messy होने के कारण बाहर; Rust ज़्यादातर चीज़ें इससे बेहतर कर सकता है

→ Clojure : बेहतरीन modeling; Lisp से सबसे अधिक मिलता-जुलता; JVM पर शानदार runtime

→ Elixir : deployment और concurrency के लिए बेहतरीन runtime; शानदार developer experience; अपेक्षाकृत छोटा ecosystem

→ Erlang : deployment और concurrency के लिए बेहतरीन runtime; कुछ चुनौतीपूर्ण developer experience; अपेक्षाकृत छोटा ecosystem

→ Elm : काफ़ी संभावनाशील; IBM अच्छे use cases साझा कर रहा है; छोटा ecosystem

→ Flow : JS का दिलचस्प सुधार; लेकिन developers इससे दूर जा रहे हैं

→ Go : शानदार developer experience; शानदार concurrency; कुछ खराब फैसले लिए गए जिनसे language अजीब लगती है

→ Haskell : सर्वश्रेष्ठ functional language; छोटा developer community; production में सफलता के ज़्यादा उदाहरण नहीं

→ Java : बेहतरीन runtime; शानदार ecosystem; बस ठीक-ठाक developer experience

→ JavaScript : सबसे लोकप्रिय language; सबसे व्यापक ecosystem

→ Kotlin : Java की कई चीज़ों में सुधार; JetBrains का शानदार support; Java to Kotlin के कई सफल उदाहरण

→ Python : system administration में सबसे लोकप्रिय language; अच्छे analysis tools; अच्छे web frameworks; Google के Go चुनने के बाद पीछे छूट गया

→ Ruby : सर्वश्रेष्ठ developer experience; सर्वश्रेष्ठ web framework; शानदार community; बहुत धीमा; packaging करना मुश्किल

→ Rust : सर्वश्रेष्ठ नई language; Zero-cost abstractions(अमूर्तीकरण करने पर भी speed कम नहीं होती) पर ज़ोर; concurrency पर ज़ोर; अपेक्षाकृत छोटा ecosystem; कुछ compiler optimizations में सीमाएँ हैं (जैसे memory direct access के लिए unsafe होना ज़रूरी है)

→ TypeScript: JavaScript में Type जोड़ता है; शानदार Transpiler; developers धीरे-धीरे JS से TS की ओर जा रहे हैं; Microsoft का मज़बूत support

  • VM-आधारित विकल्प नहीं चुनने का निर्णय लिया गया (क्योंकि इससे complexity बढ़ती है)

  • सबसे तेज़ runtime के लिए JS और C चुने जाते हैं

  • लगभग सर्वोत्तम speed वाले runtime के लिए TypeScript और Rust चुने जाते हैं

  • अगर VM और web framework चुना गया होता तो

→ Closer और Luminous

→ Java और Spring

→ Elixir और Phoenix