Yapay zeka ile uygulamayi cikardiniz ama kodun durumu hic icinize sinmedi mi?

Akliniza bircok soru geliyor olabilir. Örnegin yük altinda stabil calisak mi? Paralel islemler veriler üzerinde hata izleri birakacak mi vs. Eger akliniza hicbir soru gelmiyor ve uygulamayi hemen canliya almak istiyorsaniz, bu yaziyi önce okuyun derim :)

Yazilim sadece kodun calisiyor olmasi ile bitmez. Localhost üzerinden tek bir kullanici ile test edilmis bir uygulama henüz hicbir seye hazir degildir. “Lokalde calisiyor ama” söylemlerinin ana sebebi de budur.

Yapay zekanin ürettigi kodu nasil güvenilir hale getirirsiniz? Burada benim gibi artik hic kod yazmadiginizi farz ediyorum. En alttan yukariya dogru atilmasi gereken adimlari siralayacagim.

## Birim Testleri
Her prompt icinde mutlaka “test etmeyi de unutma” ibaresi olmali. Yapay zeka olusturdugu her satir kod icin karsiligi olan bir birim testi yazacaktir.

## Entegrasyon Testleri
Bu testler entegre edimis bir sistem de (api + db) mevcut apilerin onay/kabul kriterlerine uygunlugunu test ederler. Bu tür testlerde yapay zeka tarafindan olusturulmalidir.

## Code Coverage
Mevcut testlerin ne oranda kodu kapsadigini anlayabilmek icin code coverage araclari ile ölcüm yapilmasi gerekmektedir. Ben yapay zekaya arada bir “kod kapsama seviyemiz” nedir diye soruyorum. Aldigim cevap genelde tüm sistem geneli icin gecerli olan %90 civarinda oluyor. Ayrica yapay zekadan mevcut testleri inceleyerek, hangi alanlar icin test yazilabilecegi analizini istiyorum. Bu sekilde zaten eksik olan tüm birim testleri ortaya cikmis oluyor.

## Onay/Kabul Testleri
Yazilimci bu noktadan itibaren uygulamayi test etme islemini kendi eline almak durumundadir, cünkü uygulamadan olan beklentilerin onay/kabul kriterleri ile net olarak ifade edilmeleri gerekmektedir. Burada yine given/when/then tarzi onay/kabul kriterlerinin yer aldigi tanimlamalar ihtiva eden test spec dosyalari olusturulur. Bu spec dosyalarinin test koduna dönüstürülmesi gerekmektedir. Burada yine yapay zekadan bu spec dosyalarindan test kodunu olusturacak minik bir test catisi olusturmasi istenir. Buradaki en büyük avantaj beklentilerin plain text ile ifade edilmesi lakin gerekli test kodunun olusturulma isleminin yapay zekaya birakilmadir. Test kodu dogasi itibari ile cok kirilgan bir yapiya sahiptir. Yazilimcinin test kodu yazmak yerine, beklentilerini ifade ettigi spec dosyalari olusturmasi, kirilgan olan test kodun bakim yükümlülügünü yapay zekaya aktarmaktadir.

## Test Harness
Uygulamanin karmasik bir kismi oldugunu düsünelim. Ben burada kendi calismamdan bir örnek vereyim. Cloud main backend ile müsteri isletmelerinde benzer yapida calisan custom onprem backend sistemlerinin karsilikli olarak verisel senkronize edilmesi gerekiyor. Onprem tarafindan örnegin olusan siparislerin düzenlli olarak cloud main backende aktarilmasi lazim. Ayni sekilde cloud main backend üzerinde yapilan tüm degisiklikler verinin ait oldugu onprem instance tespit edilerek SSE üzerinden oraya aktarilmasi gerekiyor. Burada cok karmasik bir replikasyon implementasyonu var.

Bu yapiyi onbinlerce siparis ve benzeri verilerle test edebilmek icin yapay zekadan bir test harness catisi olusturmasini istedim. Bu test harness bünyesinde onbinlerce siparisi otomatik olarak onprem üzerinde olusturuluyor ve akabinde bu verilerin cloud main backende intikal edip, etmedikleri test harness catisi tarafindan kontrol ediliyor. Bu bir yük testi degil, ben sadece onprem veritabaninda olusan her satirin dogru bir sekilde cloud main backend aktarilmasini test etmek istedim.

Bu sekilde karmasik uygulama özellikleriin yük altinda ne kadar dogru ve stabil calistiklari test edilebilir.

Eger cikan sonuclara güvenmiyorsaniz, benim yaptigim gibi yapay zekadan iki veritabanini sync log dosyasi isiginda kiyaslamasini isteyebilirsiinz. Gün sonunda hakikaet veritabanindaki veride yatmaktadir.

## Yük Testleri

Load ya da performance testing icin bircok arac mevcut. Bunun icin yapay zeka destegi almak gerekmiyor diyebilirsiinz, ama cikan sonuclarin analizi icin yine yapay zeka kullanilabilir.

## Uygulama Loglari

Tek bir log yerine her büyük islem icin bir log dosyasi tahsis edilebilr. Benim uygulamada örnegin sync islemleri, siparis transaksiyonlari, merge islemleri, sse watchdog icin ayri birer log dosyasi var. Buna paralel tüm loglarin toplandigi ana bir log dosyasi da mevcut, lakin bir hata bulmak icin bu dosyayi yapay zekaya verip, contexti patlatmanin ve tokenleri yakmanin bir anlami yok.

Bunun yerine hem hata aramak hem de implementasyonu check etmek icin kücük log dosyalarini yapay zeka ile paylasiyorum. Bu sekilde cok implementasyon hatasi kesfedebildim.

## Baska Modelleri Ile Cross-Check
Ben implementasyon icin opus-4.6, analiz icin opus-4.7 kulllaniyorum. 4.7 kod yazma konusunda biraz ucuk, ama analizleri cok iyi. Bu yüzden analizleri yüksek modelle yapip, implementasyon icin bir alt modeli kullaniyorum. Bu sekilde opus-4.6 nin aklina bile gelmeyenleri, eksikleri ya da hatalari opus-4.7 ile kesfetmek ve tamamlatmak münkün. Bu yüzden “güven iyidir, ama kontrol daha iyidir” demek geliyor icimden :)

## Sürekli Entegrasyon
Her commit ile kodun derlenmesi ve mevcut testlerin kosturulmasi gerekir. Eger test kirilmalari varsa, bu yapisal bir degisikligin yan etkilerinin olduguna isaret eder. Bu yüzden sürekli entegrasyon (continuous integration) kullanilmasi gereken önemli süreclerden birisidir. Tüm testlerin calisiyor olmasi yeni bir sürüm olusturmanin ilk adimi olmalidir.