Doğal dille kod yazdırmak: isteği doğrulanabilir bir işe dönüştür

Doğal dille kod yazdırırken en yararlı başlangıç, “bana bir uygulama yap” demek yerine tek bir davranışı tarif etmektir. Örneğin bir okuma listesindeki boş başlıkları reddeden küçük bir form düşün. İsteğin sonunda hangi girdinin kabul edileceği ve hangi mesajın görüleceği açık olursa hem üretilen kodu incelemek hem sonucu test etmek kolaylaşır. Buradaki yaklaşım bir modelin her zaman doğru kod yazacağı iddiası değildir; insan incelemesini daha somut hale getiren bir çalışma yöntemidir.

İsteği bir örnekle daralt

“Formu iyileştir” yerine şu davranışı tarif et: Başlık boşsa kayıt oluşturulmasın, alanın yanında anlaşılır bir mesaj gösterilsin ve kullanıcının yazdığı diğer bilgiler korunsun. Sonra iki örnek ekle. “Akşam okuması” geçerli olsun; yalnızca boşluk içeren başlık geçersiz sayılsın. Bu iki örnek, görünüşte küçük bir ayrıntının veri davranışını nasıl değiştirdiğini gösterir. Kenar durumunu belirtmediğinde araç kendi varsayımını yapabilir.

Mevcut projede hangi dilin, çatının ve form yaklaşımının kullanıldığını da incele. Yeni bir özellik, var olan yapının tamamını yeniden yazma gerekçesi değildir. Korunacak dosyaları, mevcut kullanıcı değişikliklerini ve gerçek servislere dokunulup dokunulmayacağını açıkça belirt. Bu sınırlar yalnızca güvenlik için değil, incelemenin anlaşılır kalması için de önemlidir. Tek bir değişikliğin sonucunu görmek, aynı anda beş mimari kararın etkisini ayırmaktan daha kolaydır.

Kabul koşulunu koddan önce yaz

Bir kontrol listesi üç soruya cevap versin: Normal girdide ne olur, yanlış girdide ne olur ve işlem yarıda kalırsa ne korunur? Örnek formda geçerli başlık kaydedilir, boş başlık reddedilir ve başarısız ağ isteğinde metin kaybolmaz. Bunları kullanıcı davranışı olarak yaz; uygulanacak fonksiyonun adını testin tek amacı haline getirme. Aynı davranışı farklı ama doğru bir uygulama da sağlayabilsin.

Henüz sunucu bağlantısı yoksa bunu ayrıca belirt. Tarayıcıda bir başarı mesajı göstermek, gerçek kaydın veritabanına yazıldığını kanıtlamaz. Prototipte hangi parçanın örnek olduğunu görünür bırak. Daha sonra gerçek servis bağlandığında ayrı bir uçtan uca kontrol yap: kaydı oluştur, bağımsız okumayla varlığını doğrula ve test için oluşturduğun kaydı tanımlı geri alma yöntemiyle temizle. Üretim verisini öğrenme deneyi olarak kullanma.

Değişiklik farkını oku

Üretilen yanıtın açıklamasına güvenmekle yetinme; değişen dosyaları incele. İstenen form düzenlemesi yanında paket listesi, yetki kuralı veya yayın ayarı değişmiş mi? Yeni bir ağ isteği eklenmişse hangi adrese hangi veriyi gönderdiğini araştır. Anlamadığın bir değişikliği yalnızca testler yeşil göründüğü için onaylama. Önce amacını ve beklenen etkisini açıklat, ardından kodun bu açıklamayla uyuşup uyuşmadığını kontrol et.

İnceleme çok büyüdüyse işi böl. Önce veri doğrulama, sonra hata görünümü, ardından erişilebilirlik gibi küçük adımlar seçebilirsin. Ancak bölmek, parçalar arasındaki ilişkiyi unutmak anlamına gelmesin. Form alanı hatayı gösterirken sunucu da aynı geçersiz girdiyi reddediyor mu, birlikte düşün. Kullanıcının tarayıcı kontrollerini atlayabileceğini kabul eden bir sınır tasarla. Görsel bir uyarı veri bütünlüğünün yerine geçmez.

Çalıştırılan kontrolü dürüstçe raporla

Son notta “tamamlandı” yerine doğrulanan davranışı anlat: Boş başlık reddedildi, geçerli örnek kaydedildi, ağ hatasında giriş korundu. Mobil tarayıcıyı veya gerçek servis bağlantısını test etmediysen bunu ayrı yaz. Böyle bir rapor, bir sonraki çalışmanın nereden başlayacağını gösterir. “Her şey çalışıyor” gibi geniş bir ifade ise kontrol edilmemiş alanları görünmez hale getirir.

Deney alanını ve kendi çalışma notlarını kendi küçük görevin için doldurabilirsin. Liste kod çalıştırmaz; örneklerini ve inceleme adımlarını düzenlemene yardım eder. Son olarak sorunu yeniden üretmek için gereken en küçük notu sakla: ortam, girdi, beklenen sonuç, gözlenen sonuç ve yapılan düzeltme. Bu not, yalnızca bugünkü hatayı çözmez; aynı davranışın sonraki sürümde bozulduğunu anlaman için de somut bir referans oluşturur.

İsteğin için küçük bir inceleme formu

Bir sonraki kod görevinden önce dört satır doldur: değişecek davranış, korunacak davranış, örnek girdi ve başarı kanıtı. Örneğin başlık doğrulaması eklenirken mevcut kayıtların sıralaması korunacaksa bunu açıkça yaz. Böylece aracın formu iyileştirirken liste davranışını da değiştirmesinin görev dışı olduğunu anlayabilirsin. Korunacak özelliklerin belirtilmesi, işi gereksiz büyütmeden sınırı görünür kılar. Her ayrıntıyı önceden tahmin etmek zorunda değilsin; sonucu değiştiren belirsizliği seçmen yeterlidir.

Değişiklik sonrasında aynı formun altına gözlenen sonucu ekle. Bir test çalıştırılamadıysa nedeni ve hangi davranışın belirsiz kaldığı ayrı dursun. “Muhtemelen doğrudur” ifadesini geçen kontrol gibi işaretleme. Başka bir kişi çalışmayı devraldığında bu iki satır, uzun bir sohbet geçmişinden daha hızlı yön verebilir. Geri alma yolunu da ekle: hangi dosya veya kayıt değişti, önceki sürüm nerede duruyor ve geri dönüşün beklenen etkisi ne? Bu alışkanlık, doğal dille verilen isteği somut ve incelenebilir bir geliştirme işine dönüştürür.

Kaynak

• GitHub: kod önerilerini sorumlu kullanma ve sınırlamalar

Bu yazıdaki form örneği açıklayıcı bir tasarımdır; gerçek bir kullanıcı projesinde ölçülmüş başarı veya hız artışı olarak sunulmaz.