Yazılım geliştirme sürecimiz nasıl işliyor, özetleyelim.
Bulut tabanlı bir yazılımı bir işletmenin günlük işine sokmak, kod yazmaktan çok daha geniş bir iş. Otel, restoran, yurt ya da KOBİ fark etmiyor: sistemin gerçek hayatta tutunması, doğru soruları doğru sırayla sormaya bağlı. Aşağıda kendi ürünlerimizi geliştirirken izlediğimiz süreci, web ve mobil tarafını birlikte ele alarak anlatıyoruz. Mobil uygulamalarımızı Dart ile geliştiriyoruz; tek kod tabanından hem iOS hem Android çıkması, küçük bir ekip için belirleyici bir avantaj.
Süreç bir bütün: on aşama
Aşamaları sırayla anlatmak açıklayıcı oluyor, ama gerçekte hiçbiri kapanıp bitmiyor. Testte çıkan bir bulgu kavramsal tasarıma, sahadan gelen bir geri bildirim entegrasyon kararına dönebiliyor. Şemadaki kesikli çizgi tam olarak bunu gösteriyor.
1. Keşif ve analiz
İlk iş, yazılımın ne yapacağını değil, işletmenin bugün nasıl çalıştığını anlamak. Resepsiyonun vardiya devrinde hangi kâğıdı doldurduğunu, muhasebenin ay sonunda hangi dosyayı elle düzelttiğini görmeden yazılan ekran, sahada ilk günde tıkanıyor.
Bu aşamada üç şeyi yazıya döküyoruz: mevcut akış, acı veren noktalar ve ölçülebilir hedef. "Daha hızlı check-in" hedef değil; "check-in süresi ortalama üç dakikadan bir dakikanın altına insin" hedef. Ölçülebilir olmayan hedef, devreye alma sonrasında tartışmaya dönüşüyor.
Aynı aşamada mevcut sistemlerin envanterini çıkarıyoruz: hangi muhasebe programı, hangi kanal yöneticisi, hangi cihazlar, hangi veri nerede duruyor. Entegrasyon maliyetinin büyük kısmı burada belli oluyor.
2. Kavramsal tasarım
Kavramsal tasarım, kod yazmadan önce sistemin zihinsel modelini kurma aşaması. Üç çıktısı var: veri modeli, ekran akışı ve tıklanabilir prototip.
Veri modeli en kritik olanı. Bir rezervasyonun odayla mı, oda tipiyle mi ilişkilendiğini baştan yanlış kurarsanız, bunun bedelini iki yıl boyunca her raporda ödüyorsunuz. Ekran akışı ise mobil ve web için ayrı düşünülüyor: resepsiyon masasında geniş bir oda planı mantıklıyken, kat görevlisinin telefonunda tek elle kullanılabilen üç butonluk bir ekran gerekiyor.
Prototipi işletmeye gösterip gerçek senaryoyu tıklattırmak, bu aşamanın en ucuz sigortası. Prototipte on dakikada değişen bir karar, geliştirme bittikten sonra haftalara mal oluyor.
3. Mimari ve teknoloji kararları
Burada dört soruyu cevaplıyoruz: Veri nerede duracak? Sistem çok kiracılı mı olacak? İnternet kesildiğinde ne olacak? Yük arttığında ne büyüyecek?
Bulut kurulumu güncelleme, yedekleme ve her yerden erişim demek. Ama sezonun ortasında internet kesilen bir sahil otelinde resepsiyonun durması kabul edilebilir değil. Bu yüzden kritik ekranların çevrimdışı çalışıp bağlantı gelince eşitlenmesi, mimarinin en başında verilmesi gereken bir karar; sonradan eklenen bir özellik değil.
Mobil ve web aynı API'yi kullanıyor. Bu, iki ayrı ekip yazmış gibi birbirinden sapan iki uygulama çıkmasını engelliyor. İş kuralları sunucuda tek yerde duruyor; istemci yalnızca sunuyor ve topluyor.
4. Entegrasyon tasarımı
Entegrasyonlar, projelerin en çok hafife alınan kısmı. Kanal yöneticisi, e-Fatura, kimlik bildirimi, ödeme, mesajlaşma, muhasebe: her biri başka bir kurumun sistemi, başka bir hata anlayışı, başka bir kesinti takvimi.
Öğrendiğimiz şu: dış servise doğrudan, senkron çağrı yapmak en kırılgan yöntem. Servis yavaşladığında sizin ekranınız donuyor. Onun yerine olayı kendi tarafımızda kuyruğa yazıyor, gönderimi ayrı bir işleyiciye bırakıyoruz.
Üç detay burada hayat kurtarıyor. Tekillik anahtarı: aynı fatura iki kez gönderilse bile karşı tarafta tek kayıt oluşuyor. Artan aralıkla yeniden deneme: karşı sistem kısa süre kapalıysa işlem kaybolmuyor, belli aralıklarla tekrar deneniyor. Görünür durum: başarısız kalan gönderim sessizce kaybolmuyor, kullanıcının gördüğü bir listede "bekliyor" ya da "hata" olarak duruyor. Entegrasyonun sessiz başarısızlığı, açık hatadan çok daha pahalı.
5. Geliştirme
Geliştirme, sözleşmenin belirlenmesiyle başlıyor: API uçları, alan adları, hata kodları. Sözleşme netse web ve mobil paralel ilerleyebiliyor.
Dart tarafında tek kod tabanından iki platforma çıkmak zaman kazandırıyor, ama her şeyi ortaklaştırmak doğru değil. Bildirim izinleri, kamera ve belge okuma, arka planda çalışma gibi konularda iki platform farklı davranıyor; bunları baştan ayrı ele almak sonradan yamamaktan ucuz.
Bu aşamada yapay zekâ destekli kod asistanlarından yoğun şekilde yararlanıyoruz. Tekrarlayan katmanları çıkarmak, test verisi üretmek, eski bir ekranı yeni desene taşımak gibi işlerde ciddi hızlanma sağlıyor. Ama iki kuralımız var: üretilen kod, insan yazmış gibi gözden geçirilmeden birleştirilmiyor; ve iş kuralı testle doğrulanmadan doğru sayılmıyor. Asistan hızı artırıyor, sorumluluğu değiştirmiyor.
6. Test ve doğrulama
Testi tek bir faaliyet olarak düşünmek yanıltıcı. Katmanları var ve her katman başka bir soruyu cevaplıyor.
Alt katmanlar hızlı ve ucuz olduğu için her değişiklikte çalışıyor. Üst katmanlar pahalı, o yüzden az sayıda ama kritik yolları kapsıyor: giriş, ödeme, çıkış. Sahada kabul testi ise vazgeçilmez; laboratuvarda çalışan bir ekran, gerçek bir tesiste yirmi odalık bir grup girişinde bambaşka davranabiliyor.
Mobilde ayrıca cihaz çeşitliliği var. Eski bir Android telefonda listenin nasıl kaydığını, küçük ekranda butonun parmakla gerçekten basılabildiğini denemek gerekiyor.
7. Güvenlik ve KVKK
Bu aşama genelde listede unutuluyor, oysa misafir kimliği, çalışan bilgisi ve ödeme verisiyle çalışıyorsanız en baştan planlanması gerekiyor.
Uygulamada dört başlık: kim neyi görebilir sorusunun yanıtı olan yetki matrisi; verinin aktarımda ve diskte şifrelenmesi; ne kadar süre saklanacağının ve nasıl silineceğinin belirlenmesi; ve kimin hangi kaydı ne zaman değiştirdiğini gösteren iz kaydı. Bu dördü sonradan eklenmiyor, mimariye giriyor.
8. Optimizasyon
Optimizasyon, sistem çalışır hale geldikten sonra ölçüme dayalı yapılması gereken bir iş. Tahminle yapılan iyileştirme genellikle yanlış yeri düzeltiyor.
Üç cephede bakıyoruz. Veritabanı: en çok çağrılan sorgular, eksik indeksler, gereksiz veri çeken listeler. Ağ ve mobil: istek sayısını azaltmak, sayfalı veri çekmek, telefonun pilini ve veri kotasını korumak. Bulut maliyeti: ölçeklenen kaynakların gerçekten ihtiyaç anında büyümesi, boşta çalışan servislerin kapanması.
9. Devreye alma ve geçiş
Devreye alma, teknik bir işlem değil, bir geçiş projesi. En riskli kısmı da kod değil, veri.
Eski sistemden gelen rezervasyon, cari ve misafir kayıtlarını önce provada aktarıyoruz; sayılar tutuyor mu, karakterler bozulmuş mu, açık bakiyeler doğru mu diye kontrol ediyoruz. Gerçek geçişi ise sezon dışı, tercihen hafta sonu yapıyoruz.
Kademeli yayın, tek seferde herkese açmaktan çok daha güvenli. Pilotta bir tesis, ekip yakın izlemede; sorun çıkarsa özellik anahtarı kapatılıp önceki sürüme dönülüyor. Eğitim de bu aşamanın parçası: yerinde ya da uzaktan, kendi verileriyle. Kullanıcının ilk gün "bunu nereden yapıyordum" diye takıldığı yer, projenin gerçek sınavı.
10. İzleme ve sürekli iyileştirme
Yayın, sürecin sonu değil. Hata takibi, kullanım verisi ve kullanıcı geri bildirimi bir sonraki sürümün gündemini oluşturuyor. Hangi ekranın en çok kullanıldığını, hangi adımın yarıda bırakıldığını, hangi hatanın kaç kullanıcıda tekrarlandığını görmeden yapılan yol haritası, tahminden ibaret kalıyor.
Mobilde buna mağaza döngüsü de ekleniyor: sürüm notu, mağaza incelemesi ve eski sürümde kalan kullanıcılar. Bu yüzden istemciyi kırmayan API değişikliği disiplini, mobil uygulaması olan her projede zorunlu hale geliyor.
Özetle
Bulut tabanlı web ve mobil yazılım geliştirmenin zor kısmı teknoloji seçimi değil; işi anlamak, entegrasyonları dayanıklı kurmak ve geçişi kimseyi işinden etmeden yapmak. Süreç böyle kurulduğunda yazılım, işletmenin üzerine binen bir yük değil, işin kendisini kolaylaştıran bir araç oluyor.
Kendi işletmeniz için benzer bir süreci konuşmak isterseniz, demo talep edebilirsiniz; hangi aşamada olduğunuza bakıp yol haritasını birlikte çıkaralım.