Yazılım Mühendisi Olmadan Üretime Kod Göndermek: Harness Kaliteyi Nasıl Koruyor?

Yazılım geliştirme ekiplerinde kaliteyi koruyan en kritik unsur, genellikle mühendislerin yaptığı kod incelemeleridir. Peki ya mühendis olmayan bir ekip üyesi, üretim koduna doğrudan katkıda bulunabilseydi? airCloset’ın CTO’su Ryan Tsui’nin liderliğindeki bir proje, bu soruya oldukça etkileyici bir yanıt sunuyor. Üretim koduna doğrudan katkıda bulunabilen otomatikleştirilmiş bir sistem olan cortex, artık yalnızca hata düzeltmeleri değil, tam anlamıyla yeni özellikler de ekleyebiliyor.

Bu yenilik, yalnızca mühendis olmayanların katılımını artırmakla kalmıyor, aynı zamanda sürecin kalite standartlarını da koruyor. Peki bu nasıl mümkün oluyor? İşte cortex projesinin beşinci bölümünde, otomatik inceleme, self-healing ve kalite koruma mekanizmalarının nasıl çalıştığına dair detaylı bir inceleme.

Üretime Yönelik PR’ların Gerçek Boyutu: 1.742 Satırlık Bir Örnek

Bir ekip üyesi tarafından gönderilen ve 1.742 satırlık, 41 dosyalık bir PR, airCloset’ın internal dashboard uygulamasına yönelik önemli bir güncellemeyi içeriyordu. Başlıkta yer alan "PL dashboard ver.2", proje liderleri ve takım yöneticileri için çok daha gelişmiş bir görünürlük sunmayı hedefliyordu. Bu güncelleme, yalnızca veri tabanı sorgularından kullanıcı arayüzüne kadar tüm yazılım katmanlarını etkiliyordu.

Bu tür bir PR, genellikle deneyimli bir mühendis tarafından birkaç günlük çalışma gerektiren bir ölçekteydi. Ancak cortex sistemi, bu PR’nin sıfır insan müdahalesiyle üretime sunulmasını sağladı. Peki bu nasıl gerçekleşti?

• PR’nin açılması (1.742 satır, 41 dosya)
• Otomatik inceleme (1. tur): Ana bulgu olarak, izin kapsamında bir sorun tespit edildi. Farklı bölümlerden gelen verilere erişim sağlanması, dashboard’un temel amacına aykırıydı. Ayrıca bir dizi küçük sorun da tespit edildi.
• Yazar botunun müdahalesi (1. tur): İzin sorunu düzeltildi ve küçük sorunlar giderildi.
• Otomatik inceleme (2. tur): Kalan küçük sorunlar ve bir no-empty-function lint hatası tespit edildi.
• Yazar botunun müdahalesi (2. tur): Lint hatası giderildi.

Bu süreç, toplamda dört inceleme-tespit turu ve üç yazar botu müdahalesi ile tamamlandı. Sonunda, CI (Continuous Integration) testleri yeşil ışık yaktığında, AI tarafından onaylanan PR otomatik olarak üretime sunuldu. Üretime gönderilen kod, 56/56 paylaşılan tip kontrolleri, 2.284/2.284 API testleri, 1.113/1.113 web spesifikasyonu ve 0 lint hatası ile tamamen temizdi.

Otomatik İnceleme ve Self-Healing: Kaliteyi Korumanın Anahtarı

PR’nin ilk turunda tespit edilen izin sorunu, yalnızca teknik bir bulgu değildi. Bu tür bir sorun, üretimde fark edilmesi zor olabilecek ve kullanıcıları gereksiz bilgilerle boğan bir durum yaratabilirdi. cortex sistemi, bu sorunu otomatik olarak tespit ederek PR’nin tekrar gözden geçirilmesini sağladı. Bu, mühendis olmayan bir ekip üyesinin gönderdiği bir PR için oldukça kritik bir koruma mekanizmasıydı.

cortex’in otomatik inceleme süreci, yalnızca lint hatalarını değil, aynı zamanda mantıksal hatalardan kaynaklanan sorunları da tespit edebiliyor. Bu sayede, mühendis olmayan ekip üyeleri, kod yazma konusunda uzman olmasalar bile, üretim koduna katkıda bulunabiliyorlar. Otomatik inceleme sistemi, PR’nin içerdiği tüm katmanları (veri tabanı sorguları, API yolları, kullanıcı arayüzü bileşenleri vb.) analiz ederek, potansiyel sorunları erkenden tespit ediyor ve düzeltme sürecini başlatıyor.

Yeni Altyapı Kurmak vs. Mevcut Yığına Eklemeler: Sınırlar Nerededir?

cortex sistemi, yalnızca mevcut altyapıya eklemeler yapılmasını değil, aynı zamanda tamamen yeni altyapıların kurulmasını da destekliyor. Ancak bu iki durum arasında bazı önemli farklar bulunuyor. Mevcut altyapıya eklemeler yapmak, genellikle daha kontrollü ve risksiz bir süreçtir. Yeni altyapı kurmak ise daha fazla dikkat ve planlama gerektiriyor.

Örneğin, PR’nin ilk turunda tespit edilen izin sorunu, mevcut altyapının bir parçası olan izin yönetim sistemindeki bir eksiklikten kaynaklanıyordu. Bu sorun, otomatik inceleme sistemi tarafından tespit edilerek hızlı bir şekilde düzeltildi. Ancak, tamamen yeni bir altyapı kurmak söz konusu olduğunda, otomatik inceleme sistemi yalnızca temel kontrolleri yapabilir. Bu tür durumlarda, insan müdahalesi ve daha derin bir inceleme süreci gerekebilir.

Gelecekteki Hedefler: Tüketici Odaklı Hizmetlere Doğru

cortex projesinin beşinci bölümü, yalnızca internal sistemlere odaklanmıyor. Gelecekteki hedefler arasında, tüketici odaklı hizmetlere yönelik olarak cortex’in nasıl ölçeklendirileceği yer alıyor. Bu süreç, tamamen ayrı bir yazıda detaylandırılacak olsa da, temel olarak cortex’in otomatik kalite koruma mekanizmalarının nasıl genişletileceği üzerine odaklanıyor.

Bu yenilikçi yaklaşım, yalnızca yazılım geliştirme süreçlerini demokratikleştirmekle kalmıyor, aynı zamanda kalite standartlarını da yükseltiyor. Mühendis olmayan ekip üyelerinin üretim koduna katkıda bulunabilmesi, yalnızca işbirliğini artırmakla kalmıyor, aynı zamanda daha yenilikçi ve çeşitli çözümlerin ortaya çıkmasına da olanak tanıyor.