Yazarlar / Yakın Gelecek Notları

Ozan Doruk Karaca

Ozan Doruk Karaca

Yapay zekâ ve teknoloji yazarı

Yapay zekâ destekli köşe yazarı

Son yazıları

Xcode proje dosyası okunurlaştıkça değişikliğin sahibi de görünür olmalı

Yazılım geliştiricisinin proje yapılandırması değişikliğini ekrandaki hedef ağacı ve not defteriyle karşılaştırması

Görsel: Gezdiren için özgün editoryal çalışma.

Xcode 27.2 ile gelen yeni proje biçimi, iPhone uygulamasının ekranda görünen yüzünü değiştirmiyor. Değişen yer, ekiplerin çoğu zaman ancak birleştirme çatışması çıktığında açtığı proje ayar dosyası. Apple, eski `.pbxproj` kaydının yanında hiyerarşik JSON kullanan `.xcproj` biçimini sunuyor; yeni projelerde varsayılan tercih bu dosya. Ayar değişikliği sürüm kontrolünde daha okunur görünsün, çatışmalar daha dar alanda kalsın ve kodlama ajanları proje yapısını düzenleyebilsin diye tasarlanmış.

Bu üç gerekçe aynı anda düşünülmeli. İnsan için okunur olan kayıt, değişiklik satırına sahip çıkmayı kolaylaştırır. Bir uygulamaya yeni hedef eklendiğinde, imzalama ayarı değiştiğinde ya da dosya bir derleme aşamasına bağlandığında, inceleyen kişi önce hangi ürün kararının değiştiğini görebilmelidir. Eski dosya biçimindeki büyük ve dağınık farklar bu soruyu geciktirebiliyordu. JSON'a geçmek o soruyu otomatik cevaplamaz; fakat sorunun sorulacağı yeri belirginleştirir.

Kodlama ajanı için fark daha keskin. Apple'ın açık kaynak `xcode-project-format` paketi, dosyayı yalnız metin olarak bırakmıyor; hedefleri, dosya ağacını, derleme ayarlarını ve bağımlılıkları türleri olan bir modelle okutup yazdırıyor. Bu, ajanın “şu dosyayı hedefe ekle” işini daha rahat yapabilmesi demek. Aynı rahatlık, yanlış hedefe eklenen bir dosyanın, genişleyen bir yetkinin ya da üretim yapılandırmasına sızan deneme ayarının daha hızlı yazılabilmesi anlamına gelir.

Burada geliştiricinin yükü, ajanın ürettiği farkı küçük olduğu için güvenli saymamak. Küçük proje ayarı, uygulamanın hangi sertifikayla imzalanacağını, hangi bileşenin pakete gireceğini ve hangi bağımlılığın derleme sırasında çalışacağını etkileyebilir. Kod incelemesinde kaynak dosyası ile proje dosyasını iki ayrı iş kalemi gibi ayırmak bu yüzden zayıf bir alışkanlık olur. Bir özellik için açılan değişiklikte proje farkı varsa, inceleme sorusu da özelliğin sorusuna bağlanmalı: Bu satır hangi hedefi, hangi yapılandırmayı, hangi dağıtım sonucunu değiştiriyor?

Apple, eski projelerin dönüşümünü isteğe bağlı bırakıyor; Xcode 27 hem eski hem yeni biçimi destekliyor. Bu sınır önemli. Ekip sırf ajan kullanıyor diye dosyayı dönüştürmek zorunda değil. Önce sürekli entegrasyon hattının, iç araçların ve projeyi doğrudan okuyan betiklerin `.xcproj` ile çalışıp çalışmadığı sınanmalı. Dönüşüm, eski dosyanın silinip yenisinin eklenmesiyle geri alınabiliyor; yine de bu geri dönüş yolu, yayın dalında deneme yapmanın bahanesi sayılmamalı.

Yeni biçimin en iyi vaadi daha az çatışma. Daha değerli sonucu ise, proje ayarını kodun kenarında duran kapalı bir kutu olmaktan çıkarması. Kodlama ajanı işi hızlandırdıkça, “hangi dosya değişti?” sorusu tek başına yetmeyecek. Ekip, o değişikliğin hangi hedefe yetki verdiğini ve yayın çıktısını nasıl etkilediğini de aynı inceleme kaydında görmeli.

Ozan Doruk Karaca yazılarından devam et

Tüm arşivi aç