Güvenli, küçük yinelemeler için 'değiştirmeyin' istem kalıbı
Bir küçük güncelleme yaparken kritik UI akışlarını, iş kurallarını ve kritik davranışları dondurarak başka hiçbir şeyin kaymamasını sağlamak için 'değiştirmeyin' istem kalbını öğrenin.
Küçük değişikliklerin neden sık sık başka yerleri bozduğunu\n\n“Küçük” bir değişiklik nadiren küçük kalır. Bir düğme etiketini düzeltmesini istersiniz ve birden sayfa düzeni kayar, bir form doğrulamayı durdurur veya bir ödeme adımı farklı davranır. Uygulamalar bağlı sistemlerdir. UI, mantık, veri ve entegrasyonlar birbirine dayanır.\n\nSık karşılaşılan nedenlerinden biri belirsiz sınırlar. Bir istek “kaydoluşu daha basit yap” derse, uygulayıcı (insan veya AI) “daha basit”in ne demek olduğunu tahmin etmek zorunda kalır. Tahmin, alanları kaldırma, adımları değiştirme, kopyayı ayarlama veya doğrulamayı yeniden yazma gibi ek düzenlemelere yol açar. Bir diğer neden de gizli bağımlılıklardır. Küçük bir UI değişikliği, beş başka ekranda kullanılan bir bileşeni yeniden kullanabilir.\n\nGüvenli bir yineleme, istenen tek iyileştirmeyi almanızı sağlar ve her şeyin geri kalanı etkili şekilde aynı kalır. Teknik olmayan bir ekip için bu, iş akışının kullanıcılara aynı hissetmesi, destek senaryolarının ürünle eşleşmesi ve raporlamanın anlamlı kalması demektir. Teknik bir ekip için bu, rotalarda, veri şekillerinde, API sözleşmelerinde veya kenar durum davranışlarında beklenmedik değişiklik olmaması anlamına gelir.\n\nBunu mümkün kılmak için, hareket etmeyecek olanları dondurmanız gerekir. Pratikte bu genellikle kritik akışları (kullanıcının geçtiği tam adımlar), UI ve UX ayrıntılarını (düzen, boşluk, etkileşim davranışı), iş kurallarını (fiyatlandırma, izinler, doğrulama), veri davranışını (ne saklanır ve ne zaman) ve entegrasyonları (analitik olayları, e-postalar, ödemeler, dış API'ler) içerir.\n\nBu “değiştirme” istem kalıbı, tahminleri ortadan kaldırıp değişiklik kapsamını daraltarak riski azaltır. Bu bir garanti değildir. Orijinal davranış kötü tanımlanmışsa, değişiklik paylaşılan bileşenleri etkiliyorsa veya sonucu doğrulamazsanız sapma olabilir. Hedef, daha az sürpriz ve daha hızlı onaydır.\n\n## “Değiştirme” istem kalıbı nedir\n\nDeğiştirme istem kalıbı, bir spesifik güncelleme isterken her şeyi net şekilde kilitlemenin basit bir yoludur. İstediğiniz tek değişikliği isimlendirirsiniz, sonra güncellemeden sonra aynı kalması gereken kısımların kısa bir dondurma listesini yazarsınız.\n\nBu önemlidir çünkü modeller genellikle yardımcı olmaya çalışırken dosyaları yeniden düzenleyebilir, yeniden adlandırabilir, yeniden organize edebilir veya mantığı “temizleyebilir”. Çıktı yine çalışsa bile bu ekstra değişiklikler hatalara, davranış değişikliklerine veya incelemeyi zorlaştırmaya yol açabilir.\n\nBu iki isteği karşılaştırın:\n\n“Ayarlar sayfasını geliştirin.” Bu tasarım değişikliklerine, yeni kopyaya, düzen kaymalarına ve mantık ayarlarına davetiye çıkarır.\n\n“Sadece 'Telefon' etiketini 'Cep telefonu' olarak değiştirin. Düzeni, doğrulamayı veya kaydetme davranışını değiştirmeyin.” Bu dar, test edilebilir ve daha güvenlidir.\n\nİyi bir dondurma listesi genellikle üç alanı kapsar:\n\n- Akışlar (kullanıcı yolculukları): kullanıcıların izlediği adımlar ve hangi ekranların göründüğü.\n- UI ve UX ayrıntıları: düzen, boşluk, alan sırası, düğme konumları ve etkileşimler.\n- İş kuralları ve veri davranışı: doğrulama kuralları, fiyat hesaplaması, izinler, veritabanı yazımları ve API yanıtları.\n\nBu kalıbı sohbet tabanlı bir yapı aracında (Koder.ai gibi) kullandığınızda, yinelemeler genellikle daha hızlı ilerler çünkü model tek düzenlemeye odaklanır ve istemeden geniş “iyileştirmeler” yapmaz.\n\n## Yeniden kullanılabilir temel şablon\n\nBu kalıp en iyi tek bir küçük kontrat gibi okunduğunda çalışır: bir net hedef, aynı kalması gerekenlerin dondurulduğu liste ve sonucu doğrulamak için birkaç kontrol.\n\nAşağıdaki şablonu kopyalayıp köşeli parantezleri doldurun. Kısa ama spesifik tutun.\n\n```text
Goal (one sentence):
- Change: [describe the one small change you want]
Context (1-3 sentences):
- Current behavior: [what happens today]
- Desired behavior: [what should happen after]
DO NOT CHANGE (must remain identical):
- Critical flows: [e.g., sign up -> checkout -> receipt stays the same]
- UI/UX that must not move: [e.g., button location, labels, navigation order]
- Business rules: [e.g., pricing, permissions, validation rules]
- Data behavior: [e.g., database schema, stored fields, migration rules]
Constraints (limit drift):
- Scope: [only this screen / only this endpoint / only this component]
- Files/modules (if known): [list a couple, or say “only touch what’s necessary”]
- No refactors: do not rename, reorganize folders, or change formatting beyond the touched lines
Acceptance checks (how I will verify):
- [a simple before/after check]
- [a user path that must still work]
- [a rule that must still hold]
Output requested:
- Provide a brief diff-style summary: what changed, where, and why
- Call out any risk or unclear requirement before implementing
SSS
"Değiştirme" istem kalıbını ne zaman kullanmalıyım?
Kullanmak istediğiniz tek bir değişiklik varsa ve başka hiçbir şeyin değişmemesini önemsiyorsanız bunu kullanın. Özellikle ödeme, kimlik doğrulama, faturalama veya küçük bir sapma gerçek kullanıcı sorunlarına yol açabilecek her akış için işe yarar.
Neden "küçük" değişiklikler uygulamanın ilgisiz kısımlarını bozar?
Çünkü bir uygulamanın parçaları bileşenleri, verileri ve kuralları paylaşır. Küçük bir UI düzenlemesi yeniden kullanılan bir bileşeni etkileyebilir; bu da başka ekranlarda yerleşimi değiştirir, doğrulamayı etkileyebilir veya API yüklerini gizlice değiştirebilir.
"Değiştirme" istem kalıbı tam olarak nedir?
Tek cümlelik bir hedef yazın, sonra değişiklikten sonra aynı kalması gerekenleri listeleyin. Anahtar, davranışı (akışlar, kurallar, veriler, entegrasyonlar) ve görünür UI ayrıntılarını dondurmaktır; sadece "bir şeyleri bozma" demek yeterli olmaz.
"DO NOT CHANGE" listesine ne eklemeliyim?
Kısa ama spesifik tutun: kritik akışlar, değişmemesi gereken UI/UX ayrıntıları, iş kuralları, veri davranışı ve entegrasyonlar. Değişmemesini istediğiniz şeyi isimlendiremiyorsanız model tahmin yapmak zorunda kalır ve tahmin hatalara yol açar.
Donma listesini çok geniş tutmam nasıl önlenir?
Korumak istediğiniz en küçük alanı dondurun. Örneğin, bir ekrandaki etiketi değiştiriyorsanız ödeme akışını tamamen dondurmayın; ancak o etiketin paylaşıldığı bileşenleri ve checkout akışını dondurmak mantıklı olabilir.
Kritik akışları nasıl, çok uzun bir doküman yazmadan dondururum?
Kullanıcı yolculuklarını adım adım isimlendirin ve "tamamlandı"nın ne olduğunu tanımlayın. Ardından geri butonu davranışı, hata mesajları, boş durumlar ve yenileme davranışı gibi yaygın kenar durumları ekleyin; bu şekilde akış, kullanıcıların en çok fark ettiği yerlerde aynı kalır.
Boşluk veya kopya değişiklikleri gibi UI sürüklenmesini nasıl önlerim?
Görünür yapıyı kesinleştirin: düzen (sütun/satır, başlık/altbilgi yerleşimi), boşluk kuralları (padding, gap, hizalama) ve bileşen davranışları (hover, disabled, loading spinners, hata mesajları). Değiştirmek istediğiniz tek metin dışında tüm kopyayı dondurun.
İş kuralları ve veri davranışını pratik şekilde nasıl dondururum?
Sözleşmeleri dondurun: istek/yanıt şekilleri, doğrulama kuralları, izinler, hesaplamalar ve ne zaman ne saklandığı. Hassas kurallar için bir sayısal örnek ekleyin ki uygulayıcıların yorum yapmasına gerek kalmasın.
Hiçbir şeyin değişmediğini doğrumanın en hızlı yolu nedir?
Hızlı koşabileceğiniz kabul kontrolleri isteyin ve kısa bir diff-benzeri özet talep edin. Sonra dondurduğunuz akışları uçtan uca kontrol edin, en az bir hata durumunu tetikleyin ve veri/entegrasyonların değişmediğini doğrulayın.
Bu, Koder.ai içinde en iyi nasıl çalışır?
Değişiklikten önce bir anlık görüntü alın, planlama geçişi yapıp kapsam ve donma listesini onaylayın, en küçük yaması uygulayın ve doğruladıktan sonra tekrar anlık görüntü alın. Bir şey saparsa geri almak tek adım olur.