Yapay zeka çağında, refactoring artık angarya değil
(blog.lemonbase.team)AI + Codemod ile Design System legacy’sini düzenlemeyi anlatan bir yazı.
Büyük ölçekli bir refactoring’e hazırlananlar için faydalı olmasını umuyorum.
Sorunun ortaya çıkış arka planı
- Şirket içi Design System’de Typography dahil birçok component Deprecated oldu
- Yeni Design System + Tailwind kullanıma alındıktan sonra, aynı codebase içinde Deprecated pattern’ler iç içe kaldı
- Boy Scout kuralıyla bunları azar azar temizlemek için
- dosya sayısı çok fazlaydı
- feature değişikliği PR’ı ile refactoring PR’ını ayırma ilkesi nedeniyle iş sürekli öncelik sırasının gerisine itiliyordu
Yaklaşım: Codemod + AI
- String değiştirme yerine AST tabanlı Codemod (jscodeshift) kullanıldı
- AI şu konularda kullanıldı:
- Deprecated Typography kullanım pattern’lerinin tamamını incelemek
- Before/After kurallarını düzenlemek
- jscodeshift dönüşüm script’i taslağı ve test kodu yazımına yardımcı olmak
- Temel dönüşüm örnekleri:
<Body1 bold>텍스트</Body1>
→<span className="typography-body1-bold">텍스트</span><HeadLine5 as="h1" color={SemanticColor.Text.Primary}>
→<h1 className="typography-headLine5 text-primary">
Sonuç
- Typography ile ilgili Deprecated pattern’lerin yaklaşık %95’i otomatik dönüştürüldü
- Karışık pattern’ler büyük ölçüde azaldı, code tutarlılığı ve onboarding deneyimi iyileşti
- “Bir sonraki Design System değişimini de Codemod ile yaparız” seçeneği elde edildi
Öğrenilenler
- Düşünüldüğünden daha fazla refactoring işi AST + Codemod ile otomatikleştirilebiliyor
- Büyük ölçekli otomatik dönüşümlerde “dosya diff review” yerine “dönüşüm kuralları + test review” daha verimli ve güvenli
- AI’nin pattern analizi ve taslak hazırlama desteği, Codemod’un ise tutarlı toplu dönüşüm rolünü üstlenmesi daha iyi
6 yorum
Çok ilginç bir yazı..!
Şu anki projenin front-end kodu darmadağın, bunu denemem gerekecek!
Merhaba. Keyifle okuduğunuz için teşekkür ederim!
Uygulamaya alırken merak ettiğiniz bir nokta olursa lütfen istediğiniz zaman yazın!!
Oldukça faydalı bir yazı. AST kurallarını belirlerken başta her şeyi tamamen otomatikleştirmeye çalışıp epey zorlandığımı hatırladım... Bunu yaparken, belirsiz vakaları dışarıda bırakıp yalnızca net olanları tanımlamanın doğru yaklaşım olduğunu gördüm.
Aynen öyle, ben de aynı şekilde "hepsini otomatikleştirelim!" deyip zorlandığım bir deneyim yaşamıştım.
Bahsettiğiniz gibi, belirsiz vakaları hariç tutup önce net desenleri ele almak daha verimli olmuştu, haha.
Bunu böyle iki hatlı ilerletmek, implementasyon/review/bug riskini de göz önünde bulundurduğumuzda verimli oluyor!
Aa, bu güzelmiş.
Güzel değerlendirmeniz için teşekkürler!!