Yapay zeka ile ekiplerin tek bir kod tabanı kullanarak web uygulaması, mobil uygulama ve API’yi birlikte nasıl yayımladığını öğrenin—mimari, otomasyon, test ve tuzakları kapsar.
“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ı: 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.
Ç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, 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.
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.
Ç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.
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 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:
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.
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.
“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.
┌───────────────────────────────┐
│ 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.
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.
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.
“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.
Bir paylaşılan çekirdek tipik olarak içerir:
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 araçları özellikle çoğaltma olduğunda faydalıdır. Şunları yapabilirler:
Anahtar nokta: AI önerilerini taslak olarak ele almak—sınırları incelemeye, test eklemeye ve gerçek senaryolara karşı davranışı onaylamaya devam edersiniz.
İş 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.
“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.
Şemalar API’nizi kesin ve test edilebilir bir şeye çevirir. OpenAPI (REST) veya bir GraphQL şeması ile şunları yapabilirsiniz:
Şema değiştiğinde, herhangi bir uygulama sürümü çıkmadan önce CI’de geriye dönük uyumsuzlukları tespit edebilirsiniz.
AI, mevcut şemanız, domain terimleriniz ve örnekleriniz üzerinden çalıştığında en faydalıdır. Şunları taslak hâle getirebilir:
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.
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.
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.
Paylaşılan kod ve istemci kabukları için AI güvenilir şekilde taslak oluşturabilir:
Zor ürün kararlarını sizin yerinize vermez, ama tekrar eden kablo işlerini saatlerce kurtarır.
AI çıktıları, somut kısıtlar verdiğinizde dramatik biçimde iyileşir:
İyi bir prompt mini bir spesifikasyon gibi okunur ve mimari iskeletinizi içerir.
Üretilmiş kodu genç geliştirici kodu gibi muamele edin: yardımcı ama kontrol edilmeli.
Bu şekilde AI teslimatı hızlandırır ve kod tabanınızı sürdürülebilir tutar.
“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.
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:
Hedef: kullanıcı ürünü hemen tanısın, ekran farklı düzenlenmiş olsa bile.
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:
AI son-kilometre işleri hızlandırmak için yararlıdır:
İnsan onaylı bir tasarım sistemi kaynak doğrusu olsun; AI uygulama ve incelemeyi hızlandırmak için kullanılsın.
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.
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, 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.
Pratik bir yapı “apps” ve “packages” şeklindedir:
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ıkların içe doğru işaret ettiği bir kural koyun, yana değil. Örneğin:
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.
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.
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.
Paylaşılan kodu test etmek en yüksek kaldıraçlı yerdir.
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:
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.
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.
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).
“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.
Pratik bir yaklaşım, main dalına her merge’de tetiklenen tek bir CI iş akışıdır. Bu iş akışı:
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.
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:
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.
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.
Geri almalar sıkıcı olmalı:
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.
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.
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:
AI hızlıca çok fazla kod üretebilir, ama kötü kararları da standartlaştırabilir.
Ç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.
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’yi değişiklikleri küçük ve incelenebilir tutmak için kullanı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.
Ölçülebilir kontrol noktaları belirleyin:
İlerlemenizi pratik metriklerle takip edin:
Bu, ürün davranışının (kurallar, iş akışları, doğrulama, izinler) sürülen tek, versiyonlu bir kaynak tarafından belirlendiği anlamına gelir ve tüm çıktılar buna dayanır.
UI ve platform entegrasyonları hâlâ farklı olabilir; paylaşılan kısım karar verme ve sözleşmelerdir—böylece Web, Mobil ve API tutarlı kalır.
Paylaşılan kütüphaneler yeniden kullanılabilir paketlerdir, ancak her uygulama farklı sürümler kullanarak, farklı varsayımlarda bulunarak veya farklı takvimlerle uğraşarak sapabilir.
Gerçek bir “tek kod tabanı” yaklaşımı, çekirdek davranışındaki değişikliklerin aynı kaynak ve aynı sözleşmelerden tüm çıktılara akmasını sağlar.
Çünkü platformlar farklı hızlarda dağıtım yapar. Web günlük dağıtım yapabilir, mobil mağaza incelemesi bekleyebilir ve API dikkatli versiyonlama gerektirebilir.
Paylaşılan bir çekirdek ve sözleşmeler, kuralın kendisini ortak eser haline getirerek “Web X diyor, mobil Y diyor” durumlarını azaltır—üç ayrı yeniden uygulama yerine tek bir kaynak olur.
İş mantığını paylaşılan çekirdeğe koyun:
Platform kabukları ise UI, gezinme, depolama ve cihaz/tarayıcıya özgü konulardan sorumlu olsun.
Açık, test edilebilir sözleşmeler kullanın: paylaşılan tipler/arayüzler ve API şemaları (OpenAPI veya GraphQL gibi).
Bunları CI içinde zorunlu kılarak (şema doğrulama, geriye dönük uyumsuzluk kontrolleri, sözleşme testleri) bir değişiklik istemcilerin beklentilerini ihlal edemeden dağıtılamaz hale gelir.
Önce API sözleşmesini kasıtlı olarak tasarlamak; böylece tüm istemciler aynı arayüzü kullanır.
Pratikte bu, istek/yanıt şekillerinde, hata formatlarında, sayfalandırmada ve kimlik doğrulamada uzlaşmayı içerir—sonra tipli istemciler üretilir ve dokümantasyon şema ile uyumlu tutulur.
Tekrarlayan işleri hızlandırmak AI için en güçlü alandır:
Ancak niyet, uç durumlar ve inceleme insanlara aittir; birleştirmeden önce koruyucuları uygulamalısınız.
Tek depo, paylaşılan mantığın ve istemcilerin bir PR içinde güncellenebildiği durumlarda faydalıdır; böylece sürümler uyumlu kalır.
Monorepo kullanamıyorsanız (erişim kontrolleri, bağımsız sürüm döngüleri), birden fazla repo da çalışır—ancak paket sürümlendirme ve uyumluluk için daha fazla koordinasyon gerekir.
Ortak kaynağa en yakın yerleri önceliklendirin:
Ek olarak, API değişikliklerinin web veya mobilde sessizce kırılmasını önlemek için sözleşme testleri ekleyin.
Aşırı paylaşım en büyük hata. UI kodu, depolama adaptörleri veya platforma özgü geçici çözümler paylaşılan çekirdeğe sızmamalı.
Yardımcı koruma önlemleri: