Önümüzdeki birkaç haftayı ProductLog'un kod tabanını elle gözden geçirerek geçireceğim. Frontend, backend, worker'lar. Yeni özellik eklemiyorum. Hata düzeltmiyorum. Her dosyayı okuyacağım, nesinin yanlış olduğunu bulacağım, elimle düzelteceğim.
Bu, güvenlik ağlarını atladığım için değil. Detaylı agent kurallarım var, proje yapı dökümanlarım var. PR-reviewer agent'larım var. Linter'larım var. Değişiklikleri dikkatli review ediyorum. Bunların hepsi yardımcı oldu, bunlar olmasa kod tabanı çok daha kötü olurdu. Ama kod tabanı yine de olmasını istediğim yerde değil. Kod çalışıyor, ama optimal değil. Yakın bile değil.
Gerçekte ne buluyorum, anlatayım.
Her yerde DRY ihlali
Bir component, kod tabanında gerçek, yeniden kullanılabilir bir şey olarak yaşıyor. Birkaç yerde doğru şekilde kullanılıyor. Sonra başka bir dosyada aynı arayüz inline olarak yeniden yazılmış. Sonra üçüncü bir dosyada yine inline yazılmış ama biraz farklı şekilde.
Olması gereken şeylerin yarısı için tek bir doğruluk kaynağı yok. Yani o parçanın davranışını değiştirmek istediğimde, üç yerde değiştirmem gerekiyor. Birini atlarsam tutarsızlık kalıyor. Kod tabanı da, bundle da, hiçbir sebep yokken büyüyor. Bakım maliyeti kalıcı.
God file'lar
Üç ya da dört ayrı sorumluluğa bölünmesi gereken dosyalar, 400, 600, 800 satırlık tek dosya olarak yaşıyor. Birden fazla sorumluluk birbirine dolanmış. SOLID ihlalleri öyle bir ölçekte ki gelecekteki değişiklikler riskli — dosyanın bir kısmına dokunmak, başka bir şeyin bozulmadığından emin olmak için bütününü yeniden okumak demek. Bu tip kod tabanında çalışmış kimseye bunun neden kötü olduğunu açıklamam gerekmez. Dosyayı her açtığında maliyet katlanarak büyüyor.
Dead code
Bir şey denenmiş. Çalışmamış. Farklı bir yaklaşım bulunmuş. Eski yaklaşım dosyada kalmış, bazen yorum satırı içinde, bazen sadece hiçbir yerden referans almadan. Dead fonksiyonlar, dead component'lar, dead route'lar, dead import'lar. Her biri gürültü ekliyor. Her biri kodu okuyan bir sonraki kişinin "bu önemli mi" diye birkaç saniye düşünmesine sebep oluyor. Kod tabanı boyunca çarpıldığında, o saniyeler saatlerce kafa karışıklığına dönüşüyor.
Her yerde comment ve debug log
On satır kodun etrafına iki yüz satır yorum. Geliştirme sırasında eklenmiş ve hiç kaldırılmamış debug log'lar. Artık faydalı bir şey log'lamayan console.log çağrıları.
Bazı yorumlar bariz — "// kullanıcıyı getir" yazıyor, altında fetchUser() çağrısı var. Bazıları bayat, sonradan değişmiş kodu anlatıyor. Tek satır, ya da hiç olmaması gereken yerde tam paragraflık açıklama.
Her seviyede, her şiddette
İhlaller tek bir katmanla sınırlı değil. Bazıları kozmetik, can sıkıcı ama zararsız. Bazıları bakımı vuruyor, her değişiklik olması gerekenden daha pahalıya mal oluyor. Bazıları performansı vuruyor, tek bir çağrı yeterken tekrarlanan mantık çalışıyor, ya da aynı component üç farklı şekilde uygulandığı için aynı render işi birden çok kez yapılıyor.
Bütün güvenlik önlemlerine rağmen birikmiş olan bu. Kurallar detaylı. Review'lar yapıldı. Model yine de niyetten sapmanın bin küçük yolunu buldu.
Review neden yakalamadı
Bu kısımda dürüst olmak istiyorum.
Review'lar, hem AI'lı olanlar hem benim yaptıklarım, pull request bazında çalışıyor. Tek bir değişiklik içinde yanlış olanı yakalıyorlar. Yakalayamadıkları şey, ancak bir aylık birikimden sonra görünür hale gelen örüntü. Yeni bir inline component kendi PR'ında iyi görünüyor. Dört hafta sonraki beşincisi de kendi PR'ında iyi görünüyor. Kimse onu önceki dördüyle karşılaştırmıyor, çünkü code review sırasında kimse kod tabanına bir bütün olarak bakmıyor.
Bu AI'a özgü değil. Aynı şey insan geliştiricilerde de oluyor. AI sadece daha fazla, daha hızlı kod üretiyor, dolayısıyla birikim hızı daha yüksek ve sapma daha erken katlanıyor.
Örüntü problemleri görünür hale geldiğinde, örüntüler çoktan her yerde olmuş oluyor.
AI'ya temizletmeyi denedim
Bariz hamle, AI'ın yazdığını AI'ya düzelttirmekti. Denedim. İşe yaramadı.
Olan şu: Model uzun süre çalışırdı, değişiklik yaptığını iddia ederdi, sonunda bazı şeylerin gerçekten temizlendiğini, bazılarının hiç dokunulmadığını, bazılarının da farklı görünen ama aynı problemleri taşıyan kodla "temizlendiğini" görürdüm. İş yapılıyormuş gibi görünüyordu. Çıktı güvenilir değildi.
Bunun yapısal olduğunu düşünüyorum. Model bir örüntüye uyan yeni kod üretmekte iyi. Geniş, mevcut bir kod tabanını zihninde tutup neyi koruyacağı, neyi birleştireceği, neyi sileceği konusunda tutarlı kararlar vermekte kötü. Temizliğin gerektirdiği yargı, modellerin uzun bağlamlarda en kötü olduğu yargı.
Yani şimdi elle yapıyorum.
Manuel temizlik gerçekte ne demek
Plan, önümüzdeki birkaç hafta boyunca üç tur, frontend, backend, worker'lar. Her tur, ProductLog'un yol haritasında kendi başına bir madde.
Her dosya için:
Baştan sona oku
İhlalleri not et (tekrarlar, god file yapısı, dead code, fazla yorum ve log)
Tek tek düzelt
Testler hâlâ geçiyor mu, doğrula
Sonraki dosyaya geç
Burada kestirme yok. İçeri tek bir büyük refactor ile girmiyorum. Dosya dosya temizliyorum, bazı dosyaların bir saat süreceğini, bazılarının beş saat süreceğini kabul ederek.
Hedef mükemmellik değil. Başka bir yazılımcı açtığında savunmaya hazır olduğum bir hale getirmek. Şu an savunamam.
Yapmadığım şeyler
Çöpe atıp baştan başlamamak. Kod çalışıyor. Testler çalışıyor. Ürün yayında. Yeniden yazmak, gerçek ve hatası ayıklanmış kodu, henüz bulmadığım yeni hatalarla takas etmek. Mümkün en kötü takas.
AI'ı suçlamamak. Kodu ben yayına aldım. Pull request'leri ben onayladım. Model, yazmasına izin verdiğim şeyi yazdı. Kurallarım açıkça yeterince sıkı değildi, güvenlik önlemleri dosyalar arası örüntüleri yakalamıyordu. Bu benim tarafımda bir süreç başarısızlığı, araçların başarısızlığı değil.
Bir daha olmayacağına söz vermemek. Olacak. ProductLog'u inşa etmenin bir sonraki aşaması daha fazla AI tarafından yazılmış kod içerecek, ve o kodun bir kısmı aynı problemleri biriktirecek. Cevap AI kullanmayı bırakmak değil. Cevap, başka her tür bakımı nasıl planlıyorsan, temizlik geçişlerini de aynı şekilde düzenli olarak planlamak.
Bunu neden şimdi yazıyorum
Çünkü bu konuda dürüst yazı henüz pek yok. Bu konuda gördüğüm her diğer yaklaşım ya AI araçlarının panikli reddi ya da "doğru prompt'larsan AI ile geliştirme gayet iyi" şeklinde zaferci bir iddia. İkisi de yalan. Gerçek ortada bir yerde: AI faydalı, bir sürü işi hızlandırıyor, ve arkasında birinin temizlemesi gereken bir dağınıklık bırakıyor. Dağınıklık, kimsenin konuşmadığı kısım.
Temizliğe bu hafta başlıyorum. Üç pasın her biri bittiğinde, gerçekten ne bulduğum ve ne değiştirdiğimle ilgili bir takip yazısı yayınlayacağım. Şu an okuduğun yazı, iş başlamadan önceki saha raporu. Bir sonrakiler iş bittikten sonra olacak.
Yorumlar
Henüz yorum yok. İlk yorumu siz yapın!