Yapay Zeka ile Hızlı CRUD Uygulamaları: Panolar ve Yönetici Panelleri, Gereksiz Karmaşa Olmadan

Ne İnşa Ediyorsunuz (ve “Aşırı Mühendislik Yok” Ne Anlama Geliyor)

CRUD uygulamaları, panolar ve yönetici panelleri bir ürünün “arka ofisi”dir: verinin oluşturulduğu, gözden geçirildiği, düzeltildiği ve raporlandığı yer. Genellikle gösterişli bir UX gerekmez—ancak güvenilir, gezinmesi kolay ve iş değiştiğinde hızla değiştirilebilir olmaları gerekir.

Bu araçlar genelde neleri içerir

Çoğu yönetici tarzı uygulama birkaç tekrarlanabilir parçaya indirgenir:

• Listeler ve filtreler (arama, sıralama, sayfalandırma)
• Detay görünümleri (tek bir kayıt için salt-okunur sayfalar)
• Oluştur/düzenle formları (doğrulama ve makul varsayılanlarla)
• Temel iş akışları (onay/red, atama, durum değişiklikleri)
• Panolar (birkaç grafik, sayımlar ve "dikkat gerektiren" tablolar)
• Roller/izinler (kim görüntüleyebilir vs. düzenleyebilir vs. silebilir)

İç araçlar veya bir MVP yönetici arayüzü inşa ediyorsanız, bu parçaları doğru yapmak ileri düzey mimariden daha değerlidir.

AI en çok nerede yardımcı olur

AI, tekrarlı işler için hızlı ve tutarlı bir asistan gibi kullanıldığında en güçlüdür:

• Boilerplate iskeleti: CRUD route'ları, controller'lar, bileşenler ve formlar
• Tekrarlayan desenler: liste → detay → düzen ekranları her seferinde aynı şekilde üretilir
• UI metinleri: etiketler, boş durumlar, yardımcı metinler ve onay mesajları
• Kenar durum hatırlatmaları: “Sayfalandırmayı eklediniz mi?” “Silme işlemleri soft delete mi?”

AI, “tüm sistemi tasarla” konusunda daha az güvenilirdir—bu yüzden ona net bir yapı verip eksik kalanları doldurmasını sağlamak daha iyi sonuç verir.

Pratikte “aşırı mühendislik yok” ne demek

"Aşırı mühendislik yok" şu taahhüttür: güvenli ve sürdürülebilir olan en basit sürümü teslim et:

• Derin soyutlama katmanları ve özel framework'ler yerine varsayılanları tercih edin.
• Bugünün akışları için inşa edin, varsayımsal gelecekteki akışlar için değil.
• Veriyi ve izinleri açık tutun, “zeki” değil.
• Değişiklik hızını optimize edin: yeni bir alan veya durum küçük, öngörülebilir bir düzenleme olmalı.

Bu yaklaşım kimler için uygun

Bu yaklaşım küçük ekipler, kurucular ve ürün ekipleri için uygundur; dahili araçlar, operasyon konsolları ve MVP yönetici panelleri gönderirken—özellikle bu hafta çalışır bir şey gerektiğinde, yıllarca bakımını yapacağınız bir platform değil.

Sıkı Bir Kapsam Tanımlayın: Varlıklar, Kullanıcılar ve Birkaç Temel Akış

Hız, ne yapmayacağını seçmekten gelir. AI'den bir şey üretmesini istemeden önce, yöneticinin gerçekten yapması gereken işe uyan dar bir kapsam kilitleyin.

1) 3–5 temel varlığı seçin

Uygulamanızın yönetmesi gereken en küçük "şey" kümesiyle başlayın. Her varlık için, neden var olduğunu ve kimlerin dokunduğunu bir cümleyle yazın.

Örnek (kendi alanınıza göre değiştirin):

• Customer — işin hizmet verdiği kişi
• Order — müşterilerin satın aldığı şey
• Product — satılabilecek ürün
• Invoice — faturalandırılan kalem
• User — yöneticiye erişebilen kişi

Sonra sadece gerekli ilişkileri not edin (ör. Order → Customer, Order → çoklu Product). AuditEvent, FeatureFlag veya WorkflowStep gibi “gelecekte gerekebilir” varlıklarını ilk günde gerekmedikçe eklemeyin.

2) Olmazsa olmaz yönetici görevlerini listeleyin

Yönetici panelleri ekranlardan çok eylemlerle ilgilidir. Projeye değer katan birkaç görevi yazın:

• Kayıt oluştur/düzenle
• İnceleme ve onay (veya reddetme)
• Arama ve filtreleme
• Finans/operasyon için CSV dışa aktarma
• İstisnaları çözme (iade, iptal, yeniden senkronizasyon)

Bir görev gerçek haftalık bir operasyona denk gelmiyorsa, muhtemelen isteğe bağlıdır.

3) Başarı metriklerini tanımlayın

İlerlemenizi ölçmek için basit hedefler koyun:

• İlk ekrana ulaşma süresi (ör. 30–60 dakika)
• İlk deploy süresi (aynı gün)
• İlk gerçek görevin tamamlanma süresi (ör. bir siparişi onaylama)

4) "Şimdi değil" listesi oluşturun

Bilerek atladığınız öğeleri yazın: çok bölgeli ölçekleme, özel rapor oluşturucu, gösterişli rol hiyerarjileri, event sourcing, eklenti sistemleri. Bunu /docs/scope.md içinde tutun ki herkes (ve AI istemleriniz) aynı hizada kalsın.

Basit Bir Stack Seçin ve Varsayılanlara Sadık Kalın

Hız, öngörülebilirlikten gelir. En hızlı CRUD uygulamaları, zaten nasıl deploy edileceğini, debug edileceğini ve işe alınacağını bildiğiniz “sıkıcı” teknoloji üzerine kuruludur.

Güvenle deploy edebileceğiniz sıkıcı bir stack seçin

Tek bir kanıtlanmış kombinasyonu seçin ve proje boyunca ona bağlı kalın:

• Backend: Rails, Django, Laravel, Express/Nest veya ASP.NET Core—ekibinizin düzenli olarak gönderdiği neyse.
• Veritabanı: Postgres (varsayılan tercih), yok eğer standartınız başka ise MySQL.
• Hosting: zaten kullandığınız platform (Render/Fly/Heroku/Vercel/AWS) ve üretime giden net bir yol.

Pratik bir kural: "Hello, auth + DB migration" uygulamasını bir saatin altında deploy edemiyorsanız, hızlı bir yönetim aracı için doğru stack değildir.

Eğer yığını tamamen bağlamayı atlamak isterseniz (özellikle dahili araçlar için), Koder.ai gibi bir vibe-coding platformu sohbetten çalışan bir temel üretebilir—genellikle React web uygulaması ile Go + PostgreSQL backend olarak—ve istediğiniz zaman kaynak kodu dışa aktarmanıza izin verir.

Özel framework'ler yerine scaffold'ları tercih edin

AI, yaygın konvansiyonları kullandığınızda boşlukları doldurmada mükemmeldir. Jeneratörlere ve varsayılanlara dayanarak daha hızlı ilerlersiniz:

• Çerçevenizin resmi auth, migration, ORM ve routing'ini kullanın.
• Kendi bileşen kütüphanenizi icat etmek yerine standart bir UI kiti (veya çerçevenin varsayılan yönetici araçları) kullanın.

Scaffold düz görünüyorsa sorun yok. Yönetici panelleri net ve stabil olduklarında başarılı olur, gösterişli olduklarında değil.

Karar: server-rendered mi yoksa SPA mı (becerilere göre)

• Server-rendered (Rails/Django/Laravel): CRUD, formlar, doğrulama ve izinler için en hızlısı—daha az parça.
• SPA (React/Vue + API): sadece ekip zaten güçlüyse ve gerçekten zengin istemci etkileşimine ihtiyacınız varsa seçin.

Şüphede server-rendered ile başlayın. Sonra küçük reaktif widget'lar ekleyebilirsiniz.

CRUD çalışana kadar entegrasyonları minimumda tutun

Erken eklentilerden kaçının (event bus'lar, mikroservisler, karmaşık kuyruklar, multi-tenant mimariler). CRUD omurgası stabil olduktan sonra entegrasyonlar daha kolay ve daha güvenlidir.

Ekran Üretmeden Önce Veriyi Modelleyin

AI'den temiz CRUD ekranları üretmesini istiyorsanız, önce verinizi tasarlayın. Ekranlar modelin sadece bir görünümüdür. Model muğlaksa, UI (ve üretilen kod) tutarsız olur: uyumsuz alan adları, kafa karıştırıcı filtreler ve "gizemli" ilişkiler.

Sayfalar yerine tablolar/collection'larla başlayın

Yönetici panelinizin yöneteceği temel varlıkları (ör. Customers, Orders, Products) yazın. Her varlık için, gerçekten yayınlamayı planladığınız birkaç ana akışı destekleyecek minimum alan setini belirleyin.

Yararlı bir kural: bir alan liste görünümünü, detay görünümünü, raporlamayı veya izinleri etkilemiyorsa, muhtemelen v1'de gerekli değildir.

Erken normalizasyonu aşırıya kaçırmayın

Normalizasyon faydalıdır, ancak her şeyi ayrı tablolara ayırmak çok erken yapılırsa sizi yavaşlatır ve üretilen formları çalışdırmayı zorlaştırır.

Basit tutun:

• Gerçekten ihtiyaç duyduğunuz yerde düz yabancı anahtarlar kullanın (ör. order.customerId).
• Birçok “mükemmel” tablo yerine az sayıda net tablo tercih edin.
• Tercih tablolarını (statüler, etiketler vb.) uygulama değerini kanıtladıktan sonra ekleyin.

Denetim alanlarını (audit fields) baştan planlayın

Yönetici araçları neredeyse her zaman temel izlenebilirlik ister. Başlangıçtan audit alanları ekleyin ki her üretilen ekran bunları tutarlı şekilde içersin:

• createdAt, updatedAt
• createdBy (ve isteğe bağlı updatedBy)

Bu, hesap verebilirlik, değişiklik incelemeleri ve basit hata ayıklama sağlar, karmaşık araçlar eklemeden.

AI'ye yardımcı olması için tutarlı adlandırma kullanın

AI çıktısı, şemanız tahmin edilebilir olduğunda daha temiz olur. Bir adlandırma stili seçin ve ona sadık kalın (örn. camelCase alanlar, tekil varlık isimleri).

Örneğin customerId mi yoksa customer_id mi olacağına karar verin—sonra her yerde aynı paterni uygulayın. Tutarlılık tek seferlik düzeltmeleri azaltır ve üretilen filtre, form ve doğrulama kurullarının doğal olarak hizalanmasını sağlar.

Tutarlı, Bakımı Kolay Kod Üreten İstemler Yazın

AI çok miktarda kod üretebilir—ancak tekrarlanabilir bir istem yapınız yoksa isimlendirme, doğrulama ve pattern'lerde tutarsızlıklarla sonuçlanırsınız. Hedef, AI'yı disiplinli bir ekip arkadaşı gibi davranmaya zorlamaktır: öngörülebilir, sınırlı ve tek plana bağlı.

Tekrar kullanılabilir bir “app brief” ile başlayın

Her üretim istemine yapıştırdığınız kısa bir belge oluşturun. Sabit tutun ve sürümleyin.

App brief içinde olmalı:

• Hedef: yönetici panelinin amacı (bir cümle)
• Kullanıcılar/roller: kim kullanır ve ne yapabilir
• Varlıklar: birkaç tablo/kaynak ve nasıl ilişkilendikleri
• Ana akışlar: önemli eylemler (örn. "sipariş oluştur, iade et, müşteri geçmişini görüntüle")

Bu, modelin her yeni ekran isterken ürünü yeniden icat etmesini durdurur.

Eğer sohbet bazlı bir oluşturucu kullanıyorsanız (örn. Koder.ai), bu brief projede bir "system prompt" gibi davranmalı: tek bir yerde tutun ve her ekranın aynı kısıtlar altında üretilmesini sağlayın.

Koddan önce dosya dosya bir plan talep edin

Herhangi bir şey üretmeden önce, AI'den somut bir hüman-plan isteyin: hangi dosyaların ekleneceği/değiştirileceği, her dosyanın içeriği ve yaptığı varsayımlar.

Bu plan bir kontrol noktası olur. Dosya listesi yanlış görünüyorsa (çok fazla soyutlama, ekstra framework'ler, istemediğiniz yeni klasörler), önce planı düzeltin—sonra kodu üretin.

Tutarlılığı zorlamak için kısıtlamalar ekleyin

Bakım yapılabilirlik kısıtlamalardan gelir, yaratıcılıktan değil. Aşağıdaki gibi kurallar ekleyin:

• Adlandırma: tekil vs çoğul, casing, route desenleri, bileşen isimleri
• Doğrulama: zorunlu alanlar, min/max, formatlar, sunucu tarafı hatalarının UI'da gösterilmesi
• Liste davranışı: sayfa boyutu, varsayılan sıralama, izin verilen filtreler, boş durumlar
• API şekli: response envelope'ları, hata formatı, ID tipi (UUID vs integer)

Her yerde “sıkıcı varsayılanları” açıkça belirtin ki her CRUD ekranı aynı sistemin parçası gibi olsun.

Prompt sürüklenmesini önlemek için karar değişiklik günlüğü tutun

Seçimler yaptıkça (örn. "kullanıcılar için soft delete", "ödeme sonrası siparişler düzenlenemez", "varsayılan sayfa boyutu 25"), bunları sürekli bir changelog'a yazın ve ilgili satırları gelecekteki istemlere yapıştırın.

Bu, erken ekranlarla sonraki ekranlar arasında ince tutarsızlıkların oluşmasını engellemenin en basit yoludur—üretime kadar fark edilmeden kalma riskini azaltır.

Pratik bir yapı üç yeniden kullanılabilir blok içerir: App Brief, Vazgeçilmez Kısıtlar ve Güncel Kararlar (Changelog). Bu, her istemi kısa, tekrarlanabilir ve yanlış yorumlamaya dirençli kılar.

Tekrarlanabilir Bir Desenle CRUD Ekranları Üretin

Hız tekrardan gelir, zekadan değil. CRUD'u ürünleştirilmiş bir desen gibi ele alın: her seferinde aynı ekranlar, aynı bileşenler, aynı davranışlar.

Bir varlıkla başlayın, uçtan uca bitirin

Tek bir "çekirdek" varlık seçin (örn. Orders, Customers, Tickets) ve önce tamamlanmış döngüyü üretin: list → detail → create → edit → delete. Beş varlığı yarıda üretmeyin. Tamamlanmış bir set geri kalanlar için konvansiyonlarınızı tanımlar.

Her seferinde aynı ekran desenini kullanın

Her varlık için tutarlı bir yapı kullanın:

• Liste sayfası: tablo + filtreler + birincil eylem ("Yeni …")
• Detay sayfası: salt-okunur özet + ilişkili öğeler + eylemler ("Düzenle", "Arşivle/Sil")
• Oluştur/Düzenle: modlu (create vs edit) ortak bir form bileşeni

Tablo sütunlarınızı standartlaştırın (örn. Ad/Başlık, Durum, Sahip, Güncellendi, Oluşturuldu) ve form bileşenlerinizi standartlaştırın (text input, select, date picker, textarea). Tutarlılık AI çıktısını gözden geçirmeyi ve kullanıcıların hızlıca adapte olmasını sağlar.

"Sıkıcı" durumları baştan inşa edin

CRUD ekranları gerçek koşulları ele aldığında profesyonel görünür:

• Boş durumlar: neyin eksik olduğunu açıklayın ve sonraki adımı sunun ("İlk öğenizi oluşturun…")
• Yüklenme durumları: iskelet/tablo placeholder'ları, devre dışı bırakılmış eylemler
• Hata mesajları: kullanıcı dostu özet + alan düzeyinde eyleme geçirilebilir hatalar

Bu durumlar tekrarlıdır—yani standartlaştırmak ve yeniden kullanmak için mükemmeldir.

Tekrar kullanılabilir bir istem şablonu

Generate CRUD UI for entity: <EntityName>.
Follow existing pattern:
1) List page: table columns <...>, filters <...>, pagination, empty/loading/error states.
2) Detail page: sections <...>, actions Edit/Delete with confirmation.
3) Create/Edit form: shared component, validation messages, submit/cancel behavior.
Use shared components: <Table>, <FormField>, <Select>, <Toast>.
Do not introduce new libraries.

İlk varlık doğru görünürse, aynı reçeteyi her yeni varlığa minimal varyasyonla uygulayın.

Karmaşıklık Katmadan Kimlik Doğrulama ve İzin Ekleyin

Auth ve izinler, “hızlı yönetici aracı”nın sessizce aylara yayılan bir projeye dönüşebildiği yerdir. Amaç basit: doğru kişilerin doğru ekranlara ve eylemlere erişmesini sağlamak—tüm bir güvenlik çerçevesini icat etmeden.

Üç rolle başlayın (rol şişliğine direnin)

Küçük bir rol modeli ile başlayın ve somut bir ihtiyaç çıkınca genişletin:

• Admin: kullanıcı/rol yönetimi dahil tam erişim
• Editor: kayıt oluşturma ve güncelleme yapabilir
• Viewer: salt-okunur erişim

Yeni bir rol istendiğinde sorun: bugün hangi tek ekran veya eylem engelleniyor? Çoğu zaman kayıt seviyesinde bir kural yeterli olur.

Önce route seviyesi, sonra kayıt seviyesi kuralları

İzinleri iki katmanda yapın:

1. Route seviyesi erişim: tüm bölümlere erişimi kapatın/açın (örn. /admin/users sadece Admin).
2. Kayıt seviyesi kuralları: bir sayfa içindeki neyin yapılabileceğini kısıtlayın (örn. Editor yalnızca kendi takımının kayıtlarını düzenleyebilir, ama silemez).

Kuralları açık ve veri modeline yakın tutun: "bu kaydı kim okuyabilir/güncelleyebilir/silebilir?" uzun istisna listelerinden daha iyidir.

Var olan bir auth sağlayıcısı kullanın

Şirketiniz zaten Google Workspace, Microsoft Entra ID, Okta, Auth0 veya benzeri kullanıyorsa, SSO entegre edin ve claim/group'ları üç rolünüze eşleyin. Özel parola depolama ve "kendi girişinizi inşa etme"den kaçının, zorunlu olmadıkça.

Önemli eylemleri denetleyin

Basit yönetici panelleri bile hassas olayları loglamalıdır:

• Silmeler (ve toplu silmeler)
• Rol değişiklikleri ve izin düzenlemeleri
• Veri dışa aktarımları

Kim yaptı, ne zaman, hangi hesaptan ve ne değişti saklayın. Hata ayıklama, uyumluluk ve gönül rahatlığı için paha biçilmezdir.

Gerçek Soruları Cevaplayan Panolar Oluşturun

İyi bir yönetici panosu karar aracıdır, “anasayfa” değildir. Fazla inşa etmenin en hızlı yolu veritabanınızın bildiği her şeyi görselleştirmeye çalışmaktır. Onun yerine, operatörün 30 saniyede yanıtlaması gereken birkaç soruyu yazın.

Eylem üreten küçük bir metrik seti seçin

5–8 kilit metrik hedefleyin; her biri bugün bir karar üretmeli (onayla, takip et, düzelt, araştır):

• Bugün oluşturulan yeni öğeler vs. geçen hafta
• İnceleme bekleyen öğeler
• Başarısız ödemeler / hata sayısı
• "Pending" durumda ortalama süre
• Hacme göre en çok yük olan sahipler/kuyruklar

Eğer bir metrik davranışı değiştirmiyorsa, o raporlama içindir—pano malzemesi değildir.

Önce filtreler, sonra görseller

Panolar dilimlenince “akıllı” görünür. Widget'lar için birkaç tutarlı filtre ekleyin:

• Tarih aralığı (Bugün / 7 gün / 30 gün / Özel)
• Durum (açık, beklemede, tamamlandı)
• Sahip (atanan, takım, bölge)

Varsayılanları mantıklı yapın (örn. son 7 gün) ve filtreleri yapışkan yapın ki kullanıcılar her ziyaretlerinde tekrar ayarlamasın.

Grafiklerden önce tablolar gönderin

Grafikler yardımcı olabilir ama ekstra çalışma gerektirir (agregasyon seçimleri, boş durumlar, eksen formatlama). Sıralanabilir bir tablo toplamda daha hızlı değer sunar:

• Sayı ile “Top 10” tablosu
• Kayıtlara hızlı bağlantılar içeren “Latest 20” tablosu

Eğer grafik ekleyecekseniz, bunları gönderme engeli yerine isteğe bağlı geliştirmeler yapın.

Dışa aktarmayı dikkatle ele alın

CSV dışa aktarma faydalıdır, ancak ayrıcalıklı bir işlem gibi davranın:

• Oluşturmadan önce izinleri kontrol edin
• Pano görünümündeki aynı filtreleri uygulayın
• Kim dışa aktardı ve ne zaman kaydedin

Daha fazla aşırı mühendislik tuzağından kaçınmak için /blog/common-overengineering-traps bölümüne bakın.

Koruyucu Önlemler: Doğrulama, Temel Güvenlik ve Güvenli Varsayılanlar

Hız bir kazanım ise ancak uygulama güvenli çalışıyorsa anlamlıdır. İyi haber: CRUD uygulamaları ve yönetici panelleri için küçük bir set koruyucu önlem çoğu gerçek dünya sorununu kapsar—çok ağır mimari eklemeden.

Doğrulama: UX için istemci, gerçeklik için sunucu

UI'da kullanıcıyı rahatlatmak için doğrulama yapın (zorunlu alanlar, formatlar, aralıklar), ancak sunucu tarafı doğrulamayı zorunlu sayın. İstemciler atlanabilir.

Sunucuda şunları uygulayın:

• Tipler ve kısıtlar (örn. integer ID'ler, maksimum uzunluklar)
• İş kuralları (örn. durum geçişleri)
• Normalizasyon (trim, tutarlı büyük/küçük harf)

AI'den endpoint istemleri isterken, paylaşılan bir doğrulama şeması (veya stack paylaşımı yoksa duplicasyon) talep edin ki hatalar formlar ve API arasında tutarlı kalsın.

Tutarlı sayfalandırma, sıralama ve arama

Her liste farklı davrandığında yönetici UI'ları çürür. Bir desen seçin ve her yerde uygulayın:

• page + pageSize (veya gerçekten gerekiyorsa cursor pagination)
• sortBy + sortDir ve sıralanabilir alanların bir izin listesi
• Basit metin araması için q, artı isteğe bağlı yapısal filtreler

Tahmin edilebilir cevaplar döndürün: { data, total, page, pageSize }. Bu, üretilen CRUD ekranlarını yeniden kullanılabilir ve test edilmesi kolay hale getirir.

Sık görülen risklere karşı koruma

Yüksek frekanslı risklere odaklanın:

• Injection: her zaman parametrized sorgular/ORM yöntemleri kullanın; SQL'i string birleştirmeyin.
• IDOR: izinleri kayıt başına kontrol edin, sadece "admin mi" demek yeterli değildir.
• Aşırı maruz bırakma: dahili alanları varsayılan olarak geri göndermeyin (token'lar, notlar, PII).

Ayrıca güvenli varsayılanlar belirleyin: önce reddet, en az ayrıcalık rolleri ve hassas endpointlerde muhafazakar rate limitler.

Gizli anahtarlar ve yapılandırma: repoya koymayın

Gizli bilgileri ortam değişkenlerinde veya dağıtımın secret manager'ında saklayın. Sadece duyurusel varsayılanları repoya koyun.

CI iş akışınıza basit bir kontrol ekleyin: .env'yi .gitignore'da tutun, .env.example gibi örnek bir dosya ekleyin ve CI'de basit bir "commitlerde gizli yok" taraması yapın (basit regex tabanlı bir araç bile yardımcı olur).

Yavaşlatmadan Kalite: Testler, Linting, CI

Hız sadece "hızlı gönder" değildir. Aynı zamanda "gönderdiğinde işleri bozmamak"tır. Hile, belirgin regresyonları yakalayan hafif kalite kontrolleri eklemektir; CRUD uygulamanızı bir bilim projesine çevirmeden.

Yüksek değerli küçük bir duman testi paketi

Admin uygulamaları için kırılınca kullanımı imkansız hale getiren birkaç akışa odaklanın:

• Giriş çalışıyor (ve doğru yönlendiriyor)
• Ana liste sayfası yükleniyor
• Oluştur → Kaydet → Listede görünür
• Düzenle → Kaydet → Değişiklikler kalıcı
• İzinler: düşük ayrıcalıklı kullanıcı admin-only route'a erişemiyor

Bu testleri uçtan uca veya "API + minimal UI" şeklinde tutun. Toplamda 5–10 test hedefleyin.

AI ile test taslakları oluşturun—sonra sadeleştirin

AI ilk geçişi üretmede iyidir, ama genellikle çok fazla kenar durum, fazla mocking veya kırılgan selector'lar üretir.

Oluşturulan testleri alıp:

• Örtüşenleri silin
• Stabil selector'lar (data-testid) tercih edin
• Aşırı mocking'den kaçının: mümkünse gerçek route handler'ları/servisleri test edin
• Hataları okunur kılın (açık isimler, net assertion'lar)

Linting, formatlama ve pre-commit kontrolleri

Kod tabanının düzenli kalması için otomasyon ekleyin—özellikle kodu toplu üretiyorsanız.

Minimumda:

• Formatter (örn. Prettier / Black)
• Linter (örn. ESLint / Ruff)
• TypeScript kullanıyorsanız tip kontrolleri
• Pre-commit hook: sadece hızlı kontrolleri çalıştıracak (format + lint)

Bu, stil tartışmalarını engeller ve inceleme esnasında "diff gürültüsü"nü azaltır.

Her push'ta koşan temel CI

CI'niz tam olarak üç şeyi yapmalı:

1. Bağımlılıkları yükle
2. Lint/typ kontrollerini çalıştır
3. Duman testlerini koş

Birkaç dakikayı aşmayacak şekilde tutun. Yavaş olursa göz ardı edersiniz—o yüzden hızlı geri bildirim amaçtır.

Hızlı Gönderme: Dağıtım, Seed Verisi ve İzleme

Erken göndermek, yönetici panelinizin gerçekten kullanılabilir olup olmadığını öğrenmenin en hızlı yoludur. Basit bir pipeline hedefleyin: kodu gönderin, staging'e deploy edin, temel akışları elle test edin, sonra production'a terfi ettirin.

Erken dağıtım için staging ortamı oluşturun

Başından itibaren iki ortam oluşturun: staging (dahili) ve production (gerçek). Staging, üretim ayarlarını (aynı veritabanı motoru, aynı auth modu) yansıtmalı, ancak ayrı veri kullanmalı.

Dağıtımı sıkıcı tutun:

• Tek komut veya tek CI işiyle deploy
• Ortam değişkenleri tek bir yerde yönetilsin
• Öngörülebilir URL düzeni (örn. /staging ve /app yeterli değil—ayrı hostlar kullanın)

Minimalin nasıl göründüğü için mevcut dağıtım yaklaşımınızı yeniden kullanın ve /docs/deploy içinde dokümante edin.

Koder.ai gibi platformlar, yerleşik dağıtım + barındırma, özel alan adı bağlama ve snapshot/rollback ile daha hızlı göndermenize yardımcı olabilir.

Hızlıca akışları demo ve doğrulamak için seed veri kullanın

Seed veri, "derleniyor" halinden "çalışıyor" hale geçişi hızlandırır. Amaç, önemli ekranları elle kurulum yapmadan anlamlı kılmaktır.

İyi seed veri:

• Küçük (onlarca satır, binler değil)
• Gerçekçi (durum değerleri, zaman damgaları, kenar durumlar)
• Tekrarlanabilir (wipe + re-seed saniyeler içinde)

Her ana durum için en az bir örnek ekleyin (örn. aktif/pasif kullanıcılar, ödenmiş/ödenmemiş faturalar). Böylece her deploy sonrası filtreleri, izinleri ve pano toplamlarını hemen doğrulayabilirsiniz.

Hataları ve temel performans metriklerini enstrümente edin

Gözlemlenebilirlik devrimine gerek yok. Şundan başlayın:

• Sunucu tarafı hata takibi (uncaught exception'lar, başarısız işler)
• Yavaş endpoint'ler için istek zamanlaması (p95 yeterli)
• Önyüz hata loglama (kırık ekranlar için)

Küçük bir uyarı seti oluşturun: "hata oranı sıçraması", "uygulama down" ve "veritabanı bağlantıları tükeniyor". Fazlası bekleyebilir.

Basit bir rollback stratejisi planlayın

Rollback mekanik olmalı, kahramanca değil. Birini seçin:

• Önceki build'i tekrar deploy et
• Son release artifact'ını sakla ve swap yap

Ayrıca veritabanı değişikliklerini nasıl ele alacağınızı kararlaştırın: additive migration'ları tercih edin ve özelleştirici değişikliklerden kaçının. Bir şey bozulduğunda, dakikalar içinde uygulanabilecek rollback en iyisidir.

Yaygın Aşırı Mühendislik Tuzakları (ve Nasıl Kaçınılır)

Hız, bir yönetici panelinin kendini “platform” gibi davranmaya başladığında ölür. CRUD uygulamaları için amaç nettir: açık ekranlar, güvenilir izinler ve soruları cevaplayan panolar gönderin—sonra gerçek kullanım verisine göre yineleyin.

Erken uyarı işaretleri

Bu desenleri görürseniz, inşa etmeden önce durun:

• Çok fazla soyutlama: "BaseRepositoryFactory", "GenericServiceLayer" veya bir özellik göndermeden kendi framework'ünüzü kurmak.
• Özel UI kitleri ve design system'ler: tablolar, formlar, modal'ları ve doğrulamayı yeniden yapmak yerine sıkıcı varsayılanları kullanın.
• Generic motorlar: sadece 3–5 akışınız varken bir "workflow engine", "rule engine" veya "configurable admin builder" inşa etmek.
• Erken optimizasyon: ölçülmemiş caching, kuyruklar veya event bus'lar.
• Multi-tenant ve eklenti mimarisi: MVP tek takım ve tek dataset iken "her ihtimali" düşünmek.

Ne zaman refactor yapılmalı (ve ne zaman yapılmamalı)

Refactor tekrar eden acı olduğunda yapılır, hayali ölçek için değil.

İyi tetikleyiciler:

• Aynı mantığı 3+ yerde değiştirdiniz ve birini kaçırdınız.
• Yeni bir CRUD ekranı öncekiyle aynı nedenle daha uzun sürüyor.
• Hatalar belirli bir karmaşık alanda kümeleniyor (izinler, doğrulama, raporlama sorguları).

Kötü tetikleyiciler:

• "Belki daha sonra microservices gerekebilir."
• "Bu controller çok büyük görünüyor" (ama nadiren değişiyor ve çalışıyor).

Bilerek bir “Sonra” backlog'u tutun

Cazip fikirleri tek bir Later listesinde toplayın: caching, microservices, event streaming, background job'lar, audit log UI iyileştirmeleri, gösterişli charting ve gelişmiş arama. Sadece kullanım kanıtı olduğunda geri dönün.

Hızlandırma öncesi kısa bir karmaşıklık kontrol listesi

Yeni bir katman eklemeden önce sorun:

1. Bu haftalık hangi kullanıcı problemini çözüyor?
2. Güvenlik ve veri bütünlüğünü hâlâ karşılayan en basit versiyonu nedir?
3. Bir darboğaz (zaman, maliyet, gecikme) ölçtük mü, yoksa tahmin mi yapıyoruz?
4. Bunu çerçeve varsayılanlarıyla ve tek bir net desenle yapabilir miyiz?
5. Şimdi atlamamız neyi kırar? Cevap “hiçbir şey” ise muhtemelen "Later".