Uygulamaların güvenle değişmesi için yeniden-oluşturma öncelikli geliştirme

Neden yamalama değişiklikleri teknik borca dönüşür

Yamalamak, yeni bir gereksinim ortaya çıktığında onu uygulamaya mümkün olan en küçük düzenlemeyle sıkıştırmaktır. Hızlı hissettirir çünkü öyledir. Sorun şu ki her yama yerel bir çözümdür ve yerel çözümler genellikle uygulamanın nasıl yapılandırılması gerektiğiyle örtüşmez.

Zamanla yamalar yığılır. Uygulama hâlâ çalışır, ama kod ve yapılandırma birbirine uymamaya başlar: veritabanı bir şeyi söyler, UI başka bir şeyi ima eder ve gerçek kurallar üç farklı yerde yaşar. Bu uyumsuzluk teknik borçtur. Bu sadece "kötü kod" değildir. Bu, bir sonraki değişikliği yapmanın artan maliyetidir.

Genellikle bunu fark edebilirsiniz:

• Mantık karmaşıklaşır; küçük bir kural değişikliği birçok ekranı veya endpoint'i etkiler.
• Alanlar çoğalır ("status", "ticket_status", "status_v2") çünkü yeniden adlandırmak riskli gelir.
• UI kırılganlaşır; belirli veri şekillerine veya uç durumlara gizli bağımlılıklar oluşur.
• Geçici çözümler "geçici" bayraklara dönüşür ve asla gitmezler.
• Düzeltmeler takip düzeltmeleri ister çünkü kimse başka ne kırılacağını bilmiyor.

Riskin ne kadar hızlı büyüdüğü acı vericidir. Küçük olması gereken bir değişiklik (onay adımı eklemek, fiyat kuralını ayarlamak, bir kullanıcı rolünü ikiye bölmek) tahmin edilemeyen bir etki alanı yüzünden riskli bir sürüme dönüşür. Test etmek tahmin işi olur. Geri alma zorlaşır çünkü yama ilgisiz parçalara dokunmuştur.

Yeniden-oluşturma öncelikli geliştirme buna doğrudan bir yanıt sunar. Amaç, değişikliklerin öngörülebilir ve geri alınabilir olacağı, platformun dünkü geçici çözümleri taşımadan temiz kodu yeniden üretebileceği bir uygulama yapısı kurmaktır.

Pratik hedefler:

• Veri için tek, net bir doğruluk kaynağı (neredeyse aynı olan alanların çoğalmasına izin verme).
• Kurallar tek bir yerde yaşar, UI ve endpoint'ler arasında dağılmaz.
• UI gösterim ve girdiyle ilgilenir, iş kararlarıyla değil.
• Değişiklikler modeli ve mantığı günceller; ardından çıktıları el ile düzenlemek yerine yeniden üretirsiniz.

AppMaster gibi platformlar bunu destekler çünkü uygulama modeller ve görsel mantıkla tanımlanır ve platform tam kaynak kodu yeniden üretir. Yeniden üretim temiz kalır, ancak önce yamalama odaklı yapıyı önlemek gerekir.

Yeniden-oluşturma öncelikli geliştirme ne demek

Yeniden-oluşturma öncelikli geliştirme, uygulamanızı el ile düzenlenmiş kod yığını olarak değil, açık modeller kümesi olarak ele alır. Modelleri değiştirirsiniz, yeniden üretirsiniz ve temiz, tutarlı bir uygulama sürümü elde edersiniz. Amaç, sonraki değişikliği zorlaştıran ek geçici çözümler bırakmadan değişiklikleri göndermektir.

Yama-öncelikli bir iş akışında küçük bir isteğe (yeni bir durum alanı, yeni bir onay adımı) en hızlı uyan yere eklenir. Birisi bir API handler'ını düzeltilir, bir ekranı günceller, başka bir yerde özel bir durum ekler ve iş biter. Uygulama bugün çalışır ama mantık artık dağınıktır. Birkaç döngü sonra kimse gerçek kuralların nerede yaşadığını bilmiyordur.

Yeniden-oluşturma öncelikli geliştirmede doğruluk kaynağı modellerde kalır:

• Veri modeli: varlıklar, alanlar, ilişkiler, kısıtlar
• İş mantığı modeli: ne olacağını belirleyen kurallar ve akışlar
• UI modeli: ekranlar, bileşenler ve bunların veriye nasıl bağlandığı

Bu modellerden üretilen her şey (API endpoint'leri, veritabanı erişimi, web ve mobil kodu) çıktı olarak kabul edilir; hızlı düzeltmeler için bir yer değildir.

AppMaster'da bu çıktı backend için Go, web uygulaması için Vue3 ve mobil için Kotlin veya SwiftUI içerebilir. Gereksinimler değiştiğinde, aynı kuralı birden fazla dosyada aramak yerine modeli bir kez güncellersiniz ve yeniden üretirsiniz.

Bu, tüm katmanlarda tutarlılığı korur çünkü aynı tanımlar her parçayı besler. Eğer "Ticket Status" zorunlu hale gelirse, veritabanı şeması, doğrulama, API ve UI bağları birlikte güncellenmelidir. Bir onay kuralı değişirse, süreci güncellersiniz; böylece her endpoint ve ekran aynı mantığı gösterir.

Zihniyet değişikliği basittir: demek istediğinizi düzenleyin (modeller), ihtiyaç duyduğunuzu üretin (kod).

Değişebilecek bir veri modeli oluşturun

Yeniden-oluşturma öncelikli geliştirmenin işlemesi için en az değişmesi gereken yerden başlayın: veri modelinden. Değişime uygun uygulamalar, her ekran mükemmel olduğu için değil, temel varlıkların stabil ve iyi adlandırılmış olması sayesinde taleplere dayanır.

İşinizin bir yıl sonra da kullanacağı isimlerle başlayın. Birçok uygulama için bu User, Account, Team, Ticket, Order, Invoice, Product veya Message gibi varlıklar demektir. Bunlar net olduğunda diğer her şey (iş akışları, izinler, UI) sağlam bir temele oturur.

Adlandırma önemsiz değildir. Sonradan yapılan değişikliklerin kafa karıştıran geçişlere ve bozuk mantığa dönüşmesini engeller. Varlıklar için tekil isimler seçin, alan adlarında tutarlılık sağlayın (created_at yerine createdAt gibi tercihlerinizi belirleyin) ve türleri gerçeklikle eşleştirin (para için decimal, zaman damgaları için üzerinde anlaştığınız timezone kuralları). Küçük tutarsızlıklar kurallara, filtrelere ve raporlara yayılır.

Büyümeyi planlayın ama aşırı tasarım yapmayın. Her gelecekteki alanı tahmin etmeniz gerekmez, ama yaygın değişiklik türlerini daha güvenli hale getirebilirsiniz:

• Her aşama için yeni bir tablo eklemek yerine yeni değerlere izin veren durum alanlarını tercih edin.
• Her zaman var olmayan veriler için isteğe bağlı alanlar kullanın (phone_number, external_id).
• Denetim alanlarını erken ekleyin (created_at, updated_at, created_by) böylece daha sonra sonradan düzeltme yapmak zorunda kalmazsınız.
• Deneylerin ana modeli kirletmemesi için "notes" ve "metadata"yı temel alanlardan ayrı tutun.

Görsel bir veri tasarımcısı işe yarar çünkü ilişkileri ve kısıtları koda dönüşmeden önce görebilirsiniz. AppMaster'da Veri Tasarımcısı (Data Designer) şemanızı PostgreSQL'e eşler; böylece tabloları, alanları ve bağlantıları tek bir yerde modelleyebilir ve gereksinimler değiştiğinde temiz kaynak kodu yeniden üretebilirsiniz.

Örnek: bir destek portalı Tickets'ları Accounts ve Users ile ilişkilendirerek başlar. Daha sonra iş, öncelik, kategori ve "Waiting on Customer" adlı yeni bir durum ister. Eğer Tickets zaten bir durum alanına ve detaylar için isteğe bağlı alanlara sahipse, değerler ve alanlar ekleyebilir, veritabanını yeniden tasarlamak zorunda kalmadan devam edebilirsiniz. Yeniden üretilen uygulama sorguları ve API'leri tutarlı tutar ve tek seferlik yamalar kümesinden kaçınırsınız.

Amaç bugünkü okunabilirlik ve yarının hoşgörüsüdür.

İş mantığını modüler ve okunabilir yapın

İş mantığı genellikle değişikliklerin işi bozduğu yerdir. Bugün "sadece işe yarayan" bir hızlı düzeltme yarın özel durumların ağına dönüşebilir. Yeniden-oluşturma öncelikli geliştirmede, mantığı yamalara dayanmayacak şekilde yeniden üretebilecek biçimde tasarlarsınız.

Pratik bir yaklaşım, her iş akışını küçük bloklar kümesi olarak ele almaktır. Her blok tek bir işi yapar: girdileri doğrulamak, fiyat hesaplamak, yönlendirme kararını almak, mesaj göndermek, kaydı güncellemek. AppMaster'da bu doğal olarak İş Süreci Editörü'ne (Business Process Editor) denk gelir. Küçük süreçler daha okunur, test edilebilir, yeniden kullanılabilir ve değiştirilebilir.

Girdi ve çıktılarda düşünün

Bir blok oluşturmadan önce iki şeyi yazın: neye ihtiyaç duyduğu ve ne döndürdüğü. Bunu bir cümleyle açıklayamıyorsanız, blok muhtemelen çok fazla iş yapıyor demektir.

İyi blokların sınırları bellidir. Açık girdiler alır (kullanıcı rolü, ticket durumu, sipariş toplamı) ve açık çıktılar döndürür (onaylandı/ret edildi, nihai fiyat, sonraki adım). Bu netlik, bir bloğu tahmin etmeden değiştirebilmenizi sağlar.

Hızlı kontrol listesi:

• Her blok için tek bir amaç (doğrulama, hesaplama, yönlendirme)
• Girdiler parametre olarak geçirilir, "bir yerlerde bulunmaz"
• Çıktılar döndürülür, yan etkilere gizlenmez
• İsimler sonucu tanımlar (ValidateRefundRequest gibi)
• Hatalar tutarlı şekilde ele alınır

Gizli bağımlılıklardan kaçının

Gizli bağımlılıklar mantığı kırılgan yapar. Bir iş akışı global bayraklara, sessiz durum değişikliklerine veya "bu değişken daha önce bir yerde ayarlandı" varsayımına dayanırsa, küçük düzenlemeler beklenmedik davranış değişimlerine yol açabilir.

Durumu süreç boyunca kasıtlı olarak geçirin. Bir şeyin saklanması gerekiyorsa, bunu belirgin bir yerde (örneğin veritabanı alanı) saklayın ve açıkça okuyun. Bir adımda kaydı değiştirip başka bir adımın bunu fark edeceğini varsaymayın.

Karar noktalarını görünür yapın. Örneğin bir destek portalı "Bu ticket VIP mi?" ve "Mesai dışı mı?" gibi dallanmalara sahip olabilir. Bu dallanmalar açık ve etiketliyse, gelecekteki bir değişiklik ("VIP kuralları hafta sonları için değişti") hızlı bir düzenleme olur, riskli bir yeniden yazma değil.

UI endişelerini kurallar ve veriden ayırın

Değişime uygun bir uygulama, UI "dumb" kaldığında yeniden üretimi en kolay olanıdır. Ekranlar girdi toplamalı, durumu göstermeli ve kullanıcıya rehberlik etmelidir. İş kararları butonların, doğrulamaların veya tek seferlik ekran mantığının içine gizlendiğinde her yeni gereksinim bir yamaya dönüşür.

UI'yi paylaşılan kurallar ve verinin üzerine ince bir katman olarak düşünün. Böylece platform sunumu temiz bir şekilde yeniden inşa edebilir; kararları on ekranda yeniden uygulamak zorunda kalmazsınız.

UI nerede biter, iş kuralları nerede başlar

Pratik bir ayrım: UI netlik sağlar; iş mantığı gerçeği belirler. UI biçimlendirme, etiketleme ve kullanıcı yardımını yapabilir. İş mantığı neyin izinli olduğunu ve sırada ne olduğunu belirler.

UI sorumlulukları genellikle şunlardır:

• Veriyi gösterme ve kullanıcı girişi toplama
• Biçimlendirme (tarihler, para birimi, telefon maskeleri)
• Temel zorunlu alan kontrolleri (boş vs dolu)
• Mantıktan dönen hataları kullanıcıya anlaşılır şekilde gösterme
• Navigasyon ve düzen

İş kuralları ekran dışında, örneğin bir iş süreci veya süreç editöründe yaşamalıdır: "iade için yönetici onayı gerekir", "VIP müşteriler kuyruğu atlar", "ticket çözüm kodu olmadan kapatılamaz". Bu kuralları belirli bir sayfaya değil, veri modeline bağlayın.

Bir kez tasarla, web ve mobilde yeniden kullan

Birden fazla istemci (web ve native mobil) destekliyorsanız, çoğaltma sürüklenmeye yol açar. Ortak desenler için paylaşılan bileşenleri yeniden kullanın (ticket durum rozeti, öncelik seçicisi, müşteri kartı) ama onlara aynı veri ve aynı kural sonuçlarını besleyerek davranışı tutarlı tutun.

Örneğin, ticket durumlarını veri tasarımcısında modelleyebilir, durum değişikliklerini tek bir iş süreci üzerinden yönetebilir ve hem web hem mobil UI'lerin o süreci çağırıp döndürülen durumu render etmesini sağlayabilirsiniz. "Escalated" adı "Urgent review" olduğunda, bunu bir kez güncellersiniz ve yeniden üretirsiniz; her ekranı tek tek aramanıza gerek kalmaz.

İyi bir test: bir ekranı kaldırıp yarın yeniden oluşturduğunuzda uygulama hâlâ aynı kuralları uygular mı? Eğer uygularsa, ayrım işe yarıyor demektir.

Adım adım: temiz yeniden üretim için bir uygulamayı yapılandırma

Yeniden-oluşturma öncelikli geliştirme, uygulamanız açıkça bağımsız değişebilen parçalara ayrıldığında en iyi çalışır. Önce ekranlar değil modüller düşünün.

Temel modülleri adlandırın ve zihninizde ve işinizde ayrı tutun: veri (tablolar ve ilişkiler), süreçler (mantık), API (endpoint'ler), web UI ve mobil UI. Bir gereksinim değiştiğinde, neyin değişeceğini ve neyin dokunulmaması gerektiğini gösterebilmelisiniz.

Değişime uygun kalan bir yapı için derleme sırası

Küçük bir döngü kullanın ve her adımı ölçülü tutun:

1. Önce veriyi modelleyin: gerçeklikle uyuşan varlıklar, alanlar, ilişkiler.
2. Okunabilir, yeniden kullanılabilir iş süreçleri ekleyin. Her süreç tek bir işi yapsın (Create Ticket, Assign Agent, Close Ticket).
3. Mantık okunur hale geldikten sonra süreçleri API endpoint'lerine bağlayın. Endpoint'leri kuralların gizlendiği yerler olarak değil, akışları saran bir katman olarak düşünün.
4. UI ekranlarını veri tabloları yerine kullanıcı görevleri etrafında inşa edin.
5. Her küçük değişiklikten sonra yeniden üretin ve test edin.

Küçük örnek: dağınık yamalar olmadan değişen gereksinimler

Bir destek portalı inşa ettiğinizi varsayın. İlk versiyon Tickets ve Comments ile başlar. Bir hafta sonra ürün ekibi öncelik ve VIP müşteriler için başlangıçta High olacak yeni bir kural ister.

Modüler bir yapıyla veri modelini değiştirirsiniz (Priority ekleyin), bir iş sürecini güncellersiniz (Create Ticket müşteriye göre Priority ayarlar), yeniden üretirsiniz ve aynı UI görevini doğrularsınız. Dağınık düzenlemelere gerek yoktur.

Küçük bir alışkanlık yardımcı olur: her yeniden üretimden sonra temel akışları uçtan uca (oluştur, güncelle, izin kontrolü) hızlıca çalıştırın, sonra bir sonraki özelliğe geçin.

Örnek: sürekli değişen bir müşteri destek portalı

Küçük bir destek portalı hayal edin. Müşteriler giriş yapar, ticket'larını görür, detaylarını açar ve cevap ekler. Destek temsilcileri aynı ticket'ları görür, ayrıca dahili notlara erişir.

Yeniden-oluşturma öncelikli yaklaşım üç şeyi ayırır: ticket veri modeli, iş süreçleri (ticket'ların nasıl hareket ettiği) ve UI ekranları. Bu parçalar net olduğunda birini değiştirmek diğerlerini yamalamak zorunda kalmadan yapılabilir.

Basit başlayın, ama değişime göre yapılandırın

İlk versiyon minimal olabilir:

• Veri: Users, Tickets, Messages
• Süreçler: Create ticket, Reply, Assign to agent
• UI: Ticket list, Ticket details, New ticket form

AppMaster'da bu temiz şekilde PostgreSQL destekli veri modeline (Data Designer), sürükle-bırak mantık için İş Süreci Editörü'ne ve ayrı web/mobil UI oluşturuculara haritalanır.

Değişiklik 1: öncelik ve SLA tarihleri ekleme

Ürün ekibi Priority (Low, Normal, High) ve bir SLA bitiş tarihi ister. Yeniden-oluşturma öncelikli yapıda Ticket modeline alanlar eklersiniz; sonra sadece bu alanları okuyan/yazan yerleri güncellersiniz: create-ticket süreci müşteri tipine göre varsayılan priority atar, temsilci ekranı SLA tarihini gösterir ve liste ekranı filtre ekler.

Platform backend ve API'yi yeniden üretir, böylece yeni alanlar kodun birinci sınıf parçaları haline gelir.

Değişiklik 2: kapatmadan önce onay adımı ekleme

Artık ticket kapatmak belirli müşteriler için yönetici onayı gerektiriyor. Kapatma kurallarını birçok ekrana serpmek yerine modele net bir durum ekleyin (Open, Pending approval, Closed) ve close sürecini güncelleyin:

• Temsilci kapatma isteği gönderir
• Sistem onay gerekip gerekmediğini kontrol eder
• Yönetici onaylar veya reddeder
• Onaydan sonra ticket kapatılır

Kural tek bir süreçte yaşadığı için UI mevcut durumu ve izin verilen sonraki eylemi gösterir.

Değişiklik 3: mobil push bildirimleri

Kullanıcılar temsilci yanıtı geldiğinde push bildirim almak istiyor. Bildirim mantığını UI kodunun içine gömmeyin. "New message" sürecine, cevap kaydedildiğinde bir bildirim modülü tetiklemesi ekleyin. Yeniden üretim, güncellenmiş native uygulamalar üretir; böylece değişiklikler manuel yamalara dönüşmez.

Yeniden-oluşturmaya engel olan yaygın hatalar

Yeniden-oluşturma öncelikli geliştirme ancak uygulamanız yeniden üretilebilirse işe yarar. Ekipler genellikle bugün zararsız görünen hızlı düzeltmelerle bunu bozar ve yarın için işar yaparlar.

1) Üretilen kodu düzenlemek yerine modeli değiştirmemek

Üretilen parçalarla manuel düzenlemeleri karıştırmak, temiz yeniden üretimi kaybetmenin en hızlı yoludur. Eğer bir platform gerçek kaynak kodu (AppMaster gibi backend, web ve mobil için) üretiyorsa, görsel projeyi kaynak olarak kabul edin. Bir gereksinim değiştiğinde veri modelini, iş sürecini veya UI builder'ı güncelleyin.

Basit bir kural: değişikliği görsel projeden yeniden üreterek çoğaltamıyorsanız, o güvenli bir değişiklik değildir.

2) UI'nin kuralları belirlemesine izin vermek

Ekranlar iş kurallarını kodladığında ("bu buton sadece VIP kullanıcılar için görünür", "bu form toplamları UI'da hesaplar"), her yeni ekran özel duruma dönüşür. İzinleri, hesaplamaları ve doğrulamaları iş mantığında (örneğin İş Süreci) tutun; UI sadece sonucu gösterir.

3) Hayali veri modelini erken tasarlamak

Aşırı modelleme, gerçek kullanım olmadan düzinelerce alan, durum ve kenar durum tablosu eklemek gibidir. Her güncelleme çok fazla parçayı etkilediğinden değişiklikleri acı verici yapar.

Bilinenle başlayın, sonra küçük adımlarla genişletin:

• Sadece düz bir dilde açıklayabileceğiniz alanları ekleyin.
• Durum değerlerini kısa ve gerçek tutun (3-6, 20 değil).
• Anlamı bir dev tabloya sıkıştırmaktansa ileride yeni bir tablo eklemeyi tercih edin.

4) Adlandırma kurallarını atlamak

Tutarsız isimler kafa karıştırıcı modeller ve endpoint'ler yaratır: "Cust", "Customer" ve "Client" aynı uygulamada. Yeniden üretim yine çalışır ama insanlar değişiklik yaparken hata yapar.

Basit bir desen seçin (tekil tablo isimleri, eylemler için tutarlı fiiller) ve buna sadık kalın.

5) Bir devasa iş akışı inşa etmek

Bir büyük iş akışı başlangıçta düzenli görünebilir, ama zamanla güvenle değiştirilemez olur. Mantığı açık girdiler ve çıktılar olan küçük süreçlere ayırın. Bir destek portalında "Create ticket", "Assign agent" ve "Send notification"'ı ayrı tutun ki bir adımı değiştirirken diğerleri risk altında olmasın.

Yeniden üretmeden ve yayına almadan önce hızlı kontroller

Yeniden-oluşturma öncelikli geliştirme yalnızca rutinleriniz ortak "sessiz kırılma" sorunlarını yakalayabiliyorsa güvenli hisseder. Yeniden üretmeden önce uygulamanızın nasıl yapılandırıldığını yansıtan kısa bir geçiş yapın: veri, mantık, UI ve API'ler.

Hızlı kontrol listesi:

• Veri: varlıklar ve alanlar güncel gereksinimlerle uyumlu, isimler tutarlı ve aynı anlama gelen iki alan yok.
• Mantık: her süreç net bir girişe, net bir çıkışa ve öngörülebilir hata yoluna sahip.
• UI: ekranlar paylaşılan bileşenleri yeniden kullanıyor ve kuralları sert kodlamıyor.
• API'ler: endpoint'ler süreçlerle tutarlı şekilde eşlenmiş. "Bu endpoint hangi süreci çalıştırıyor?" sorusuna kazma gerektirmeden cevap verebiliyorsunuz.
• Sürüm: "tıkla bakalım" yerine küçük, tekrarlanabilir bir test senaryonuz var.

Kurallar için tek bir doğruluk kaynağını koruyun. Eğer ticket önceliği müşteri seviyesine bağlıysa, bunu tek bir süreçte tanımlayın; hem API hem UI aynı sonucu göstersin.

10 dakikalık bir test senaryosu genellikle yeterlidir:

• Sadece zorunlu alanlarla yeni bir kayıt oluşturun.
• Ana süreci tetikleyin ve beklenen durum değişikliğini doğrulayın.
• Bir hata durumu deneyin (izin eksikliği veya zorunlu veri eksikliği).
• Ana ekranları web ve mobile'da açıp aynı kuralın aynı şekilde göründüğünü doğrulayın.
• Bir veya iki temel endpoint'i çağırın ve yanıtların UI ile eşleştiğini kontrol edin.

Eğer bir şey başarısız olursa, önce yapıyı düzeltin (veri, süreç, paylaşılan UI) ve tekrar yeniden üretin.

Sonraki adımlar: bir sonraki değişikliğinize bu yaklaşımı uygulayın

İlk önce bir alan seçin ve kapsamı küçük tutun. Son zamanlarda hangi değişiklikler acı vericiyse, ondan başlayın: veri modeli, karışmış bir mantık parçası veya sürekli "bir ayar daha" yapılan bir ekran.

Bir sonraki değişikliği bir tatbikat gibi ele alın: düzenle, yeniden üret, doğrula, yayınla. Amaç, güncellemelerin rutin, riskli değil, hissettirmesidir.

Tekrarlayacağınız basit döngü:

• Bir küçük değişiklik yapın (bir alan, bir kural veya bir ekran davranışı).
• Kodun tutarlı kalması için yeniden üretin.
• Hızlı bir dumbo testi çalıştırın (mutlu yol + bir uç durum).
• Önce güvenli bir ortama deploy edin (staging veya test workspace).
• Öğrendiklerinizi kısa bir not halinde yazın.

Kısa bir değişiklik günlüğü kararları açıklar, sadece düzenlemeleri değil. Örneğin: "Ticket priority enum olarak saklanır, serbest metin değil, böylece etiketler değiştiğinde raporlar bozulmaz." Böyle iki satır ileride saatler kazandırır.

Eğer üretilen çıktıyı el ile düzenlemeden pratik yapmak istiyorsanız, AppMaster'da küçük, izole bir modül oluşturun (örneğin bir ticket formu, bir yönetici listesi veya basit bir onay adımı), her değişikten sonra yeniden üretin ve modelin kaynak otorite olduğunda uygulamayı evrilmenin ne kadar kolay olduğuna dikkat edin. Eğer araçları değerlendiriyorsanız, appmaster.io bu iş akışıyla denemeler yapmak için uygun bir başlangıç yeridir.

Bir sonraki değişikliğiniz iyi bir başlangıçtır. Uygulamanın bir köşesini seçin ve bugünden değişime uygun hale getirin.