AI'yi daha net gereksinimlere, modüler tasarımlara ve test edilebilir koda yönlendiren kanıtlanmış prompt kalıplarını öğrenin — refaktör ve yeniden yazım döngülerini azaltın.
Bu yazıda "daha temiz mimari" belirli bir çerçeve veya kusursuz bir diyagram anlamına gelmiyor. Sistemi kısa bir açıklamayla tarif edebilmek, değiştirdiğinizde alakasız kısımları kırmamak ve kahramanca test yapmadan davranışı doğrulayabilmek demek.
Açıklık demek sistemin amacı ve şeklinin kısa bir açıklamadan belirgin olması demektir: ne yapar, kim kullanır, hangi veriyi işler ve asla ne yapmamalı. AI destekli çalışmada açıklık ayrıca modelin gereksinimleri sizin onaylayacağınız şekilde tekrar ifade edebilmesi demektir.
Modülerlik demek sorumlulukların temiz sınırlara sahip olmasıdır. Her modülün bir işi, girdileri/çıktıları ve diğer modüllerin iç detayları hakkında asgari bilgi sahibi olması gerekir. AI kod ürettiğinde, modülerlik iş kurallarının controller, UI ve veri erişimi arasında yayılmasını engeller.
Test edilebilirlik demek "çalıştığını kanıtlamak" ucuz hale gelir. İş kuralları tam çalışan bir sistem olmadan test edilebilmeli ve entegrasyon testleri her kod yolunu değil bazı sözleşmeleri hedeflemelidir.
Yeniden yazımlar genellikle "kötü koda" değil eksik kısıtlara, belirsiz kapsama ve gizli varsayımlara dayanır. Örnekler:
AI bu başarısızlık modunu hızlandırabilir çünkü inandırıcı çıktı hızlıca üretebilir; bu da sarsak temellerin üzerine inşa etmeyi kolaylaştırır.
İlerideki kalıplar uyarlanabilir şablonlardır, sihirli promptlar değil. Gerçek hedefleri erken doğru konuşmaları zorlamaktır: kısıtları netleştirmek, seçenekleri karşılaştırmak, varsayımları belgelemek ve sözleşmeleri tanımlamak. Bu düşünmeyi atladığınızda model memnuniyetle boşlukları doldurur—ve bedelini sonra ödersiniz.
Bu kalıpları teslimat döngüsünün tamamında kullanacaksınız:
Eğer chat ile oluşturup yineleyerek bir "vibe-coding" iş akışı kullanıyorsanız, bu kontrol noktaları daha da önemli hale gelir. Örneğin, Koder.ai içinde bir "planlama modu" döngüsü çalıştırarak gereksinimleri ve sözleşmeleri React/Go/PostgreSQL kodu üretmeden önce kilitleyebilir, sonra varsayımlar değiştiğinde deneyleri güvenle yineleyebilmek için snapshot/rollback kullanabilirsiniz—her değişikliği yeniden yazıma dönüştürmeden.
Prompt kalıpları karar çalkantısını azalttıklarında en değerli hale gelir. Püf noktası, bunları kısa, tekrar edilebilir kontrol noktaları olarak kullanmaktır—kodlamadan önce, tasarım sırasında ve inceleme esnasında—böylece AI yeniden kullanılabilir artefaktlar üretir, üzerinde ayıklamanız gereken ekstra metin değil.
Kodlamadan önce: hedefleri, kullanıcıları, kısıtları ve başarı metriklerini onaylamak için bir "hizalama" döngüsü çalıştırın.
Tasarım sırasında: açık takasları zorlayan kalıplar kullanın (alternatifler, riskler, veri sınırları) ve sonra implementasyona geçin.
İnceleme sırasında: kontrol listesi tarzında bir prompt kullanarak boşlukları (köşe durumları, izleme, güvenlik, performans) değişiklikler hala ucuzken yakalayın.
Küçük, tutarlı bir giriş paketi ile daha iyi çıktı alırsınız:
Bir şeyi bilmiyorsanız, bunu açıkça söyleyin ve modelden varsayımları listelemesini isteyin.
"Tasarımı açıkla" demek yerine, dokümanlara veya ticket'lara yapıştırabileceğiniz artefaktlar isteyin:
10–15 dakikalık döngüler yapın: prompt → göz at → sıkıştır. Her seferinde kabul kriterleri dahil edin (tasarımın kabul edilebilmesi için nelerin doğru olması gerektiği) ve modelden bunlara karşı kendi çıktısını kontrol etmesini isteyin. Bu süreç sonsuz yeniden tasarıma dönüşmesini engeller ve sonraki kalıpları hızlıca uygulamayı sağlar.
Çoğu "mimari yeniden yazım" kötü diyagramlardan değil, yanlış (veya eksik) problemler için doğru şeyi inşa etmekten kaynaklanır. Bir LLM'i erken kullandığınızda, önce mimari istemeyin. Belirsizliği ortaya çıkarmasını isteyin.
Modeli bir gereksinim görüşmecisi gibi kullanın. Amacınız bileşenleri seçmeden, veritabanı seçmeden veya API'lara karar vermeden önce onaylayabileceğiniz kısa, önceliklendirilen bir spesifikasyon almaktır.
İşte kopyala-yapıştır şablonu:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
(Üstteki kod bloğu aynen korunmalı; içerik değişmedi.)
Soruların karar vermeyi zorlayacak şekilde olması (genel "daha fazla bilgi ver" türü değil) ve must-have listesinin gerçekten zaman çizelgenizde bitirilebilecek öğeler içermesi gerekir.
"10 madde"lik tekrar ifadeyi bir kontrat gibi kullanın: ticket/PRD'ye yapıştırın, paydaşlardan hızlıca evet/hayır alın ve ancak o zaman mimariye geçin. Bu adım en yaygın geç refaktör nedenini önler: gerçekte gerekli olmayan özellikleri inşa etmek.
Tool'larla başlamaya ("Event sourcing kullanalım mı?") başladığınızda genellikle kullanıcı için değil mimari için tasarım yaparsınız. Temiz yapıya daha hızlı ulaşmak için AI'dan önce kullanıcı yolculuklarını düz metinle tarif etmesini isteyin, sonra bu yolculukları bileşenlere, verilere ve API'lara çevirin.
Kopyala-yapıştır başlangıcı olarak kullanın:
Sonra isteyin:
“Her eylem için adım adım akışı düz metin halinde tanımla.”
“Basit bir durum diyagramı veya durum listesi ver (örn. Draft → Submitted → Approved → Archived).”
“Mutluluk dışı senaryoları listele: zaman aşımı, yeniden deneme, çoğaltılmış istekler, iptaller ve geçersiz girdiler.”
Akışlar netleştikten sonra AI'dan bunları teknik kararlara eşlemesini isteyin:
Ancak o zaman akış adımlarına doğrudan bağlı bir mimari taslağı (servisler/modüller, sınırlar ve sorumluluklar) isteyin.
AI'dan her yolculuğu şu biçimde kabul kriterlerine dönüştürmesini isteyin:
Bu kalıp, mimarinin teknoloji varsayımlarından değil kullanıcı davranışından büyümesini sağlar ve yeniden yazımları azaltır.
Çoğu mimari yeniden işleme "kötü tasarım" yüzünden değil, yanlış çıkan gizli varsayımlar yüzündendir. Bir LLM'e mimari sorduğunuzda, boşlukları makul tahminlerle doldurur. Varsayım günlüğü bu tahminleri erken görünür kılar, değişiklik ucuzken.
Hedefiniz sağladığınız gerçekler ile modelin uydurduğu varsayımlar arasında temiz bir ayrım zorlamak.
Bu prompt kalıbını kullanın:
Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
Kısa tutun ki insanlar gerçekten kullansın:
Modelin kritik noktalarını söylettirin:
Bu kalıp mimariyi koşullu kararlara dönüştürür. Sadece bir diyagram değil—hangi noktaların doğrulanmadan commit edilmemesi gerektiğinin bir haritasını alırsınız.
AI araçları tek bir "en iyi" tasarım üretmede iyi ama genellikle bu ilk mantıklı seçenekten ibarettir. Daha temiz bir mimari genellikle erkenden karşılaştırma yapıldığında ortaya çıkar; değişiklikler ucuzken bunu zorlayın.
Erken çoklu mimariler ve yapılandırılmış bir takas tablosu isteyen bir prompt kullanın:
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
(Kod bloğu olduğu gibi korunmalı.)
Bir karşılaştırma modelin (ve sizin) gizli varsayımlarını ortaya çıkarmaya zorlar: durum nerede tutuluyor, servisler nasıl iletişim kuruyor, neyin senkron olması gerekiyor ve ne geciktirilebilir. Kriter tablosu tartışmaları "monolith vs microservices" gibi görüşlere değil, aslında önem verdiğiniz şeylere sabitleyerek sonlandırır—hızlı gönderim, operasyonel yükü azaltma veya güvenilirliği artırma gibi.
"Bağlı" demeyi kabul etmeyin. Net bir öneri ve optimize ettiği spesifik kısıtları isteyin.
Ayrıca bu iterasyonda "ne inşa etmiyoruz"u da zorlayın. Örnekler: "Çok bölgeli failover yok", "Plugin sistemi yok", "Gerçek zamanlı bildirimler yok." Bu, mimarinin sessizce genişlemesini engeller ve kapsam daha sonra değiştiğinde sürpriz yeniden yazımları önler.
Çoğu yeniden yazım sınırlar belirsiz olduğu için olur: her şey her şeye dokunur ve küçük bir değişiklik tüm kod tabanına yayılır. Bu kalıp, kimse framework veya sınıf diyagramları tartışmadan önce net modül sahipliğini zorlayan promptlar kullanır.
AI'dan modülleri ve sorumlulukları tanımlamasını isteyin ve her modülde açıkça nelerin olmaması gerektiğini belirtin. Sonra arayüzler (girdiler/çıktılar) ve bağımlılık kuralları isteyin; yapı planı veya implementasyon detayları değil.
Yeni bir özellik tasarlarken veya karışık bir alanı refactor ederken bunu kullanın:
Modülleri listeleyin:
Her modül için sadece arayüzleri tanımlayın:
Bağımlılık kuralları:
Gelecekteki değişiklik testi: Bu muhtemel değişiklikler verildiğinde: <list 3>, hangi tek modülün her değişikliği absorbe etmesi gerektiğini ve nedenini gösterin.
Amacınız bir ekip arkadaşınıza bir dakikadan kısa sürede tarif edebileceğiniz modüller almak. Eğer AI "Utils" gibi bir modül öneriyorsa veya iş kurallarını controller'lara koyuyorsa geri itiniz: "Karar verme mantığını domain modülüne taşı ve adaptörleri ince tut."
Bittiğinde, değişikliklerin net bir evi olur ve bağımlılık kuralları istemeden coupling'i engeller, böylece yeni gereksinimler geldiğinde sınırlar dayanır.
Entegrasyon yeniden işleri genellikle "kötü kod" yüzünden değil, belirsiz sözleşmeler yüzündendir. Veri modeli ve API şekilleri geç kararlaştırılırsa her ekip (veya modül) boşlukları farklı doldurur ve sonraki sprintte uyumsuzlukları uzlaştırmak için zaman harcarsınız.
Sözleşmeleri framework, veritabanı veya mikroservis tartışmadan önce belirleyin. Net bir sözleşme UI, backend ve veri boru hatlarını hizalayan ortak referans olur.
AI asistanınızla erken bu promptu kullanın:
Ardından hemen şunu isteyin:
Prose değil, somut artefaktlar isteyin. Örnek:
Subscription
Ve bir API taslağı:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
(Kod blokları olduğu gibi korunmalı.)
AI'dan şu tür kurallar belirtmesini isteyin: "Yalnızca alan eklemek versiyon artışı gerektirmez; yeniden adlandırma /v2 gerektirir; istemciler bilinmeyen alanları yok saymalıdır." Bu adım sessizce bozucu değişiklikleri ve ardından gelecek yeniden yazımları engeller.
Mimari, "happy path" tasarımları gerçek trafik, güvensiz bağımlılıklar ve beklenmeyen kullanıcı davranışı ile karşılaşınca yeniden yazılır. Bu kalıp güvenilirliği tasarım çıktısı olarak açık hale getirir, sonradan panik yapmayı azaltır.
Seçtiğiniz mimari tanımıyla bunu kullanın:
List failure modes; propose mitigations; define observability signals.
For each failure mode:
- What triggers it?
- User impact (what the user experiences)
- Mitigation (design + operational)
- Retries, idempotency, rate limits, timeouts considerations
- Observability: logs/metrics/traces + alert thresholds
Başarısız olabilecek arayüzleri isimlendirmekle başlayın: harici API'ler, veritabanı, kuyruklar, auth sağlayıcı ve arka plan işleri. Sonra somut kararlar isteyin:
Promptu şu satırla bitirin: "2 dakikada gözden geçirebileceğimiz basit bir kontrol listesi döndür." İyi bir kontrol listesi şunları içerir: bağımlılık timeout'ları ayarlı, retry'ler sınırlı, idempotency create/charge işlemleri için uygulanmış, backpressure/rate limiting var, kademeli düşüş (graceful degradation) tanımlı.
Sadece sistem içlerine değil kullanıcı anlarına bağlı olaylar isteyin: "user_signed_up", "checkout_submitted", "payment_confirmed", "report_generated". Her biri için isteyin:
Bu, güvenilirliği koddan önce doğrulanabilir bir tasarım artefaktı haline getirir.
AI destekli tasarımın yeniden yazım yaratmasının yaygın yolu, çok erken "tam" bir mimari oluşturmayı teşvik etmesidir. Çözüm basit: planı en küçük kullanılabilir dilimle başlatmaya zorlayın—değer sağlayan, tasarımı test eden ve gelecekteki seçenekleri açık tutan bir dilim.
Çözüm gereksinimlerden hızlı genişliyorsa bunu kullanın:
Template: "Propose the smallest usable slice; define success metrics; list follow-ups."
Modelden şu şekilde cevap vermesini isteyin:
İkinci bir talimat ekleyin: "Fazlı bir yol haritası ver: MVP → v1 → v2 ve her fazın hangi riski azalttığını açıkla." Bu, sonraki fikirleri görünür tutar ama ilk sürüme zorlamaz.
Örnek sonuçlar:
Bu kalıbın en güçlü satırı: "MVP için açıkça kapsam dışı olanları listele." Dışlamalar mimari kararı erken karmaşıklığa zorlamaz.
İyi dışlamalar örnekleri:
Son olarak: "MVP'yi ticket'lara çevir, her birine kabul kriterleri ve bağımlılıklar ekle." Bu netliği zorlar ve gizli coupling'i ortaya çıkarır.
Tipik ince bölüm bileşenleri:
İsterseniz modelden takımınızın formatında çıktı (ör. Jira-stili alanlar) üretmesini isteyebilirsiniz ve sonraki fazları ayrı backlog olarak tutabilirsiniz.
Mimarinin kaymasından kaçınmanın basit yolu, bir bileşen tasarlamadan önce testlerle netlik zorlamaktır. Bir LLM'e önce kabul testleri yazmasını söylediğinizde, davranışları, girdileri, çıktıları ve köşe durumlarını adlandırmak zorunda kalır. Bu eksik gereksinimleri ortaya çıkarır ve implementasyonu temiz modül sınırlarına iter.
Bir bileşen tasarımı yapmadan önce şu kapı prompt'unu kullanın:
Takip eden isteğiniz: "Testleri modül sorumluluğuna göre grupla (API katmanı, domain mantığı, kalıcılık, harici entegrasyonlar). Her grup için neyin mocklandığını ve neyin gerçek olduğunu belirt."
Bu, LLM'i her şeye dokunan karışık tasarımlardan uzaklaştırır. Eğer entegrasyon testlerinin nerede başlayıp bittiğini açıklayamıyorsa, muhtemelen mimari henüz net değildir.
İsteyin: "Test veri planı öner: fixtures vs factories, köşe durumları nasıl üretilecek ve testleri deterministik tutma stratejisi. Hangi bağımlılıkların in-memory fake ile çalıştırılabileceğini ve hangilerinin CI'de gerçek servis gerektirdiğini listele."
Çoğu zaman "basit" görünen bir özellik aslında bir kontrat, seed veri seti veya sabit ID'ler gerektirir—bunu şimdi bulmak yeniden yazımdan daha iyidir.
Hafif bir kontrol listesi ile bitirin:
Tasarım incelemeleri sadece kod mevcutken olmamalı. AI ile mimari taslağınıza (birkaç paragraf veya sözlü diyagram bile olsa) bir "pre-mortem" incelemesi çalıştırıp, yeniden yazımlara dönüşmeden önce somut zayıflıkları alabilirsiniz.
Keskin bir eleştirmen tutumu ile başlayın ve kesinlik zorlayın:
Prompt: "Act as a reviewer; list risks, inconsistencies, and missing details in this design. Be concrete. If you can't evaluate something, say what information is missing."
Tasarım özetinizi, kısıtları (bütçe, zaman çizelgesi, ekip yetenekleri) ve herhangi bir fonksiyonel olmayan gereksinimi (gecikme, kullanılabilirlik, uyumluluk) yapıştırın.
Geri bildirim belirsiz olduğunda inceleme başarısız olur. Öncelikli düzeltme listesini isteyin:
Prompt: "Give me a prioritized punch list. For each item: severity (Blocker/High/Medium/Low), why it matters, suggested fix, and the smallest validation step."
Bu, tartışma yerine karar-almaya hazır görevler üretir.
Yarar sağlayan bir zorlayıcı: basit bir puanlama:
Prompt: "Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?"
Amaç hassasiyet değil; en yeniden yazım eğilimli varsayımları ortaya çıkarmaktır.
Son olarak incelemeyi kapsam genişletmeye dönüştürmemek için:
Prompt: "Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts."
Bu kalıbı her yinelemede tekrarlarsanız, mimariniz küçük, geri alınabilir adımlarla evrilir—büyük problemler ise erken yakalanır.
Bu paketi her özellik için tekrarlanabilir hafif bir iş akışı olarak kullanın. Amaç promptları zincirleyip her adımın bir sonraki adımın kullanacağı bir artefakt üretmesini sağlamaktır—kayıp bağlamı ve sürpriz yeniden yazımları azaltır.
Pratikte ekipler bu zinciri bir "özellik tarifi" olarak uygular. Eğer Koder.ai ile inşa ediyorsanız, aynı yapı sohbet tabanlı bir build sürecine kolayca uyum sağlar: artefaktları bir yerde saklayın, ilk çalışan dilimi üretin, sonra snapshotlarla deneyler geri alınabilir kalsın. MVP hazır olduğunda kaynak kodu dışa aktarabilir veya deploy/host edebilirsiniz—AI destekli teslimat hızı isterken tek bir ortama kilitlenmemeniz için faydalıdır.
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
(Kod blokları ve şablonlar olduğu gibi korunmalıdır.)
Eğer daha derin bir eşlik isterseniz, ilgili blog başlığını ve fiyatlandırma sayfasını kendi değerlendirme adımlarınızda inceleyebilirsiniz.","output_format":"json","source_language":"en","target_language":"tr"
"Daha temiz mimari" burada şu anlama gelir:
AI destekli çalışmada ayrıca modelin gereksinimleri sizin onaylayacağınız şekilde tekrar ifade edebilmesi gerekir.
AI etkileyici kod ve tasarım üretebildiği için, eksik kısıtlar ve gizli varsayımlar üzerine inşa etmek kolaylaşır. Bu hız şu gibi yeniden yazım tetikleyicilerini büyütebilir:
Çözüm "daha az AI" değil—promptları kullanarak kısıtları, kontratları ve varsayımları baştan açığa çıkarmaktır.
Kısa, tekrar edilebilir kontrol noktaları olarak kullanın; amaç kullanılabilir çıktı üretmek, gereksiz metin değil:
10–15 dakikalık turlarla çalışın: prompt → gözden geçir → sıkıştır. Her seferinde kabul kriterlerine karşı kontrol edin.
Küçük, tutarlı bir giriş paketi getirin:
Bir şey bilinmiyorsa, bunu açıkça belirtin ve modelden varsayımları listelemesini isteyin.
Belgeler, ticket veya PR'lara yapıştırabileceğiniz artefaktları isteyin:
Bu, AI çıktısını eyleme geçirilebilir kılar ve "kayıp bağlam" nedeniyle oluşan yeniden işleri azaltır.
Modeli bir gereksinim mülakatçısı gibi kullanın. Yaptırın:
Roller ve eylemlerle başlayın; sonra şunu isteyin:
Akışlar netleştikten sonra doğrulama vs iş kurallarının nerede olması gerektiği, idempotency gereksinimleri ve hangi verinin saklanıp hangisinin türetilmesi gerektiği gibi kararlara geçin. Sonra akışları test edilebilir Given/When/Then kabul kriterlerine dönüştürün.
LLM'ler boşlukları makul varsayımlarla doldurur; bu yüzden sağlanan gerçeklerle modelin çıkardığı varsayımları ayrıştırmak gerekir. İsteyin:
Ayrıca "cevabınızı ne değiştirir?" tetikleyicilerini isteyin (ör. kullanıcı hacmi, gecikme hedefleri, uyumluluk ihtiyaçları) ki tasarım koşullu hale gelsin ve yeniden yazım riski düşsün.
Modeli birden çok mimari önermeye zorlayın ve yapılandırılmış bir takas tablosu isteyin:
Karşılaştırma, modelin ve sizin gizli varsayımları gözler önüne sermesini sağlar; kriter tablosu da kararı neye göre verdiğinizi sabitler.
Sözleşme-öncelikli yaklaşım, veri şekillerini ve uyumluluk kurallarını baştan netleştirerek entegrasyon yeniden işlerini azaltır. İsteyin:
/v2 gerektirir; istemciler bilinmeyen alanları görmezden gelmeli)UI, backend ve entegrasyonlar aynı kontrat artefaktını paylaştığında, sonraki sprintlerde uyumsuz varsayımları uzlaştırmakla geçirilen zaman azalır.
Bu 10 maddelik tekrar, tasarımdan önce paydaşlarla hızlıca onaylanacak bir kontrat gibi davranmalıdır.