Yeniden Yazımın Kötü Yanları: 5 Yaşındaki Bir Arka Uç Kod Tabanını Nasıl Geliştirdim (Ve Neden Siz de Kodu Yeniden Yazmamalısınız)

Mevcut sistemlerin, üretimi bozmadan veya yılların köşeli tarihini kaybetmeden kademeli olarak modernleştirilmesi üzerine derin bir bakış.

1. Çoğu Legacy Sistem Kötü Kod Yüzünden Değil, Duygusal Kararlar Yüzünden Başarısız Olur.

Üretim arka planınız yavaşlamaya başladığında, kod sizin en büyük düşmanınız değildir. Ego en büyük düşmanınızdır. Bunun hemen arkasında yazılım mühendisliğinin iki sireni: Yeniden Yazım Cazibesi ve Mikroservis Hype’ı vardır.

5 yıllık bir arka plana bakarken, onu baştan yazmak istemek her zaman caziptir. Yine de gerçek şu ki: üretim baskısı mühendisliğin yeniden yapılandırmak istemesi nedeniyle durmaz. Eğer modernizasyon stratejinizi tamamen yeni bir yazıma veya derin bir tedarikçi kilitlemeye sıkı sıkıya bağlıysanız, mevcut müşterilerinizden yeni değerleri mahrum bırakarak işinizi tehlikeye atıyorsunuz.

5 yıllık arka planımızı yeniden yazmadık; onu evrimleştirdik. Ağır tedarikçi kilitlemesinden kaçındık. AI ajanlarını kod yazmamız için değil, kaybolmuş modülleri anlamamızı hızlandırmak için kullandık.

2. 5 Yıllık Bir Arka Plan Nasıl Görünür?

5 yıldır çalışan bir sistemi devralan ya da bakımını yapan biriyseniz, “teknik borç” kavramı soyut ve steril gelebilir. Gerçek şu ki, 5 yıllık bir arka plan, kötü yapılmış bir köprüden çok, kendi kalıntılarının üzerine inşa edilmiş eski bir şehir gibidir.

Bu sistemin başlama aşamasında, küçük bir takım erken kariyer düzeyinde bir anlayışla inşa edildi. Amaç, pazar uyumunu bulmaktır, mükemmel bir alan odaklı tasarım oluşturmak değil.

Sonuç olarak, desen kayması her yerde vardır. Kod tabanına yakından baktığınızda, farklı paradigmaların popüler olduğu zamanları görebilirsiniz. Eski denetleyicilerde 800 satırlık ham HTTP istekleri, veritabanı sorguları ve iş mantığı karışmıştır.

3. Yeniden Yazım Cazibesi

Karışık soyutlama seviyeleri ve sıkı bağlı çekirdek alanlar karşısında, sistemi sıfırdan yeniden yazma çağrısı oldukça caziptir. Yeniden yazım temiz görünür ve eski hataların sonunu vaadedebilir.

Fakat bir yeniden yazım tehlikelidir ve çoğu zaman bir tuzaktır. Gizli fırsat maliyeti büyüktür; mevcut işlevselliği “daha temiz” bir halde yeniden inşa etmek için harcanan her ay, ürünün duraksamasına yol açar.

Bir yeniden yazım için doğru güvenlik ağı yüksek bir kod kapsamı değildir — kapsam yalnızca yürütmeyi ölçer, doğruluğu değil. Gerçekten ihtiyacınız olan, her kritik yolun gözlemlenebilir çıktısını yakalayan kapsamlı bir davranış testleri setidir.

4. Duraklayan Mikroservis Girişimi

Yeniden yazmayı düşünmedik; mikroservislere geçişi agresif bir şekilde takip ettik. Bu alanların ayrı hizmetler olarak bölünmesi, “kıdemli” bir mühendislik yaklaşımı olarak görünüyordu.

Planın ilk önerildiği zaman, daha fazla mimari deneyime sahip bir mentordan danışmanlık aldım. Mikroservislerin ölçeğimiz için gerekli olmadığı konusunda açıkça uyardı. O zaman bunu kabul etmedim — ama şimdi bu tavsiyeyi çok isterdim.

5. Kademeli Modernizasyon Çerçevesi

Bu yaklaşım, Martin Fowler’ın tanımladığı Strangler Fig pattern ile örtüşüyor — eski davranışları yavaş yavaş yenileriyle değiştirmek. Bu model, her modernize modülün eski çekirdek etrafında büyüyen yeni bir halkasıdır.

Adım 1: Koda Dokunmadan Önce Sistem Haritalama

Yalnızca bir satır refaktör yazmadan önce, terimi haritalamalısınız. Sonrası, içerisinde değişiklik yapıldığında üç diğerine şok dalgaları gönderen modülleri tanımlamak için bağımlılık izleme kullandık.

Adım 2: Davranış Kilitleme

Ne test edemeyeceğinizde güvenle değişiklik yapamazsınız. Karakterizasyon testleri tanıttık. Bu testler, doğruluğu doğrulamak için değil, mevcut, gerçek davranışı belgelendirip kilitlemek için yazıldı.

Adım 3: Alan İzolasyonu

Testler kurulduktan sonra alan izolasyonuna başladık. Bu, kodu yeni bir sunucuya taşımak anlamına gelmiyor; bunun yerine, kuklaların belirli bir isim alanında ve kesin sınırlar içinde hareket etmesini sağladık.

6. AI İle Kod Arkeoloğu Olmak

AI bir mimar değildir. Ama sağladığı şey, anlama aşamasında benzersiz bir hızlandırmadır. AI’yı ben bir Kod Arkeoloğu; olarak kullandım.

1.200 satırlık bir denetleyiciyle karşılaştığımda, insan mühendisin gerçekleştirmesi günler alacak bir durumu hızla çözebiliyordum.

7. Git Geçmişinin Açtığı Gerçekler

Bir mimarinin gerçek durumunu anlamak istiyorsanız, günümüzdeki kod tabanına değil, git geçmişine bakmalısınız. Gelişim aşamasında, komutlar büyük oluyordu; her şey bir arada sınırsızca ve hızlı bir şekilde ekleniyordu.

8. Tedarikçi Kilitlenmesinden Kaçınmak

Modern tuzaklardan birisi, mimarinizi özel hizmetlerle birleştirmektir. Biz iş mantığını taşınabilir kıldık. Bulut sağlayıcılarına, özel alan mantığımızın uzantıları olarak değil, birer hizmet olarak davrandık.

9. Ölçülebilir İyileştirmeler

Sonuçlar somuttu ve izlenebilir:

• Sipariş işlemlerindeki kusur oranı önemli ölçüde düştü.
• Bilişsel yük azaldı.

10. Zor Dersler

Her şey başarılı olmadı. Gereksiz refaktörasyonlar nedeniyle zaman kaybettim. Boy Scout Kuralı kodları yalnızca dokunduğunuzda geçerlidir; geçmeyeceğiniz kodda bu kural geçerli değildir.

11. “Modern”ı Yeniden Tanımlamak

Modern yeniden yazım veya mikroservisler demek değildir. Modern, Gözlemlenebilirlik, Değiştirilebilirlik ve Açık Sınırlar anlamına gelir.

12. Tartışma

Evlat edinme, ego yönlendirmeli yazımlardan daha iyidir. Ancak bu sorular evrensel cevaplar sunmaz; ekip, ölçek ve bağlama bağlıdır. Diğer mühendislerin nasıl başa çıktığını duymak isterim:

• Yeniden yazım için tam olarak doğru an nedir?
• Bir organizasyon, mikroservisler için gerçekten ne zaman hazırdır?