- Kod refaktörizasyonu, kod tabanını sağlıklı tutmada önemli bir rol oynar
- Ancak hatalı refaktörizasyon, kodu daha karmaşık ve bakımını daha zor hale getirebilir
- İyi refaktörizasyon ile kötü refaktörizasyonu ayırt etmeyi ve kötü refaktörizasyonun tuzaklarından nasıl kaçınılacağını bilmek gerekir
Refaktörizasyonun iyi, kötü ve çirkin tarafları
- Soyutlama iyi de olabilir kötü de olabilir. Esas mesele, onu ne zaman ve nasıl uygulayacağını bilmektir
- Bazı yaygın tuzaklar ve bunlardan kaçınma yolları açıklanıyor (orijinal koddaki örnekler atlanmıştır)
1. Kodlama stilini ciddi biçimde değiştirmek
- Geliştiriciler refaktörizasyon sırasında kodlama stilini tamamen değiştirme hatasına sıkça düşer
- Yeni bir kütüphane eklemek veya tamamen farklı bir kodlama stilini benimsemek bakım üzerinde olumsuz etki yaratabilir
- Kodu daha idiomatik ve daha okunabilir hale getirmek iyidir, ancak tamamen yeni bir paradigma veya dış bağımlılık getirmemek daha doğru olur
2. Gereksiz soyutlama
- Mevcut kodu anlamadan aşırı miktarda yeni soyutlama eklemek sorunludur
- Bu yalnızca karmaşıklığı artırabilir ve kodu anlamayı zorlaştırabilir
- Mantığı küçük ve yeniden kullanılabilir fonksiyonlara ayırmak iyidir, ancak gereksiz karmaşıklık eklenmemelidir
3. Tutarsızlık eklemek
- Kod tabanının yalnızca bir bölümünü tamamen farklı çalışacak şekilde güncellemek kafa karışıklığı ve hayal kırıklığı yaratabilir
- Yeni bir desen getirmek gerekiyorsa, önce ekibin onayını almak iyi olur
- Tüm uygulamada veri getirme konusunda tutarlı bir yaklaşımı korumak önemlidir
4. Refaktörizasyondan önce kodu anlamamak
- Kodu öğrenirken aynı anda refaktörize etmek iyi bir fikir değildir
- Bu durum bug oluşturabilir, performansı düşürebilir ve işlevleri ortadan kaldırabilir
- Refaktörizasyondan önce kodu derinlemesine anlamak ve mevcut davranışı koruyarak iyileştirmek önemlidir
5. İş bağlamını anlamak
- İş ihtiyaçlarını anlamadan teknik seçimler yapmak felakete yol açabilir
- SEO'ya büyük ölçüde bağımlı bir e-ticaret sitesi için istemci tarafı render kötü bir seçim olabilir
- Next.js veya Remix gibi sunucu tarafı render yaklaşımları, SEO ve performans açısından daha iyi bir seçim olabilir
6. Aşırı kod birleştirme
- Esnekliği feda ederek kodu "temiz" hale getirmek için zorla birleştirmek iyi değildir
- Soyutlama yaparken her zaman hizmet ettiği kullanım senaryoları dikkate alınmalıdır
- Soyutlama, orijinal uygulamanın sunduğu tüm işlevlere izin verebilmelidir
Doğru şekilde refaktörize etmek
- Kod refaktörizasyonu gereklidir. Ama doğru şekilde yapılmalıdır
- Kodumuz mükemmel değildir ve düzenlenmeye ihtiyaç duyar, ancak mevcut kod tabanıyla tutarlılık korunmalıdır
- Kodu iyi anladıktan sonra refaktörize etmek gerekir ve soyutlamalar dikkatle seçilmelidir
- Başarılı refaktörizasyon için ipuçları:
- Aşamalı ilerleyin: Baştan sona yeniden yazmak yerine küçük ve yönetilebilir değişiklikler yapın
- Önemli bir refaktörizasyona veya yeni soyutlamalara başlamadan önce kodu derinlemesine anlayın
- Mevcut kod stiline uyun: Bakım için tutarlılık kilit önemdedir
- Çok fazla yeni soyutlama eklemekten kaçının: Karmaşıklığa gerçekten ihtiyaç yoksa sade kalın
- Özellikle ekip onayı olmadan çok farklı programlama stilleri getiren yeni kütüphaneler eklemekten kaçının
- Refaktörizasyondan önce test yazın ve ilerledikçe testleri güncelleyin. Bu, orijinal işlevselliğin korunduğunu doğrulamanıza yardımcı olur
- Ekip arkadaşlarınızın da bu ilkelere uymasını karşılıklı sorumluluk anlayışıyla destekleyin
Daha iyi refaktörizasyon için araçlar ve teknikler
- Daha iyi refaktörizasyon için aşağıdaki teknik ve araçların kullanımı değerlendirilebilir:
Linting araçları
- Tutarlı bir kod stili uygulamak ve olası sorunları bulmak için linting araçları kullanın
- Prettier ile tutarlı bir stile otomatik biçimlendirme yapılabilir
- Eslint ile özel eklentiler üzerinden daha ayrıntılı tutarlılık denetimi yapılabilir
Kod incelemesi
- Refaktörize edilmiş kod birleştirilmeden önce ekip arkadaşlarından geri bildirim almak için kapsamlı kod incelemeleri uygulayın
- Bu, olası sorunları erken tespit etmeye ve refaktörize edilen kodun ekip standartları ile beklentilerine uyduğunu doğrulamaya yardımcı olur
Test
- Refaktörize edilen kodun mevcut işlevleri bozmadığından emin olmak için testler yazın ve çalıştırın
- Vitest, özellikle hızlı, sağlam ve kullanımı kolay bir test runner'dır; varsayılan olarak yapılandırma gerektirmez
- Görsel testler için Storybook kullanmayı değerlendirin
- React Testing Library, React bileşenlerini test etmek için iyi bir yardımcı araç setidir (Angular vb. için varyantları da vardır)
(Uygun) yapay zeka araçları
- Mevcut kodlama stili ve kurallarıyla uyum sağlayabilen yapay zeka araçlarıyla refaktörizasyon çabalarını destekleyin
- Visual Copilot, frontend kodlama sırasında tutarlılığı korumada özellikle yararlı bir araçtır
- Mevcut kodlama stiliyle uyumlu kalarak ve tasarım sistemi bileşenleri ile token'larını doğru kullanarak tasarımı koda dönüştürmeye yardımcı olur
Sonuç
- Refaktörizasyon, yazılım geliştirmede gerekli bir parçadır; ancak mevcut kod tabanı ve ekip dinamikleri gözetilerek dikkatli biçimde yapılmalıdır
- Refaktörizasyonun amacı, kodun dış davranışını değiştirmeden iç yapısını iyileştirmektir
- En iyi refaktörizasyonlar çoğu zaman son kullanıcı tarafından fark edilmez, ancak geliştiricilerin hayatını ciddi ölçüde kolaylaştırır
- Okunabilirliği, bakım yapılabilirliği ve verimliliği artırır, fakat tüm sistemi karmaşaya sürüklemez
- Kod için "büyük planlar" yapmak istediğinizde bir adım geri çekilin, kodu iyice anlayın, değişikliklerin etkisini değerlendirin ve ekibin takdir edeceği kademeli iyileştirmeler yapın
- Gelecekteki siz ve ekip arkadaşlarınız, kod tabanını temiz ve bakımı yapılabilir tutmaya yönelik bu düşünceli yaklaşım için size teşekkür edecektir
6 yorum
Test kodu olmadan birden refaktöringe girişenler de zaman zaman oluyor.
İzlerken sanki son derece tehlikeli bir cambaz ipinde yürüyorlarmış gibi geliyor; bu da insana tuhaf bir heyecan veriyor haha
Bu çok bariz ve temel bir yaklaşım gibi geliyor, haha. Derli toplu şekilde özetlemiş olması güzel görünüyor. Refaktoring yapılınca %100 daha iyi kod çıktığını düşünüyorum. Eğer öyle değilse, bu benim becerilerimin düne göre geriye gittiği anlamına gelmez mi?
Bu kadar bariz şeylerin toparlanmış olmasına bakınca, sanki biri ortalığı mahvetmiş de buna gerçekten sinirlenip yazmış gibi duruyor, hahaha.
Bu, iyi refactoring yapma yöntemlerinden çok, iş hayatında gerçekten iyi kod yazmanın yolu gibi..
(Belli ki bir junior gelip legacy projeyi refactor edeceğim diye orayı burayı gereksiz yere karmaşıklaştırıp bug üretince sinirlenip yazılmış bir yazı gibi görünüyor...)
İşin birimini ve kodun birimini ayırt edemeyen ya da bunları karıştıran kişiler, deneyimleri az ya da çok olsun, böyle refaktöringler yapıyor. Düzeltilmesi kolay ve bakım yapılabilir kod dediğimiz şey sonuçta, sonradan başka biri gelip baktığında da iş akışını okuyabilmesini sağlamalı; ama bunun gerçekten ancak sahada çalışarak edinilen deneyimle anlaşılabilen bir şey olup olmadığını da düşündürüyor.
React'ta aşırı soyutlamanın işareti olarak bir örnek yaşamıştım; UI framework tarafından tablo bileşeni zaten soyutlanmışken, sadece iki tablonun şeması benzer görünüyor diye inversion of control kullanıp hiçbir işe yaramayan yeni bir bileşen oluşturulmaktan kaçınmak gerektiğini düşünüyorum. Atomic design uygulayacağız diye on satırlık boş kabuk bileşenlerin ortalığa saçıldığı örnekleri görünce, farklı bölümlere bakmak gerektiği için gerçekten çok rahatsız ediciydi.
DRY kuralının asıl amacı, görünümü ve işlevi tamamen aynı olan kodu kopyala-yapıştır yapmamak gerektiğiydi; ama bunu yanlış anlayan insanlar mutlaka çıkıyor gibi görünüyor. Tasarım kalıplarına körü körüne bağlanmamak gerektiği sözü de acaba bu bağlamda mı ortaya çıktı?