C#'ta Eski Kodu Yeniden Yazmalı mısınız? Derek Comartin'ın Görüşü Üzerine Derinlemesine İnceleme

"Asla Kod Yeniden Yazma" İlkesi

Derek, yazılım geliştirmede sıkça verilen ve "Kodları asla sıfırdan yeniden yazma." tavsiyesiyle başlar. Bu düşünce, Joel Spolsky'nin "Yapmamanız Gereken Şeyler" başlıklı ünlü blog yazısından gelmektedir ve eski sistemlerin yeniden yazılmasına karşı güçlü bir uyarı içermektedir.

Derek, (0:32)'de Spolsky'nin parçasından en kritik fikri belirtir:

"Herhangi bir yazılım şirketinin yapabileceği en kötü stratejik hatayı yaptılar: Kodu sıfırdan yeniden yazmaya karar verdiler."

Derek, ana çıkarımın şu olduğunu açıklar: sıfırdan başladığınızda, ilk seferden mutlaka daha iyi bir iş çıkaracağınızdan emin olmak için bir neden yoktur. Özellikle büyük, karmaşık sistemlerde, mevcut uygulamaya gömülü gizli değeri küçümsemek kolay olabilir.

Basitlik İllüzyonu

(1:07)'de Derek, yeni bir geliştirici olarak erken zamanlarına bakar. Birçok diğer geliştirici gibi, genellikle kodun kötü olduğunu düşündüğü için bir sistemin büyük bölümlerini yeniden yazmak isterdi. Ama daha sonra bu inancın çoğunlukla kodu anlamamaktan, kodun kendisinin özünde kötü olmasından değil, kaynaklandığını fark etti.

İlişkilendirilebilir bir gerçeği paylaşır:

"Bir şeyi baştan sona sıfırdan başlatmak, gerçekten derine gömülmek, kod tabanına girmek, tüm karmaşıklığı, uç durumları anlamak gerçekten zor."

Aslına bakarsanız, "feci bir durum" gibi görünen şey, evrim ve yamanın yıllarına sarılmış mantığın anlaşılamayan bir hali olabilir. Geliştiriciler, genellikle yabancılığı kötü tasarımla karıştırırlar.

Yeniden Yazmaların Haklı Olduğu Durumlar

Derek yine de yeniden yazmanın her zaman kötü olmadığını belirtir. (1:44) civarında, nüansı getirmeye başlar. Yıllardır aynı kod tabanında olan, tüm alan karmaşıklığını ve sistem sınırlamalarını bilen ekipler için—yeniden yazma geçerli bir seçenek olabilir.

"Uzun zamandır bir sistem içindeyseniz... işte o zaman nüans ortaya çıkar. Evet, bu şeyin feci bir durum olduğunu ve bizi geride bıraktığını söyleyebilirsiniz. Belki de yeniden yazmayı yapmak uygundur."

"Kötüyken Daha İyi" ve 80/20 Kuralı

Derek, 2:01'de "Kötüyken Daha İyi" kavramını tanıtır ve bunu Pareto İlkesi (80/20 kuralı) ile bağdaştırır. Sıklıkla, sistemin değerinin %80'inin sadece %20'sinden geldiğini savunur. Bu nedenle, yeniden yazarken hedef, her şeyi kopyalamak değil, gerçekten değer katan özü vurgulamak olmalıdır.

"Daha az işlevsellikle daha kötü bir seçenek olan bir noktaya geliyor."

O, basitliğin ve pratikliğin çoğu zaman bütünlüğün önüne geçtiğini açıklar. Sınırlı ama kullanılabilir ve sürdürülebilir bir sistem, geniş ama bakım yapmak zor olan bir eski platformdan daha iyi hizmet edebilir.

Maliyet ve Yararın Değerlendirilmesi

2:47'de Derek, nihai kararın genellikle maliyet-yarar analizine indirgenmesi gerektiğini öneriyor. Yeniden yazma uğruna yeniden yazma asla haklı gösterilemez. Ancak eski kodu sürdürmenin maliyeti veya eski teknolojiyle sınırlı kalmanın maliyeti yeniden inşa etmekten daha büyükse, denklem yeniden yazma lehine değişebilir.

Rekabetçi avantajınızın, güncelliğini yitirmiş platformlarda veya araçlarda sıkışıp kaldığınız için engellendiği durumlara atıfta bulunuyor. Bu gibi durumlarda, teknoloji açığı kendisi başlı başına yeniden inşa etmek için geçerli bir neden haline gelir.

Greg Young'dan Bir Ders

Derek, 3:12'de Greg Young tarafından yazılan ve kazara üretime geçmiş bir prototipin yeniden yazıldığı müthiş bir yazıya değiniyor. Yeniden yazma 9 ay sürdü. Sonuç?

"Dokuz ay boyunca güzel mimari ve kod çalışmaları yaptıktan sonra, yaklaşık olarak ayda fazladan 10.000 dolar kazanıyorduk."

Greg, bu tek yeniden inşaya derinlemesine yatırım yapmak yerine 30 yeni prototip oluşturarak yeni stratejileri test etmenin daha iyi olacağını öne sürdü. Derek, bu sonucu seviyor çünkü teknik mükemmelliğin her zaman hedef olduğu varsayımına meydan okuyor.

Bazen, "yeterince iyi" olan yazılım kazanır — özellikle işletme değeri sağladığında.

Eski vs. Yeni Önyargısı

4:20'de Derek, eski olan kötü ve yeni olan iyi olduğu yaygın zihniyetine değiniyor. Kendi tecrübesinden bir örnek sunuyor: iki üçüncü taraf hizmetiyle entegre oluyor, ikisi de aynı amaca hizmet ediyor. Biri modern JSON kullanıyor ve muhtemelen Python'da geliştirilmiş. Diğeri ise şaşırtıcı bir şekilde XML döndürüyor ve muhtemelen 1990'larda ColdFusion ile geliştirilmiş.

"Her ikisi de eşdeğer. Her ikisi de istikrarlı. Bana ve müşterilerime aynı değeri sağlıyorlar."

Bu, daha yeni olanın her zaman daha iyi olmadığını vurgular. İstikrar, güvenilirlik ve kullanışlılık genellikle teknoloji yığınından çok daha önemli olabilir.

Derek'in Kişisel Yeniden Yazma Deneyimi

Sonunda Derek, 5:31'de kendi hikayesini paylaşıyor. Orijinal sistemin alanında altı yılı aşkın zaman geçirdikten sonra geniş çaplı bir yeniden yazmaya katıldı. Bu yeniden yazma yaklaşık 14 ay sürdü, ve esas olarak sistemin modern e-ticaret araçları ve çevrimiçi hizmetlerle entegre olma yeteneğini sınırlayan bir teknoloji açığı tarafından yönlendirildi.

"Bu amaç için gerçekten yeni bir şey inşa etmemiz gerekiyordu."

Bu sadece "kötü kod" durumu değildi — sistemin temel olarak evrim geçirme kapasitesi yoktu, bu yüzden yeniden inşa tek uygulanabilir yoldu.

Son Düşünceler

Derek, videonun bitiminde, 6:11 civarında, yanıtın yalnızca "evet" veya "hayır" olmadığını vurguluyor.

"Kesin bir yanıtın hayır olduğunu sanmıyorum. Karar verirken dikkatli olmalısınız çünkü bağlam önemlidir ve nüanslar çoktur."

Eski C# kodunu yeniden yazmanız gerekebilir — ancak sadece bağlam, alan bilgisi, değer sağlama ve teknoloji sınırlamaları bu kararı desteklediğinde.

Sonuç

Derek Comartin'in videosu, yazılım geliştirme dünyasının en çok tartışılan konularından biri hakkında dengeli, deneyime dayalı bir perspektif sunuyor: Eski kodu yeniden yazmalı mısınız? Onun tavsiyesi dogmatik değil — düşünülmüş, temellendirilmiş ve kişisel bilgilerle dolu.

Tarihsel dersleri, gerçek dünya hikayelerini ve "yeni daha iyidir" tuzağını dikkate alarak, Derek, izleyicilere yazılım mimarisinde en önemli kararlardan birini vermek için olgun bir çerçeve geliştirmelerine yardımcı oluyor.

Kendi C# projenizde benzer bir seçimle karşı karşıyaysanız, Derek'in videosunu tekrar izleyin ve bağlamınızı dikkatlice değerlendirin. Bazen, eski kod düşman değildir — yalnızca yanlış anlaşılmıştır.

Derek'in YouTube Kanalı'nda daha fazla bilgi dolu video izleyin. CodeOpinion.com adresini ziyaret edin ve Derek'in diğer içeriklerine ulaşın.