भाग 1: रचना (navy, 1–4) · भाग 2: सीमा आणि styles (ochre, 5–8) · भाग 3: ते निरोगी ठेवणे (teal, 9–12). प्रत्येक आकृती खऱ्या, deterministic lab मधून काढली आहे — arch/demo.py जे आकडे print करते तेच — आणि प्रत्येकीखाली एक lab आहे जिथे तुम्ही स्वतः मार्गिका हलवता. वर्तुळातील आकडे 1 → 2 → 3 या क्रमाने पाहा.
1 🏛️ Architecture म्हणजे काय
जिना, रंग नव्हे — बदलायला महाग असलेले निर्णय, त्यांनी मिळणाऱ्या -ilities, आणि त्यांची किंमत.
🧒 सोप्या शब्दांत
कतरिना नव्या शाळेच्या इमारतीचा आराखडा बनवते. रंग नंतर सहज बदलता येतो. जिना नाही. तो हलवायचा म्हणजे अर्धी शाळा बंद. Sample app मध्ये ports नावाची एक room इतर 12 पैकी 8 rooms ना आधार देते. असा निर्णय म्हणजे architecture. कतरिना सर्वात महत्त्वाचे थोडे गुण निवडते, आणि त्यांची किंमत स्वीकारते.
📖 नवे शब्दarchitecture — नंतर बदलायला महाग असलेले निर्णय, जसे जिना कुठे असावाmodule — code ची एक file; या शाळेत ती एक room आहेblast radius — एखादा बदल ज्या सगळ्या rooms पर्यंत पोहोचू शकतो, जसे ports साठी 12 पैकी 8-ility — इमारतीत हवा असलेला गुण, जसे testability, आणि त्याला नेहमी किंमत असते
⏪ आधी
टीम प्रत्येक निर्णय सारखाच मानत असे: variable चे नाव आणि सगळ्यांचा port सारख्याच काळजीने, किंवा बेफिकिरीने बदलले जात.
💡 काय
Architecture म्हणजे जिना, रंग नव्हे: जे निर्णय नंतर बदलणे महाग असते, जसे sample मधील domain.ports.
⚙️ कसे
Analyzer 13 rooms आणि 24 corridors वाचतो: domain.ports मधला बदल 12 पैकी 8 rooms पर्यंत पोहोचतो, timetable चा 0.
🎯 का
कतरिना 3 driving characteristics निवडते, प्रत्येकासोबत scenario आणि किंमत, कारण प्रत्येक गुण दुसऱ्या कशाची तरी किंमत घेतो.
🚀 पुढे
पुढचा धडा rooms मोजतो: प्रत्येक मजल्याला किती corridors आहेत, आणि त्याचा बदलावर काय परिणाम होतो.
🧪 इथे करून पाहा — एक खोली निवडा — तिच्यातील बदल कोणत्या खोल्यांपर्यंत पसरू शकतो?
कमी मार्गिका असलेल्या खोल्या, मोजून — cohesion, coupling, Ca, Ce, instability, abstractness आणि distance.
🧒 सोप्या शब्दांत
चांगल्या room चे एकच काम असते. Test tubes विज्ञान प्रयोगशाळेत असतात, library मध्ये नाही. चांगल्या room ला कमी दारे असतात. दीपिका प्रत्येक मजल्याची दारे मोजते. Rule book च्या मजल्याला आत येणारी 5 दारे आणि बाहेर जाणारी 2 आहेत. अनेक जण त्यावर अवलंबून आहेत, म्हणून तो हळूहळू बदलायला हवा. त्याची instability 0.29 आहे.
📖 नवे शब्दcohesion — एकत्र वापरल्या जाणाऱ्या गोष्टी एकाच room मध्ये राहतातcoupling — एका room ला इतर rooms कडे किती corridors लागतात; कमी असतील तर बदल सोपाinstability — बाहेर जाणारी दारे भागिले सगळी दारे, जसे 7 पैकी 2 = 0.29abstract — कोण करणार हे न सांगता काय हवे आहे याचा आराखडा, जसे port
⏪ आधी
Code अंदाजाने तपासला जाई: 'हे module गोंधळलेले दिसते'. एखादा भाग किती coupled आहे, आणि ते वाईट आहे का, कोणी सांगू शकत नसे.
💡 काय
Cohesion आणि coupling आकड्यांत: Ca आत येणारी दारे, Ce बाहेर जाणारी, instability I = Ce/(Ca+Ce), आणि distance D = |A+I-1|.
⚙️ कसे
दीपिका प्रत्येक मजला मोजते: domain चे Ca=5, Ce=2, म्हणून I=0.29; main चे I=1.00; web चे D=0.67 आणि app चे H=0.33.
🎯 का
ज्यांच्यावर अनेक जण अवलंबून आहेत ते स्थिर भाग abstract असावेत; web स्थिर पण पूर्ण concrete आहे, म्हणून बदलायला अवघड.
🚀 पुढे
पुढचा धडा rooms मजल्यांवर रचतो आणि विचारतो जिना कोणत्या दिशेने जावा: फक्त खाली, कधीच वर नाही.
🧪 इथे करून पाहा — एखादी मार्गिका जोडा किंवा काढा — Ca, Ce, I, A आणि D कसे बदलतात ते पाहा
मजले, आणि जिने कोणत्या दिशेने जातात — layer नियम, strict विरुद्ध relaxed, आणि उल्लंघने शोधणे.
🧒 सोप्या शब्दांत
शाळेला चार मजले आहेत. वर reception, मग office, मग rule book, आणि खाली store room. नियम सोपा: जिन्याने खाली जा, कधीच वर नाही. कतरिना प्रत्येक corridor तपासते. तिला वर जाणारे 4 सापडतात. पण त्यातले 3 म्हणजे store room चे कर्मचारी rule book वाचत आहेत, जे खरे तर चूक नाही.
📖 नवे शब्दlayer — इमारतीचा एक मजला, जसे web, app, domain किंवा infraviolation — नियम मोडणारा corridor, जसे जिन्याने वर जाणाराstrict layering — फक्त लगेच खालच्या मजल्यावर जाता येते, ज्यात 5 violations सापडले
⏪ आधी
Screens, rules आणि SQL एकाच files मध्ये होते, म्हणून database बदलला की business rules लाही हात लावावा लागे.
💡 काय
Layers म्हणजे मजले: web, app, domain, infra. एखादी room स्वतःच्या किंवा खालच्या मजल्याला import करू शकते, वरच्याला कधीच नाही.
⚙️ कसे
Check ला relaxed mode मध्ये 4 वर जाणारे corridors सापडतात, आणि strict मध्ये 5, कारण enrol थेट infra.email ला जातो.
🎯 का
मजल्यांचा नियम जिना एकाच दिशेने ठेवतो; पण 4 पैकी 3 violations हे adapters आहेत, जे स्वतः implement करत असलेले ports import करतात.
🚀 पुढे
पुढचा धडा चित्र उलटवतो: rule book मध्यभागी जाते आणि प्रत्येक दार बाहेरच्या दिशेने उघडते.
🧪 इथे करून पाहा — मजल्यांचा क्रम आणि नियम निवडा — तो मोडणाऱ्या मार्गिका मोजा
मध्यभागी नियमपुस्तिका, बाहेर उघडणारी दारे — domain कोणतेही infrastructure import करत नाही.
🧒 सोप्या शब्दांत
आता rule book मधल्या staff room मध्ये आहे. प्रत्येक दारावर पाटी आहे: 'मला marks आणणारे कोणीतरी हवे.' आज store room चा कर्मचारी येतो. Test मध्ये दीपिका कागद घेऊन येते. दोघेही त्या दाराला बसतात. तीन दारे चुकीने बाहेर उघडत होती. ती दुरुस्त केल्यावर grades च्या test ला फक्त 1 दुसरी room लागते.
📖 नवे शब्दport — core च्या दारावरची पाटी, काय हवे ते सांगते, कोण देणार ते नाहीadapter — बाहेरचा मदतनीस जो दाराला बसतो, जसे SQL store किंवा email पाठवणाराdependency rule — प्रत्येक corridor आतल्या दिशेने, rule book कडे जातोfake — tests मध्ये वापरला जाणारा खोटा मदतनीस, जसे database ऐवजी कागद
⏪ आधी
Domain database वर बसलेले होते, म्हणून marks चा नियम test करायला SQLite सुरू करून store room load करावी लागे.
💡 काय
Ports and adapters: core ports ठरवतो (GradeStore, Mailer, Ledger) आणि बाहेरचे adapters त्यांना जोडले जातात.
⚙️ कसे
Ring check ला 3 बाहेर जाणारे corridors सापडतात; ते काढल्यावर domain.grades च्या test ला load कराव्या लागणाऱ्या rooms 3 वरून 1 होतात.
🎯 का
आतल्या दिशेने जाणाऱ्या dependencies मुळे मौल्यवान नियम SQL आणि SMTP पासून मुक्त राहतात, आणि fakes सोबत काही ms मध्ये test होतात.
🚀 पुढे
पुढचा धडा core ला विभागांमध्ये वाटतो, प्रत्येकाचा 'student' या शब्दाचा स्वतःचा अर्थ असतो.
🧪 इथे करून पाहा — बाहेर जाणाऱ्या 3 मार्गिका ठेवा किंवा काढा — domain.grades च्या test ला काय load करावे लागते?
स्वतःचे शब्द असलेले विभाग — bounded contexts, ubiquitous language आणि code मधून वाचलेला context map.
🧒 सोप्या शब्दांत
तीन offices ना विचारा student म्हणजे काय. Admissions म्हणते form number आणि नाव. Exam cell म्हणते marks सह roll number. Accounts म्हणते fees देणे असलेले खाते. तिघीही आपल्या office मध्ये बरोबर आहेत. पण grades आणि fees admissions ची कल्पना उसनी घेतात. Admissions ने नावाचा रकाना बदलला, तर 2 offices बिघडतात.
📖 नवे शब्दbounded context — असा विभाग जिथे एक model आणि एकच शब्दसंच सुसंगत राहतातubiquitous language — विभाग बोलण्यात आणि code मध्ये सारखेच वापरतो ते शब्दcontext map — कोणता विभाग कोणावर अवलंबून आहे याचा नकाशा, जसे grades → admissionsanti-corruption layer — दारावरचा अनुवादक जो दुसऱ्या office चे शब्द आपल्या शब्दांत बदलतो
⏪ आधी
एकच मोठा Student class प्रत्येक office वापरत असे, म्हणून admissions साठी नवे field आले की report cards गुपचूप बिघडू शकत.
💡 काय
Bounded contexts म्हणजे विभाग: admissions, grades, fees, timetable, प्रत्येकाचे एक model आणि स्वतःचे शब्द.
⚙️ कसे
Code मधून वाचलेला context map 2 विभाग-ओलांडणारे corridors दाखवतो: grades आणि fees दोघेही admissions चा Student import करतात.
🎯 का
Admissions ने Student.name बदलले तर काहीही न बदलता 2 विभाग बिघडतात; ACL तो बदल दारातच थांबवतो.
🚀 पुढे
पुढचा धडा विचारतो विभाग कुठे ठेवायचे: एक मोठा हॉल, भिंती असलेली एक इमारत, की campus.
🧪 इथे करून पाहा — विभाग Student उसना घेतात — anti-corruption layer जोडा, मग Student.name चे नाव बदला
एक इमारत, भिंती असलेली एक इमारत, की कॅम्पस — आणि प्रत्येक शैलीची किंमत काय.
🧒 सोप्या शब्दांत
कतरिना चार विभाग तीन प्रकारे ठेवू शकते. एक मोठा हॉल सोपा, पण कागद मिसळतात. भिंती असलेली एक इमारत प्रत्येक office चे कागद वेगळे ठेवते. वेगळ्या इमारती प्रत्येक office ला आपल्या दिवशी बदल करू देतात. पण प्रत्येक प्रश्न म्हणजे campus ओलांडून फेरी. विद्यार्थिनीच्या प्रवेशासाठी 3 फेऱ्या लागतात, आणि काही निरोप पोहोचतच नाहीत.
📖 नवे शब्दmonolith — एकच unit म्हणून deploy होणारा एक program, जसा एक मोठा हॉलmodular monolith — विभागांमध्ये भिंती असलेला एक program, build च्या वेळी तपासलेलाmicroservices — प्रत्येक विभाग स्वतंत्र program, network वरून बोलणाराhop — एका service कडून दुसऱ्याकडे एक call, जसे enrol चे 3 hops
⏪ आधी
टीम गोंधळलेल्या monolith मधून थेट microservices कडे गेल्या, आणि गुंतलेल्या imports ऐवजी गुंतलेले network calls आले.
💡 काय
तीन शैली: monolith, build-time check असलेल्या भिंतींचा modular monolith, आणि network वरचे microservices.
⚙️ कसे
Microservices मध्ये enrol 3 hops चालतो: +3 ms आणि 99.7% यशस्वी; report card 2 hops, 99.8%; दोन्ही monoliths 100.0% वर.
🎯 का
Microservices 4 स्वतंत्र deploys देतात, पण hops, partial failure आणि sagas घेऊन; modular monolith भिंती फुकट ठेवतो.
🚀 पुढे
पुढचा धडा offices मधल्या फेऱ्यांऐवजी board वर एक सूचना लावतो: events, आणि थोडे मागे राहणारे read model.
🧪 इथे करून पाहा — एक request, तीन शैली — एका hop ची किंमत बदला
सूचना फलक आणि display फलक — एकदाच publish करा, थोडे मागे असलेले model वाचा.
🧒 सोप्या शब्दांत
पूर्वी admissions नव्या विद्यार्थिनीबद्दल सांगायला तीन offices मध्ये जात असे. आता ती board वर एक सूचना लावते: 'दीपिका 5A मध्ये आली.' प्रत्येक office board वाचते आणि आपले काम करते. Library सुरू झाली की तीही board वाचते. हॉलमधील marks board थोड्या वेळाने अद्ययावत होतो, म्हणून तो 82.33 आधी 78.5 दाखवू शकतो.
📖 नवे शब्दevent — काहीतरी घडल्याची सूचना, जसे StudentAdmittedlistener — board वाचून सूचनेवर कृती करणारे officeCQRS — एका ठिकाणी लिहिणे आणि दुसऱ्या, तयार ठिकाणाहून वाचणेeventually consistent — थोडा वेळ मागे असलेली, आणि मग बरोबरीला येणारी copy
⏪ आधी
नवीन विद्यार्थिनी आली की admissions प्रत्येक office मध्ये जाऊन सांगत असे, आणि नवी library म्हणजे admissions मध्ये पुन्हा बदल.
💡 काय
सूचना फलकावर events, आणि CQRS: लिखाण नोंदवहीत जाते, वाचन display board वरून होते जो नंतर अद्ययावत होतो.
⚙️ कसे
StudentAdmitted(Dipika, 5A) 3 listeners पर्यंत पोहोचते; marks 72, 85, 90 लिहिले, 2 applied → 78.5, नंतर 82.33.
🎯 का
Events मुळे admissions 0 विभाग import करते आणि 4था listener काहीही न बदलता जोडला जातो; किंमत म्हणजे मागे राहणारे read model.
🚀 पुढे
पुढचा धडा विचारतो data कोणाच्या मालकीचा: सामायिक कपाट, खिडकी, की copy केलेली सूचना.
🧪 इथे करून पाहा — थेट calls विरुद्ध सूचना फलक — मग read model ला बरोबरीला येऊ द्या
सामायिक कपाट, एक खिडकी, की नोटिशीची प्रत — shared DB विरुद्ध API विरुद्ध events.
🧒 सोप्या शब्दांत
Fee पावत्यांसाठी accounts ला प्रत्येक विद्यार्थिनीचे नाव हवे. ती थेट admissions चे कपाट वाचू शकते, पण column चे नाव बदलल्याने 15 वेळा अडचण येते. ती admissions च्या खिडकीवर विचारू शकते, पण office बंद असताना 3 वेळा उत्तर मिळत नाही. किंवा प्रत्येक सूचना आपल्या वहीत copy करू शकते, जी 2 वेळा थोडी मागे असते.
📖 नवे शब्दdata ownership — आपले tables कसे दिसतील हे एकच विभाग ठरवतोshared database — अनेक टीम तेच tables वाचतात, सामायिक कपाटासारखेAPI — मालकाला खिडकीवर विचारणे; मालक उघडा असेपर्यंतच चालतेstale — अजून नव्या बदलापर्यंत न पोहोचलेली copy
⏪ आधी
प्रत्येक application त्याच tables वाचत आणि लिहित असे, म्हणून column चे नाव बदलायची कोणाची हिंमत होत नसे.
💡 काय
Data ownership: प्रत्येक table ची मालकी एका विभागाकडे; इतरांना तो shared database, API किंवा events मधून मिळतो.
⚙️ कसे
20 वाचनांत, tick 5 ला rename आणि 10–12 ला बंद: shared DB 15 वेळा अपयशी, API 3 वेळा, events 2 वेळा जुने.
🎯 का
Shared DB ने 2 इतर टीमचा code देखील मोडला; API runtime ला जोडते, आणि events ताजेपणाच्या बदल्यात स्वातंत्र्य देतात.
🚀 पुढे
पुढचा धडा एक inspector नेमतो जी प्रत्येक push वर आराखडा तपासते, कोणतेही नवे दार राहण्याआधी.
🧪 इथे करून पाहा — shared DB विरुद्ध API विरुद्ध events — rename, बंद पडणे आणि lag हलवा
कतरिनाने सुंदर आराखडा काढला. मग घाईत असलेल्या एका बांधकाम कामगाराने भिंतीत दार पाडले. म्हणून ऐश्वर्या इमारत निरीक्षक बनते. ती प्रत्येक push वर 6 नियम तपासते. आज 4 fail होतात, आणि नवे दार स्वीकारले जात नाही. 5 चुकीची दारे बंद केल्यावर सगळे 6 pass होतात आणि build हिरवा होतो.
📖 नवे शब्दfitness function — architecture चा नियम तपासणारी आपोआप चालणारी testCI — प्रत्येक push वर प्रत्येक check चालवणारी pipelinecycle — एकमेकांना import करणाऱ्या दोन rooms, जसे grades आणि dbexit code — check परत देणारा आकडा: 0 म्हणजे pass, 1 म्हणजे fail
⏪ आधी
Architecture चे नियम wiki page वर आणि एका senior engineer च्या डोक्यात होते, आणि इमारत आराखड्यापासून दूर जात राहिली.
💡 काय
Fitness functions म्हणजे CI मधील architecture tests: cycles नाहीत, आतल्या दिशेची dependencies, leaks नाहीत, विभाग-ओलांडणारे imports नाहीत.
⚙️ कसे
ऐश्वर्याचा check sample वर 6 पैकी 4 नियमांत fail होतो, exit code 1; 5 planted corridors काढल्यावर: 6/6, exit 0.
🎯 का
Build fail करणारा नियम drift त्याच दिवशी पकडतो, जसे grades ↔ db cycle, सहा महिन्यांनी नाही.
🚀 पुढे
पुढचा धडा इमारत चार zoom levels वर काढतो, आणि drawing code मधूनच बनवतो म्हणजे ते खोटे बोलू शकत नाही.
🧪 इथे करून पाहा — मार्गिका पेरा किंवा विटांनी बंद करा — 6 fitness functions CI सारख्या पुन्हा चालतात
कॅम्पसचा नकाशा, इमारतीचा आराखडा, मजल्याचा नकाशा — code मधून तयार होणारे text C4 model, आणि drift.
🧒 सोप्या शब्दांत
ऐश्वर्या ही नवी शिक्षिका शाळेत येते. कतरिना आधी तिला campus चा नकाशा दाखवते. मग इमारतीचा आराखडा, मग एका मजल्याचा आराखडा. तिने विचारले तरच, एका room मधली बाके. पण भिंतीवरचा आराखडा जुना आहे: त्यात बांधकामात नंतर आलेले 3 corridors नाहीत. म्हणून कतरिना इमारतीवरूनच नवा आराखडा छापते.
📖 नवे शब्दC4 model — चार zoom levels: context, containers, components आणि codecontainer — चालणारी किंवा data साठवणारी गोष्ट, जसे web app किंवा databasediagram as code — text म्हणून लिहिलेले चित्र, जसे 31 ओळींची DSL filedrift — चित्र आणि इमारत आता जुळत नाहीत, जसे 3 गहाळ arrows
⏪ आधी
Wiki वरचा हाताने काढलेला box diagram दोन वर्षांपूर्वीचा आराखडा दाखवत होता, आणि नवीन लोक त्यावर विश्वास ठेवत.
💡 काय
C4 model: context, containers, components आणि code, Structurizr DSL text file म्हणून लिहिलेले.
⚙️ कसे
Analyzer 31 ओळींचा DSL लिहितो, ज्याचे component arrows imports मधून येतात, जसे app -> domain (6).
🎯 का
Wiki drawing मध्ये code मधले 3 arrows नाहीत: app → infra, domain → infra, domain → web; fixes नंतर 0 drift.
🚀 पुढे
पुढचा धडा निर्णय का घेतला ते लिहून ठेवतो, आणि पर्यायांना गुण देतो म्हणजे trade-off दिसतो.
🧪 इथे करून पाहा — code मधून generate केलेला component view — आणि wiki पासूनचा त्याचा drift
मुख्याध्यापिकेची नोंदवही — decision records आणि weight check सह ATAM-lite गुणांकन.
🧒 सोप्या शब्दांत
कतरिना मुख्याध्यापिकेच्या office मध्ये एक नोंदवही सुरू करते. प्रत्येक मोठ्या निर्णयासाठी ती परिस्थिती, निवड आणि त्याची किंमत लिहिते. टीम तीन पर्यायांना गुण देते: भिंती असलेल्या इमारतीला 42, एका हॉलला 35, campus ला 34. पुन्हा कधी विचार करायचा तेही ती लिहिते: वेगळे releases खूप महत्त्वाचे झाले तर.
📖 नवे शब्दADR — एका निर्णयाची छोटी नोंद: संदर्भ, निर्णय आणि परिणामtrade-off — एक गुण मिळवण्यासाठी दुसऱ्याचा काही भाग सोडणेweight — एखादा गुण किती महत्त्वाचा आहे, धड्यात 1 ते 3superseded — नव्या निर्णय-नोंदीने बदललेले, कधीच edit न केलेले
⏪ आधी
मोठे निर्णय meeting मध्ये घेतले जात आणि विसरले जात; एका वर्षाने एकच इमारत का आहे हे कोणालाच माहीत नसे.
💡 काय
ADR संदर्भ, निर्णय आणि परिणाम नोंदवतो; ATAM-lite पर्यायांना weighted quality scenarios नुसार गुण देते.
⚙️ कसे
5 scenarios, weights 1–3: modular monolith ला 42, monolith ला 35, microservices ला 34; ADR-0007 14 ओळींचा आहे.
🎯 का
Weights महत्त्वाचे: deployability चे weight 4 झाले तर microservices जिंकतील, म्हणून ADR नेमके तिथेच पुन्हा पाहायला सांगतो.
🚀 पुढे
पुढचा धडा चार terms मध्ये इमारत पाहतो: ती कशी बिघडते, कशी सुधारते, आणि route by route कशी बदलायची.
🧪 इथे करून पाहा — weights हलवा — दुसरा पर्याय कधी जिंकतो?
वाढा, सडू नका — काळानुसार cycles आणि propagation cost, strangler fig, आणि संपूर्ण नकाशा.
🧒 सोप्या शब्दांत
Exam च्या गडबडीत बांधकाम करणारे shortcuts टाकतात. इमारत गुंतते: corridors चे 4 फेरे तयार होतात. पुढच्या term ला निरीक्षिकेचे checks ते सगळे काढतात. मग शाळा नवीन wing बांधते. ती जुनी इमारत बंद करत नाही. द्वारपाल एका वेळी एका प्रकारच्या पाहुण्यांना नवीन wing कडे पाठवतो, सगळे तिथे जाईपर्यंत.
📖 नवे शब्दarchitecture erosion — shortcuts मुळे इमारत हळूहळू आराखड्यापासून दूर जाणेpropagation cost — एखादा बदल इमारतीचा किती भाग गाठू शकतो, जसे exam rush मध्ये 49.7%strangler fig — पुढच्या दारामागे एका वेळी एक route असे जुने system बदलणेfacade — request जुन्या की नव्या भागाकडे जाईल हे ठरवणारा द्वारपाल
⏪ आधी
जुन्या systems गोठवून एकाच big bang मध्ये पुन्हा लिहिल्या जात, महिनोनमहिने features शिवाय आणि धोकादायक weekend cutover सह.
💡 काय
Evolutionary architecture: प्रत्येक term ला झीज मोजा, आणि strangler fig ने जुने भाग एका वेळी एक route बदला.
⚙️ कसे
Propagation cost 24.3% → 31.4% → exam rush मध्ये 49.7%, नंतर checks सह 22.2%; routes 2% → 100% हलतात.
🎯 का
Checks झीज थांबवतात, 4 cycles पुन्हा 0 होतात, आणि लहान उलटवता येणाऱ्या पायऱ्यांमुळे शाळा चालू असताना नवीन wing वाढते.
🚀 पुढे
पुढे, scan() तुमच्या ओळखीच्या खऱ्या codebase वर चालवा: मजले मोजा, cycles शोधा आणि पहिला ADR लिहा.
🧪 इथे करून पाहा — झिजेची सत्रे, आणि strangler-fig route क्रम