İlk hafta kimse itiraz etmez. Ön yüz ekibi beklemek istemez; elle yazılmış birkaç örnek gövdeyle başlar ve ekranlar hızla çıkar.
İkinci hafta da sorun görünmez. Üçüncüde de. Sahte veri, projenin en sessiz teknik borcu: her gün biraz büyür ve faizini bir kerede öder.
Ödeme günü entegrasyonun son haftasıdır. Gerçek alan adları, dolgu karakterleri, boş gelen alanlar ve hata gövdeleri o hafta görünür. Ekran tasarımı bitmiştir, testler yazılmıştır; sözleşmedeki her değişiklik artık yeniden çalışma demektir.
iDataView tanımındaki gerçek alan üst verisi
Oysa gerçek alan bilgisi projenin ilk gününde masadaydı. Bir iDataView tanımı, kaynak nesneyi seçtiğiniz anda SAP üst verisinden alan adını, referans alanını, veri tipini, uzunluğunu, ondalık basamağını ve dönüşüm çıkışını rapor tasarımına alır. Dile bağlı alan metinleri de aynı tanımın içinde durur.
Bu liste sahte veriden iki bakımdan farklı: adlar ve tipler uydurulmuş değil, kaynağın kendisinden geliyor; uzunluk ve zorunluluk bilgisi de aynı yerden. Tanımı gerçek kaynağa karşı çalıştırdığınızda kontrollü bir örnek sonuç alırsınız ve boş değerler gerçekten boş gelir.
Tanım giden servis olarak yayımlandığında aynı nesne JSON veya XML döndürür. Ön yüz ekibi böylece ilk günden gerçek alan adlarıyla çalışır ve iki ekip aynı çıktıya bakarak konuşur.
Bugün yapabileceğiniz bir karşılaştırma var: ön yüz ekibinin elindeki sahte gövdeyi ve aynı nesnenin servis yanıtını yan yana koyun. Alan adları, uzunluklar ve boş değer davranışı kaç yerde ayrışıyorsa, son haftada konuşulacak madde sayısı da o kadar.
Ön yüz sözleşmesine yazılacak beş satır
- Alan adı, tipi, uzunluğu ve zorunlu olup olmadığı.
- Boş değerin nasıl geldiği: alan hiç gelmiyor mu, boş dize mi, sıfır mı?
- Sabit parametreler ile çağrı anında değiştirilebilenler.
- Kayıt sınırı ve sayfalama beklentisi.
- Hata gövdeleri: yetki hatası, kaynak hatası ve zaman aşımı ayrı ayrı.
Uygulama içi yanıtların ortak bir zarfla üretildiğini de hesaba katın: hata ve başarı üst verisini taşıyan ApiResponse zarfı ile verinin kendisi ayrı şeylerdir. Ön yüz ekibi hangisini okuyacağını baştan bilmezse, ilk hata yanıtında boş ekran çıkar.
Test çıktısı üretim verisinin yerine geçmez
Bir noktayı abartmamak gerekir. Test çıktısı üretim verisinin bütün istisnalarını temsil etmez; özel karakterler, uzun metinler ve beklenmedik birim kombinasyonları çoğunlukla yalnız gerçek veride görünür. Sözleşmeyi sürümlemek ve ilk gerçek veri turundan sonra bir kez daha okumak, bu yüzden en ucuz sigorta.
Süre vaadi de vermiyoruz. “On beş dakikada API” gibi ifadeler ölçülmüş bir sonuç değil. İddia daha sade: ön yüz ekibinin elindeki alan listesi, kaynağın kendi üst verisinden gelir.
Ön yüz sprintini başlatmadan önce yarım saatlik bir masa kurun: bir iDataView tanımından alan listesini çıkarın, hata gövdelerini yanına yazın ve bunu sözleşmenin birinci sürümü olarak kayda geçirin. O masayı birlikte kurmak isterseniz haber verin.