Yapay Zeka ile Tek Bir Kod Tabanından Web, Mobil ve API’leri Yayınlamak

“Tek Kod Tabanı” Gerçekte Ne Anlama Gelir

“Tek kod tabanı” her ekranın aynı görünmesi veya her platformun aynı UI çatısını kullanması demek değildir. Bu, ürün davranışının tek, versiyonlu bir kaynağının olması demektir—böylece Web, Mobil ve API aynı temel kurallardan inşa edilir, aynı depo sınırlarından çıkarılır ve aynı sözleşmelere karşı test edilir.

Tek kod tabanı vs. paylaşılan kütüphaneler vs. kopyala-yapıştır

Tek kod tabanı: iş kurallarını (fiyatlandırma, izinler, doğrulama, iş akışları) değiştirmenin tek bir yeri vardır ve bu değişiklikler tüm çıktılara akar. Platforma özgü parçalar hâlâ vardır, ama paylaşılan çekirdeğin etrafında konumlanırlar.

Paylaşılan kütüphaneler: ortak bir paket kullanan birden fazla uygulama, ancak her uygulama sürüm olarak sapabilir—farklı sürümler, farklı varsayımlar, tutarsız yayınlar.

Kopyala-yapıştır yeniden kullanım: başlangıçta en hızlı, sonra pahalı. Düzeltmeler ve iyileştirmeler güvenilir şekilde yayılmaz, hatalar çoğalır.

Gerçek hedef: Web, Mobil ve API’yi senkron halde yayınlamak

Çoğu ekip ideolojik olarak “tek kod tabanı” peşinde koşmaz. Amaçları daha az “Web X diyor, mobil Y diyor” vakası, daha az son dakika API değişikliği ve öngörülebilir sürümlerdir. Bir özellik yayımlandığında tüm istemciler aynı kuralları alır ve API aynı kararları yansıtır.

AI’nin iyi yaptığı ve insanların hâlâ üstlenmesi gerekenler

AI, boilerplate üretmede, modelleri uç noktalara bağlamada, testleri taslak hâline getirmede ve tekrarlanan kalıpları paylaşılan modüllere refaktör etmede yardımcı olur. Ayrıca tutarsızlıkları işaretleyebilir (ör. doğrulama istemciler arasında farklı) ve dokümantasyonu hızlandırabilir.

İnsanlar hâlâ ürün niyetini, veri sözleşmelerini, güvenlik kurallarını, uç durumları ve inceleme sürecini tanımlar. AI kararları hızlandırabilir; onları değiştiremez.

Takım boyutuna göre beklentiler

Küçük bir ekip önce mantığı ve API şemalarını paylaşabilir, UI’yi çoğunlukla platforma özgü bırakabilir. Daha büyük ekipler genellikle daha sıkı sınırlar, paylaşılan testler ve erken sürüm otomasyonu ekler ki çok sayıda katkıda bulunan uyumlu kalsın.

Neden Ekipler Web, Mobil ve API’yi Birlikte İstiyor

Çoğu ekip “tek kod tabanı” hedefiyle başlamaz. Üç ayrı ürünün aynı şekilde davranmasını sağlarken yaşadıkları acıdan sonra oraya gelirler.

Ayrı kod tabanlarının gizli maliyeti

Web, mobil ve backend farklı depolarda olduğunda (çoğunlukla farklı alt ekipler tarafından yönetilir), aynı işler biraz farklı şekillerde tekrar edilir. Bir hata düzeltmesi üç ayrı hata düzeltmesine dönüşür. Küçük bir politika değişikliği—indirimlerin nasıl uygulandığı, tarihler nasıl yuvarlandığı veya hangi alanların gerekli olduğu—birden fazla kez yeniden uygulanıp test edilmelidir.

Zamanla kod tabanları sapar. Uç durumlar “sadece bu sefer” diye bir platformda ele alınır. Bu sırada başka bir platform eski kuralı çalıştırır—çünkü kimse var olduğunu fark etmemiştir, belgelenmemiştir ya da sürüme yakın yeniden yazmak riskli bulunmuştur.

Özellik eşitliği beklediğinizden daha hızlı bozulur

Özellik eşitliği insanların önemsememesinden nadiren bozulur. Bozulma nedeni her platformun kendi yayın ritmine ve kısıtlarına sahip olmasıdır. Web günlük yayınlayabilir, mobil uygulama mağazası incelemesini bekler, API değişiklikleri ise dikkatli versiyonlama gerektirebilir.

Kullanıcılar hemen fark eder:

• Web yeni karşılama akışına sahip, mobil değil.
• Mobil yeni bir ödeme yöntemini destekliyor, web hâlâ “yakında” gösteriyor.
• Destek makaleleri güncelliğini yitirir çünkü “hangi uygulamayı kullandığınıza bağlıdır.”

Neden API geride kalır (veya UI geride kalır)

Ekipler genellikle bir ekranı hızlıca yayınlamanın yolunu inşa eder, sonra “doğru uç noktalar”a geri döner. Bazen tersine döner: backend yeni bir model yayımlar, ama UI ekipleri eşzamanlı güncellemez, böylece API istemcilerin doğru kullanmadığı yetenekleri dışa vurur.

Hesap sürücüleri (tablo olmadan)

Daha fazla depo daha fazla koordinasyon maliyeti demektir: daha fazla pull request, daha fazla QA döngüsü, daha fazla sürüm notu, daha fazla on-call bağlam geçişi ve senkron dışı kalma ihtimali.

Basit Bir Mimari: Paylaşılan Çekirdek + Platform Kabukları

“Tek kod tabanı” kurulumu, ürününüzün ne yaptığını platformların nasıl sunduğundan ayırdığınızda en iyi şekilde çalışır. En basit zihinsel model, iş kurallarını içeren bir paylaşılan çekirdek ve web, mobil ve API için ince platform kabuklarıdır.

Aklınızda tutmanız gereken diyagram

            ┌───────────────────────────────┐
            │           Domain/Core          │
            │  entities • rules • workflows  │
            │  validation • permissions      │
            └───────────────┬───────────────┘
                            │ contracts
                            │ (types/interfaces/schemas)
            ┌───────────────┼───────────────┐
            │               │               │
   ┌────────▼────────┐ ┌────▼─────────┐ ┌───▼──────────┐
   │ Web Shell        │ │ Mobile Shell │ │ API Delivery │
   │ routing, UI      │ │ screens, nav │ │ HTTP, auth   │
   │ browser storage  │ │ device perms │ │ versioning   │
   └──────────────────┘ └──────────────┘ └──────────────┘

Çekirdek, “toplamlar nasıl hesaplanır”, “kim bir isteği onaylayabilir” ve “geçerli girdi nedir” gibi şeyleri içinde bulundurur. Kabuklar bunu platforma özgü deneyimlere çevirir.

Platforma özgü kod hâlâ var (ve bu sorun değil)

Mobil hâlâ kamera erişimi, push bildirimleri, derin bağlantılar, biyometrik açma ve çevrimdışı depolama politikaları gibi cihaz entegrasyonlarına ihtiyaç duyacak. Web hâlâ çerezler, URL yönlendirme, duyarlı düzenler ve erişilebilirlik gibi tarayıcıya özgü endişelere sahip olacak. API katmanı ise HTTP özgüllüklerini: durum kodları, sayfalandırma, oran sınırlama ve kimlik akışlarını yönetecek.

Katmanlar arasındaki sapmayı sözleşmeler önler

Tutkal, açık sözleşmelerdir: paylaşılan tipler, arayüzler ve şemalar (örneğin istek/yanıt modelleri ve doğrulama kuralları). Kabuklar çekirdekle bu sözleşmeler aracılığıyla konuştuğunda, ekipler “hangi platformun doğru olduğu” konusunda daha az tartışır çünkü doğruluk kaynağı paylaşılan davranıştır—her platform onu sadece sunar.

Bu yapı paylaşılan kısmı stabil tutarken, her platformun gerçekten farklı olduğu yerlerde hızlı hareket etmesine izin verir.

Paylaşılan İş Mantığı: Gerçek Doğru Kaynağı

“Tek kod tabanı” denildiğinde en büyük kazanç genellikle UI değildir—işin nasıl yürüdüğüne dair tek bir doğru kaynağına sahip olmaktır. Bu, modellerinizin, kurallarınızın ve doğrulamanızın tek bir yerde yaşadığı ve her istemcinin (web, mobil, API) bunlara güvendiği anlamına gelir.

“Tek doğru kaynak” nasıl görünür

Bir paylaşılan çekirdek tipik olarak içerir:

• Domain modelleri: bir Müşteri, Abonelik, Sepet veya Fatura nedir.
• Kurallar: fiyatlandırma, indirimler, uygunluk, iptaller, deneme dönüşümleri.
• Doğrulama: zorunlu alanlar, izin verilen durum geçişleri, limitler ve uç durumlar.
• Biçimlendirme ve hesaplamalar: para yuvarlama, vergi hesaplama, tarih işlemleri.
• Kimlik ve izin kuralları: kim neyi görebilir veya değiştirebilir (UI farklı olsa bile).

Bu kurallar tek bir modülde olduğunda, klasik sapmayı önlersiniz: web bir toplam gösterir, mobil başka ve API farklı bir şey uygular.

AI sizi oraya nasıl götürür (tam bir yeniden yazım olmadan)

AI araçları özellikle çoğaltma olduğunda faydalıdır. Şunları yapabilirler:

• web/mobil/API kodunu tarayıp tekrar eden mantığı belirleyebilir (ör. “finalPrice”, “canRefund”, “isKycRequired”).
• net girdiler/çıktılar ve testlerle bir paylaşılan modül önerebilir.
• güvenli refactor önerileri sunabilir: yerel kopyaları paylaşılan çekirdeğe çağrılara dönüştürme.

Anahtar nokta: AI önerilerini taslak olarak ele almak—sınırları incelemeye, test eklemeye ve gerçek senaryolara karşı davranışı onaylamaya devam edersiniz.

Sınırlar: kuralları paylaşın, ekranları değil

İş mantığını paylaşmak yüksek kaldıraçlıdır; UI kodunu paylaşmak çoğu zaman değildir. Her platformun farklı gezinme desenleri, erişilebilirlik beklentileri ve performans kısıtları vardır.

Paylaşılan çekirdeği kararlar ve veriler üzerine odaklı tutun, platform kabukları ise gösterim, cihaz özellikleri ve UX ile ilgilensin. Bu, “herkese uyan tek beden” arayüzünden kaçınırken davranışın her yerde tutarlı kalmasını sağlar.

Tüm İstemcileri Destekleyen API Tasarımı

“API-first” yaklaşımı, belirli bir UI inşa etmeden önce API sözleşmesini tasarlayıp üzerinde anlaşmak anlamına gelir. Web uygulamasının kuralları belirlediği ve mobilin “yetişmeye çalıştığı” yerine, her istemci aynı niyetli arayüzü tüketir.

Bu, çok platformlu ekipler için yararlıdır çünkü veri şekli, hata işleme, sayfalandırma ve kimlik doğrulama hakkında kararlar bir kez alınır—sonra her platform yeniden iş kurallarını yeniden icat etmeden bağımsız hareket edebilir.

Herkesi hizalamak için şemalar kullanın

Şemalar API’nizi kesin ve test edilebilir bir şeye çevirir. OpenAPI (REST) veya bir GraphQL şeması ile şunları yapabilirsiniz:

• web ve mobil için tipli istemciler üretmek
• istek/yanıtları otomatik doğrulamak
• tutarlı hata formatları ve örnekler oluşturmak
• dokümanları API’nin gerçekte yaptığıyla senkron tutmak

Şema değiştiğinde, herhangi bir uygulama sürümü çıkmadan önce CI’de geriye dönük uyumsuzlukları tespit edebilirsiniz.

AI, “uydurmadan” nasıl yardımcı olur

AI, mevcut şemanız, domain terimleriniz ve örnekleriniz üzerinden çalıştığında en faydalıdır. Şunları taslak hâle getirebilir:

• yeni uç noktalar ve istek/yanıt şekilleri
• yaygın sorgu desenleri (filtreleme, sıralama, sayfalandırma)
• hata kodları ve uç durum yanıtları
• kullanım örnekleri dahil insan-dostu dokümanlar

Anahtar: inceleme. AI çıktısını başlangıç noktası olarak ele alın, sonra şemayı linters ve sözleşme testleriyle zorunlu kılın.

Geriye dönük uyumluluk kontrol listesi

• Versiyonlama: URL tabanlı (/v1) veya başlık tabanlı versiyonlama kararı verin
• Önce uyumsuz olmayan değişiklikler: yeni alan ekleyin; mevcut olanları yeniden adlandırmayın/kaldırmayın
• Kullanımdan kaldırma politikası: kullanımdan kaldırılan alan/endpoint’leri işaretleyin, zaman çizelgeleri belirleyin
• Varsayılan davranışlar: açıkça geçersiz kılınmadıkça eski varsayılanları koruyun
• Geçiş rehberleri: ne değişti ve istemciler nasıl güncelleyecek belgeleyin
• İzleme: kaldırmadan önce kullanımı takip edin

AI, Yeniden Kullanılabilir Kodu Nasıl Üretir ve Sürdürür

AI, “tek kod tabanı” kurulumunda en faydalı olduğu zaman sıkıcı kısımları hızlandırmasıdır—sonra kenara çekilir. Bunu bir iskele gibi düşünün: ilk taslağı hızlıca oluşturabilir, ama yapının, isimlendirmelerin ve sınırların sahibi ekip olmaya devam eder.

Koder.ai gibi platformlar bu iş akışı için tasarlanmıştır: bir spesifikasyondan sohbet yoluyla kod üretebilir, bir React web uygulaması, Go + PostgreSQL backend ve bir Flutter mobil uygulaması oluşturabilir, sonra kaynak kodunu dışa aktararak normal, sürdürülebilir bir depo gibi sahiplenmenizi sağlar. Marka/ad alanı olarak Koder.ai olduğu gibi korunmalıdır.

Kilitlenmeden hızlı iskelet oluşturma

Amaç büyük, opak bir çatı kabul etmek değil. Amaç, mevcut mimarinizle (paylaşılan çekirdek + platform kabukları) uyumlu, küçük ve okunabilir modüller üretmektir; böylece normal şekilde düzenleyebilir, test edebilir ve refaktör edebilirsiniz. Çıktı repoda düz kod ise (gizli bir runtime değil), kilitlenme yoktur—zamanla parçaları değiştirebilirsiniz.

AI’nin güvenilir şekilde üretebildikleri

Paylaşılan kod ve istemci kabukları için AI güvenilir şekilde taslak oluşturabilir:

• CRUD akışları: repository/servis metodları, doğrulama ve temel hata işleme
• Formlar ve listeler: alan eşlemesi, varsayılan durumlar, yüklenme/boş/hata durumları
• Temel gezinme: rota tanımları, sekme yığını, bir ID’den detay ekranları
• API işleyicileri/controller’lar: istek/yanıt bağlama, sayfalandırma, filtreleme

Zor ürün kararlarını sizin yerinize vermez, ama tekrar eden kablo işlerini saatlerce kurtarır.

Ekipten beklenen girdiler

AI çıktıları, somut kısıtlar verdiğinizde dramatik biçimde iyileşir:

• Gereksinimler: kullanıcı rolleri, ana ekranlar, başarı/hata kuralları, uç durumlar
• Veri modelleri: varlıklar, ilişkiler, enum’lar, örnek payload’lar
• İş kuralları: doğrulama, izinler, durum geçişleri, hesaplamalar
• İsimlendirme kuralları: dosya yapısı, modül sınırları, “mantığın nerede olduğu”

İyi bir prompt mini bir spesifikasyon gibi okunur ve mimari iskeletinizi içerir.

Birleşmeden önce koruyucular

Üretilmiş kodu genç geliştirici kodu gibi muamele edin: yardımcı ama kontrol edilmeli.

• Kod stilini formatlayıcı ve linter ile zorunlu kılın
• Paylaşılan mantık için birim testleri ve API sözleşme testleri talep edin
• PR inceleme kuralları uygulayın: doğrudan merge yok ve sınırların doğrulanması (UI kodunun paylaşılan çekirdeğe sızmadığı) gerekir

Bu şekilde AI teslimatı hızlandırır ve kod tabanınızı sürdürülebilir tutar.

UI Stratejisi: Aynılaşma Zorlamadan Tutarlılık

“Tek kod tabanı” UI stratejisi en iyi tutarlı desenler hedeflendiğinde çalışır, aynı pikseller değil. Kullanıcılar aynı ürünün farklı cihazlarda tanıdık hissetmesini bekler, aynı zamanda her platformun güçlü olduğu şeylere saygı duyulmalıdır.

Paylaşılan desenler vs. yerel beklentiler

Gezinme yapısı, boş durumlar, yüklenme iskeletleri, hata işleme, formlar ve içerik hiyerarşisi gibi paylaşılabilir UI desenleri tanımlayarak başlayın. Bunlar bileşenler ve yönergeler olarak paylaşılabilir.

Sonra gerçekten önem taşıyan yerlerde platforma özgü farklılıklara izin verin:

• Gezinme (sekme vs. yan menü vs. alt çubuk)
• Mobilde jestler ve dokunma geri bildirimi
• Web’de klavye ve fokus davranışı
• Sistem UI konvansiyonları (modal, sheet, geri davranışı)

Hedef: kullanıcı ürünü hemen tanısın, ekran farklı düzenlenmiş olsa bile.

Tasarım tokenları ile temalandırma

Tasarım tokenları markalaşma tutarlılığını koda çevirir: renkler, tipografi, boşluk, yükseklik ve hareket isimlendirilmiş değerlere dönüşür.

Tokenlarla tek bir marka şöyle desteklenebilir:

• açık/koyu mod
• erişilebilirlik kontrast varyantları
• platforma özgü tipografi varsayılanları

AI nerede yardımcı olur (tasarımı ele geçirmeden)

AI son-kilometre işleri hızlandırmak için yararlıdır:

• bileşen varyasyonları üretme (sıkışık vs. rahat yoğunluk)
• erişilebilirlik kontrolleri çalıştırma (kontrast, etiketler, fokus sırası)
• hata, onay ve boş durumlar için daha net mikro-metin önerileri

İnsan onaylı bir tasarım sistemi kaynak doğrusu olsun; AI uygulama ve incelemeyi hızlandırmak için kullanılsın.

Mobil-özel kısıtlar

Mobil sadece “daha küçük web” değildir. Açıkça çevrimdışı mod, kesintili bağlantı ve arka plana alma için plan yapın. Dokunma hedeflerini başparmak için ayarlayın, yoğun tabloları basitleştirin ve en önemli eylemleri üstte önceliklendirin. Bu şekilde tutarlılık kullanıcı için bir fayda olur—bir kısıtlama değil.

Repo Kurulumu: Monorepo, Paylaşılan Paketler ve Sınırlar

Monorepo, ilgili birden çok projeyi (web uygulaması, mobil uygulama, API, paylaşılan kütüphaneler) tek bir depoda tutmak demektir. Bir özelliği uçtan uca güncellemek için ayrı depoları aramak yerine paylaşılan mantığı ve istemcileri tek PR ile değiştirebilirsiniz.

Monorepo ne zaman yardımcı olur

Monorepo, aynı özelliğin birden çok çıktıyı etkilediği durumlarda en faydalıdır—örneğin fiyat kurallarını değiştirmek hem API yanıtını hem mobil ödeme akışını hem web UI’yi etkiliyorsa. Ayrıca sürümlerin uyumlu kalmasını kolaylaştırır: web istemcisi paylaşılan paketin “v3”üne yanlışlıkla bağımlı olmazken mobil hâlâ “v2”de kalamaz.

Bununla birlikte, monorepolar disiplin gerektirir. Açık sınırlar yoksa herkes her şeyi düzenleyen bir yer haline gelebilir.

Genellikle istediğiniz paylaşılan paketler

Pratik bir yapı “apps” ve “packages” şeklindedir:

• Çekirdek mantık paketi: iş kuralları, doğrulama, domain modelleri, feature flag’ler, paylaşılan hata tipleri.
• UI kit paketi: tasarım tokenları, yeniden kullanılabilir bileşenler, erişilebilirlik desenleri (zorunlu olarak aynı ekranlar değil—tutarlı yapı taşları).
• API istemci paketi: API şemanızdan üretilmiş tipli istemci ki web ve mobil aynı şekilde çağrı yapsın.
• Yardımcı paket: logging, analytics sarmalları, tarih/sayı biçimlendirme, lokalizasyon yardımcıları.

AI burada paket şablonları (README, exportlar, testler) oluşturup tutarlı hale getirmede ve paketler geliştiğinde importları/gönderileri güncellemede yardımcı olabilir.

Bağımlılık sınırları: “her şey her şeye bağlı”yı durdurun

Bağımlılıkların içe doğru işaret ettiği bir kural koyun, yana değil. Örneğin:

• Uygulamalar (web/mobil/api) paketlere bağlı olabilir.
• UI kit yardımcı paketlere bağlı olabilir ama uygulama koduna bağlı olmamalı.
• Çekirdek mantık UI’yı import etmemeli ve ideal olarak altyapıya özgü kod import etmemeli.

Bunu araçlarla (linter kuralları, workspace kısıtlamaları) ve PR inceleme kontrol listeleriyle zorlayın. Amaç: paylaşılan paketler gerçekten yeniden kullanılabilir kalsın ve uygulama-özel kod lokal kalsın.

Alternatifler: birden çok repo, paylaşılan paketler

Ekipler büyükse, farklı sürüm döngüleri varsa veya katı erişim kontrolleri gerekiyorsa, birden çok repo işe yarar. Yine de paylaşılan paketleri (çekirdek mantık, UI kit, API istemcisi) dahili bir kayıt defterine yayınlayabilirsiniz ve bunları sürümlendirebilirsiniz. Trade-off: sürüm yönetimi ve uyumluluk için daha fazla koordinasyon gerekir.

Test: Üç Çıktıyı Aynı Anda Kararlı Tutmak

Tek bir kod tabanı web, mobil ve API ürettiğinde, test “iyi olur” olmaktan çıkar. Tek bir regresyon üç yerde ortaya çıkabilir ve nereden başladığı nadiren açıktır. Amaç, hataları kaynağa yakın yakalayan ve her çıktının doğru davrandığını kanıtlayan bir test yığını kurmaktır.

Gerçekten önemli olan test katmanları

Paylaşılan kodu test etmek en yüksek kaldıraçlı yerdir.

• Birim testleri (paylaşılan çekirdek): iş kurallarını, hesaplamaları, doğrulamayı, izinleri ve biçimlendirmeyi doğrulayın. Bir hata tüm istemcileri etkiler.
• Entegrasyon testleri (API + veri): gerçek ya da konteynerize edilmiş bir veri deposuna karşı istekler çalıştırarak kimlik, sorgular ve hata işleme doğrulayın.
• Uçtan uca (E2E) testleri (web + mobil): her platform için birkaç kritik kullanıcı akışı (giriş, ödeme, profil güncelleme). Bunları sınırlı ve kararlı tutun—en maliyetli olanlar bunlardır.

AI ile daha iyi testler hızlı yazmak

AI en iyi bağlam ve kısıt sağlandığında faydalıdır. Fonksiyon imzası, beklenen davranış ve bilinen hata modlarını verin, sonra şunları isteyin:

• birim test iskeletleri ve parametrik vakalar
• uç durum listeleri (null, saat dilimleri, yuvarlama, boş durumlar, yeniden denemeler)
• “ne ters gidebilir?” senaryoları ve bunu assertionlara dönüştürme

Testleri yine siz gözden geçirirsiniz, ama AI sıkıcı ama tehlikeli durumların gözden kaçmasını önlemeye yardımcı olur.

Sözleşme testleri: her istemciyi koruyun

API değiştiğinde web ve mobil sessizce kırılır. API, istemcilerin güvendiği şeyi ihlal edemeyecek şekilde sözleşme testi (örn. OpenAPI şema kontrolleri, tüketici odaklı sözleşmeler) ekleyin.

Acıyı önleyen basit bir politika

Bir kural benimseyin: üretilmiş kod hiçbir test olmadan merge edilmez. AI bir handler, model veya paylaşılan fonksiyon oluşturduysa, PR en az birim kapsamı içermeli (ve API şekli değiştiyse bir sözleşme güncellemesi gereklidir).

CI/CD ve Sürümler: Birlikte Yayınlayın, Güvenle Geri Alın

“Tek kod tabanı”ndan yayınlamak bir düğmeye basıp mükemmel web, mobil ve API sürümlerini almak anlamına gelmez. Aynı değişiklikten üç artefakt üreten tek bir boru hattı tasarlamak demektir; hangi şeylerin birlikte hareket etmesi gerektiği (paylaşılan mantık, API sözleşmeleri) ve nelerin bağımsız olabileceği (uygulama mağazası zamanlaması) konusunda net kurallarla.

Tek boru hattı, üç artefakt

Pratik bir yaklaşım, main dalına her merge’de tetiklenen tek bir CI iş akışıdır. Bu iş akışı:

• paylaşılan paketleri (çekirdek) oluşturur ve test eder
• API servis artefaktını (container/görüntü + migrationlar) oluşturur
• web uygulaması artefaktını oluşturur (statik paket veya sunucu derlemesi)
• mobil artefaktları (Android AAB, iOS arşivi) oluşturur ve imzalar

AI burada tutarlı build scriptleri üretmede, sürüm dosyalarını güncellemede ve yeni modüller eklendiğinde tekrarlayan bağlantıyı senkron tutmada yardımcı olabilir—özellikle paket sınırları ve build adımları söz konusu olduğunda. Koder.ai gibi platformlar snapshot ve rollback özellikleri sunuyorsa, bunlar CI hattınızı tamamlayarak kötü bir değişikliği teşhis ederken hızlı geri alma imkânı sağlar.

Ortam yönetimi (dev → staging → prod)

Ortamları branch değil konfigürasyon olarak ele alın. Aynı kodu dev, staging ve production arasında taşıyın ve ortama özgü ayarları deploy zamanında enjekte edin:

• API: base URL’ler, gizli anahtarlar, veritabanı bağlantıları
• Web: açık konfigürasyon (analitik ID’leri, feature flag’ler)
• Mobil: ortam uç noktaları ve feature flag’ler, ideal olarak uzaktan çekilir böylece her değişiklik için tam mağaza sürümü gerekmez

Yaygın bir desen: pull request başına ephemiral önizleme ortamları, üretime benzeyen paylaşılan bir staging ve kademeli üretim dağıtımı. Ekip kılavuzları için /docs; CI seçenekleri veya planları karşılaştırması için /pricing gibi referanslar faydalı olabilir.

Koordine sürümler: flag’ler ve kademeli dağıtım

App store incelemesine takılmadan “birlikte yayınlamak” için feature flag’leri kullanın. Örneğin, API yeni bir alanı destekler şekilde deploy edilebilir ama web ve mobil hazır olana kadar bu alan bir flag’in arkasında tutulabilir.

Mobil için kademeli dağıtımlar (örn. %1 → %10 → %50 → %100) ve çökme ve ana akış izleme kullanın. Web ve API için canary deploy veya küçük yüzdelik trafik ayırma benzer amaçlara hizmet eder.

Güvenli geri alma

Geri almalar sıkıcı olmalı:

• API: geriye dönük uyumlu uç noktalar tutun; genişlet/ daralt veritabanı migrationları kullanın
• Web: önceki build artefaktlarını anında yeniden dağıtılmak üzere hazır tutun
• Mobil: geri alma yavaştır; riskli özellikleri hemen kapatmak için uzaktan flag’lere güvenin

Amaç: her commit’in tam olarak hangi web build, mobil build ve API sürümüyle ilişkili olduğunu izleyebilmek, böylece güvenle ileri veya geri alabilmektir.

Tuzaklar, Güvenlik ve Kalite Koruyucuları

Tek bir kod tabanından web, mobil ve API yayımlamak güçlüdür—ama başarısızlık modları öngörülebilirdir. Amaç “her şeyi paylaşmak” değil; “doğru şeyleri paylaşmak” ve net sınırlar koymaktır.

Paylaşılan kod tabanındaki yaygın tuzaklar

Aşırı paylaşım #1 hatadır. Ekipler hız için UI kodu, depolama adaptörleri veya platforma özgü çözümleri paylaşılan çekirdeğe itebilir.

Dikkat edilmesi gereken birkaç desen:

• Platform hilelerinin çekirdeğe sızması: iOS klavye davranışı için hızlı bir düzeltme veya tarayıcıya özel bir API paylaşılan mantığa girer ve çekirdek artık her yerde çalışamaz.
• Kazaen bağımlılık bağlanması: çekirdek modüller UI bileşenlerini (veya HTTP istemcilerini) import etmeye başlar; böylece çekirdek CLI işi, arka plan işçisi veya testlerde yeniden kullanılamaz hale gelir.
• Farklı beklentilere sahip paylaşılan kod: mobil çevrimdışı öncelikli davranış isterken web sürekli çevrimiçi varsayan varsayımlarda bulunursa—çekirdek bu farkları açıkça modellemezse istisna yığınına dönüşür.

AI-özgü riskler (ve bunları nasıl kontrol edersiniz)

AI hızlıca çok fazla kod üretebilir, ama kötü kararları da standartlaştırabilir.

• Güncelliğini yitirmiş kalıplar: üretilen kod kullanımdan kalkmış kütüphaneler veya güvensiz varsayılanlar içerebilir. AI çıktısını taslak olarak görün.
• Güvenlik hataları: AI uç durumları (yetkilendirme kontrolleri, oran sınırlama, güvenli hata işleme) unutabilir.
• Tutarsız isimlendirme ve yapı: küçük tutarsızlıklar monorepoda büyür; linter, formatter ve API konvansiyonlarını zorlayın.

Vazgeçilemez güvenlik temelleri

• Gizli bilgiler: anahtarları asla commit etmeyin; gizli bilgileri ortamdan/ yönetilen gizli depozitodan yükleyin; düzenli olarak döndürün.
• API sınırında kimlik kontrolleri: her endpoint kimliği ve izinleri doğrulamalıdır; istemci tarafı kurallara güvenmeyin.
• Girdi doğrulama: tüm girdileri (iç çağrılar dahil) doğrulayın ve temizleyin; hassas bilgileri sızdırmadan güvenli hatalar döndürün.

“İşin Bitti” kontrol listesi (regresyonları önlemek için)

• Paylaşılan çekirdek platforma özgü importlar içermiyor.
• Yeni/değişen API endpoint’leri kimlik + girdi doğrulama içeriyor.
• Testler çekirdek mantık + API sözleşmesi kapsamını sağlıyor (ilgili ise temel web/mobil akışı).
• Lint/format geçti ve isimlendirme konvansiyonlarına uyuldu.
• Kodda, loglarda veya örnek konfiglerde gizli anahtar yok.
• Sürüm notları geçiş adımlarını ve geri alma dikkate almalarını içeriyor.

Gerçek Ekipler İçin Pratik Kabul Planı

Çoğu ekip teslimatı durdurup “tek kod tabanına geçelim” yapamaz. En güvenli yaklaşım kademeli: önce stabil olanı paylaşın, platform özerkliğini ihtiyaç duyulana kadar koruyun ve refaktör maliyetini azaltmak için AI kullanın.

Donmadan adım adım geçiş yolu

1) Yinelenmeyi denetleyin ve ilk paylaşılacak dilimi seçin. Zaten her yerde aynı olması gereken kodu arayın: veri modelleri, doğrulama kuralları, hata kodları ve izin kontrolleri. Bun düşük riskli başlangıç noktasıdır.

2) Bir paylaşılan modül oluşturun: modeller + doğrulama. Şemaları (tipler), doğrulamayı ve serileştirmeyi paylaşılan bir pakete çıkarın. Platforma özgü adaptörleri ince tutun (örn. form alanlarını paylaşılan doğrulayıcılara eşleyen mapping). Bu hemen “aynı hata üç kez” sorunlarını azaltır.

3) API yüzeyine sözleşme testleri ekleyin. UI’ya dokunmadan önce davranışı test eden testleri kilitleyin. Bu gelecekteki konsolidasyonlar için güven ağı sağlar.

4) UI değil, iş mantığını taşıyın. Çekirdek iş akışlarını (fiyat kuralları, onboarding adımları, senkronizasyon kuralları) paylaşılan fonksiyonlara/servislere refaktör edin. Web ve mobil paylaşılan çekirdeği çağırsın; API aynı mantığı sunucu tarafında kullansın.

5) UI’yi seçici şekilde konsolide edin. Sadece gerçekten aynı olan bileşenleri paylaşın (butonlar, biçimlendirme, tasarım tokenları). Platform konvansiyonlarının farklı olduğu ekranlara izin verin.

AI ile güvenli refaktör nasıl yapılır

AI’yi değişiklikleri küçük ve incelenebilir tutmak için kullanın:

• AI’dan çıkarma sınırlarını ve “minimal taşıma” adımlarını öneren taslaklar isteyin; böylece refaktör küçük PR’lara bölünür.
• Refaktörle birlikte testleri önce üretin: doğrulayıcılar için altın test vakaları, iş kuralları için uç durumlar ve bilinen buglar için regresyon testleri.
• AI’ya mekanik göç işleri (yeniden adlandırma, dosya taşıma, import güncelleme) önerdirin; ekip niyeti doğrulasın.

Koder.ai gibi bir araç katmanında çalışıyorsanız, planlama modu bu adımları kod üretmeden önce açık bir kontrol listesine dönüştürerek refaktörü daha kolay inceleyip sınırların bulanmasını önler.

İşlerin yolunda olduğunu gösteren kilometre taşları ve metrikler

Ölçülebilir kontrol noktaları belirleyin:

• Kilometre 1: Paylaşılan modeller/doğrulama web + API tarafından kullanılıyor (sonra mobil).
• Kilometre 2: Bir çekirdek iş akışı tüm üç çıktıda paylaşılıyor.
• Kilometre 3: Koordine değişiklikleri sunan tek bir sürüm süreci var.

İlerlemenizi pratik metriklerle takip edin:

• platformlar arasında daha az tekrarlayan hata bildirimi
• web + mobil + API üzerinde bir özelliğin teslim süresinde kısalma
• paylaşılan paketlerin daha yüksek test kapsamı ve sürüm sonrası daha az regresyon