AI के दौर में, refactoring अब सिर्फ मेहनत-मजदूरी नहीं रही
(blog.lemonbase.team)यह AI + Codemod के साथ Design System legacy को व्यवस्थित करने पर एक लेख है। उम्मीद है कि बड़े पैमाने के refactoring की तैयारी कर रहे लोगों के लिए यह उपयोगी संदर्भ बनेगा।
दृष्टिकोण: Codemod + AI
- कंपनी के आंतरिक Design System में Typography सहित कई components Deprecated हो चुके थे
- नया Design System + Tailwind लागू होने के बाद एक ही codebase में Deprecated patterns मिले-जुले रूप में मौजूद थे
- Boy Scout rule के तहत थोड़ा-थोड़ा करके साफ़ करना मुश्किल था
- files की संख्या बहुत ज़्यादा थी
- feature change PR और refactoring PR को अलग रखने के सिद्धांत के कारण इसकी priority लगातार पीछे खिसकती रही
दृष्टिकोण: Codemod + AI
- string replacement की जगह AST-based Codemod(jscodeshift) का उपयोग
- AI का उपयोग करके:
- Deprecated Typography usage patterns की पूरी जाँच
- Before/After rules को व्यवस्थित करना
- jscodeshift transformation script के draft और test code लिखने में सहायता
- मुख्य transformation उदाहरण:
tekst→tekst→
परिणाम
- Typography से जुड़े Deprecated patterns का लगभग 95% automatic transformation
- mixed patterns में बड़ी कमी आई, जिससे code consistency और onboarding experience बेहतर हुआ
- “अगला Design System replacement भी Codemod से करेंगे” जैसा एक विकल्प तैयार हो गया
सीखी गई बातें
- सोचा गया था उससे कहीं अधिक refactoring कार्य AST + Codemod से automate किए जा सकते हैं
- बड़े पैमाने के automatic transformation में “file diff review” की तुलना में “transformation rules + test review” अधिक efficient और सुरक्षित है
- AI को pattern analysis और draft writing assistance की भूमिका में, और Codemod को consistent bulk replacement की भूमिका में अलग रखना बेहतर है
6 टिप्पणियां
बहुत दिलचस्प लेख है..!
अभी हमारे प्रोजेक्ट का फ्रंटएंड कोड पूरी तरह बिखरा हुआ है, इसे आज़माना पड़ेगा!
नमस्कार। इसे रुचि से पढ़ने के लिए धन्यवाद!
इसे अपनाते समय कोई भी सवाल हो, तो बेझिझक कभी भी छोड़ दीजिए!!
यह बहुत उपयोगी लेख है। AST rules तय करते समय, मुझे याद है कि शुरुआत में सब कुछ automate करने की कोशिश करके काफ़ी जूझना पड़ा था... यह करते-करते समझ आया कि अस्पष्ट cases को छोड़कर सिर्फ़ पक्की चीज़ें तय करना ही सही जवाब है।
सही है :'( मेरे साथ भी बिल्कुल ऐसा ही हुआ था कि "चलो, सब कुछ automate कर देते हैं!" कहकर बाद में काफ़ी परेशानी उठानी पड़ी।
जैसा आपने कहा, ambiguous cases को छोड़कर पहले स्पष्ट patterns को handle करना ज़्यादा efficient रहा haha
इसे इस तरह two-track approach में ले जाना, implementation/review/bug risk तक को ध्यान में रखें तो काफ़ी efficient लगा!
ओह, यह अच्छा है।
अच्छा समझने के लिए धन्यवाद!!