Avustralya

Miras Kod (Legacy Code) İle Çalışmak 2

Merhaba,

Geçen hafta burada, içinde bulunduğum durumdan bahsetmiştim. Şimdi de nasıl ilerlediğimden bahsedeceğim.

Bana verilen ilk görevlerden biri şu meşhur 1200 satırlık kodda değişiklik yapmamı gerektiriyordu. Bu kodun oluşturduğu sayfa bir nevi Client Dashboard. Yani içinde müşteriye bağlı tüm bilgilerin bulunduğu bir sayfa. Durum böyle olunca da kodun dokunmadığı database, ViewBag yok gibi. Üşenmedim saydım tam 54 tane ViewBag set ediliyor, 30 kere database’e erişiliyor.

Arada şunu belirteyim o zamanlar ReSharper kullanıyordum ve onun önerilerini dinlemek bazen aklınıza bile gelmeyen güzel sonuçlar veriyor. Ancak kısa bir süre sonra farkettim ki belki benim hatamdan veya -haşa- ReSharper’ın hatasından bazı otomatik refactoring işlemleri hatalar oluşturdu kodda. Ben de üzülerek ReSharper’ı kaldırdım makinadan. Bir parantez daha ReSharper Visual Studio’nun da performansını bayağı kötü etkiliyordu. Donmalar oluyordu.

  • Önce methodun içindeki değişken isimlerini anlamlı hale getirdim. Misal, “repository5” yerine “clientRepository” kullandım. Çünkü en tepede tanımlı bir değişkenin aşağıda ne yaptığını anlamak imkansızdı (kod 1200 satır olunca tabi).
  • Siz nasıl kullanıyorsunuz bilmiyorum ama tek satırlık if’lerin parantezlerinden kurtuldum.
  • String.Format yerine string interpolation kullandım.
  • Gereksiz değişken tanımlarından kurtuldum. Aşağıdaki gibi…

Tabi bu arada mevcut yapıyı bozmadan ama anlamaya çalışarak verilen işi de yaptım. Diyemiyorsun ki arkadaş ben bunu baştan yazayım. Açıkçası ilk başladığım günlerde baştan yazmayı ayrı localde bir branch’da denedim. Ancak test ederken her yerden patladı ve vazgeçtim.

Şimdi diyebilirsiniz ki e bu değişikliklerin faydası ne ki! Boşu boşuna görünürde veya işlevsel olarak hiçbirşey değiştirmedik ki! Çok haklısınız… Zaten anlamı itibariyle refactoring tam olarak da bu demektir 🙂 Burada Martin Fowler’ın burada da türkçe olarak tanımlanmış halini bulabilirsiniz. Kodu okumayı ve dolayısıyla anlamayı kolaylaştıran değişiklikler bunlar.

Sadece yukarıda bahsettiğim küçük değişiklikleri yaparak kodun okunabilirliğini ciddi biçimde arttı. Ama daha ciddi değişikliklere gitmeden önce koda daha aşina olmanız yani code base’i ve çalıştığınız domain‘i öğrenmeniz şart. Bir örnekle anlatayım. Bu Client Dashboard ekranının sağ üst bölgesinde frame içinde bir başka projenin kodu çalışıyor(html oluşturuluyor). Ben de burada yapılacak bir değişiklik için haliyle viewları taradım ama bir türlü bulamadım. Saatler sonra farkettim ki tüm o blok string birleştiren bir method ile oluşturulup ekrana bir ViewBag ile getiriliyormuş.

Daha kodun ne yaptığını kavramadan derin refactoring yapmaya çalışmak hem sizi olması gerekenden daha fazla yoracaktır hem de çok büyük ihtimalle hata yapmanıza neden olacaktır.

Zaten yaptığınız değişikliği kontrol edecek bir test mekanizması da olmadığından, yaptığınız değişikliğe güvenmek pek de mantıklı değil. Bu nedenle ilk konsantre olunması gereken konu okunabilirliği arttırmak olmalı.

Değinmem gerektiğini düşündüğüm bir başka konu ise refactoring işleminin sürekli olması. Sevgili Uncle Bob Martin‘in burada dediği gibi refactoring biten bir iş değildir. Yani yaptım bitti oh rahatım diye bir dünya yok. ilk işe başladığımdan bu yana her dokunduğum kod parçasını daha okunabilir ve kullanılabilir yapmanın yollarını arıyorum. Kodu yazmadan önce değişikliğin olacağı methodu bulduğumda önce o methodu bir elden geçiriyorum. Sonra esas geliştirmeye başlıyorum.

Sizi bilmiyorum ama özellikle yalın kod, SOLID prensipleri gibi kavramlar üzerine araştırıp okudukça, insanın bu konulardaki hassasiyeti de bilgisi ölçüsünde gelişiyor. Şu an artık bir çok refactoring işlemini düşünmeden yapıyorum. Gördüğüm yanlışlar ve eksikler beni rahatsız ediyor. Kod kokuyor.

Bu yaptığınız değişikliklerin bütün takım tarafından benimsenmesi ve code review‘larda dikkate alınması bir başka önemli husus. Tabi bu konular yönetimsel kararlar ve tüm takım tarafından kabul edilmesi ve daha önemlisi benimsenmesi gereken kurallar. Bir çok yazılımcı kendi yöntemini en doğrusu kabul eder(Ben de dahil). İnsan psikolojisi değişikliğe direnç gösterir. Bu yüzden takım arkadaşları ile bir araya gelinip bu kuralları beraberce belirleyip sonra da uygulamak en doğrusu olacaktır.

Benim durumumda ise bütün ekip toplam 4 kişiden oluştuğu ve herkes ayrı projelerde çalıştığı ve dahası code review diye bir şey hiç yapılmadığı için ben refactoring işlemlerini yaptım. İlk toplantıda yaptıklarımı kısaca anlattım:) çok da ikna etmeye çalışmadım. Sonrasında da kodu %90 ben değiştirdiğim için öylece kaldı. Kurumsal olmamanın artıları ve eksilerini de burada değerlendirmiş oldum ufaktan.

Bu haftaki yazının da sonuna geldik, devamı haftaya…

2 thoughts on “Miras Kod (Legacy Code) İle Çalışmak 2

  1. Merhaba , bu güzel yazı için teşekkürler devamını bekliyorum. Maalesef benim çalıştığım şirkette de benzer bir durum mevcut. Bu işin içinden nasıl çıkarsınız bilmiyorum ama 4 kişi de devamlı olarak bir proje ile uğraşıyorsa çok zor kodları revize etmek için birilerine daha ihtiyaç var sanırım. En azından şirketin bunun bu şekilde gitmeyeceğini biliyor olması güzel.

    1. Merhaba,
      Yoğunluktan devamını yazamadım bir türlü ama durum şu anda ideal olmasa da daha iyi. Zaman ve sürekli iyileştirme gerekiyor.

Leave a Reply

Your email address will not be published. Required fields are marked *