Uçtan uca sorumluluk: BGB'de katmanların birbirine etkisi

01Ürünün bağlamı

BGB, kumar zararlarını azaltmaya yönelik bir dijital ürün. Konunun hassas olduğunun farkındayım; bu yüzden bu notta ürünün etkisi hakkında bir iddiada bulunmuyorum. Anlatmak istediğim şey, böyle bir ürünün yazılım tarafını uçtan uca üstlenmenin nasıl bir iş olduğu. Bu bir şirket projesi. Ürünün analiz, tasarım ve geliştirme süreçlerini yürüttüm; mobil uygulama, backend algoritmaları, yönetim paneli ve web arayüzü olmak üzere tüm yazılım katmanlarında sorumluluk aldım.

Hassas bir alanda çalışırken bence en doğru tutum, ürünü kullanacak kişiye saygıyla yaklaşmak ve arayüzün dilini sade tutmak. Yazılımın görevi burada gösteriş değil; güvenilir, anlaşılır ve tutarlı davranmak. Bu, dil seçiminden hata mesajlarının tonuna kadar küçük kararları da etkiliyor.

02Dört yüzey, tek ürün

Mobil kullanıcı deneyimi React Native ve Expo ile, web ve yönetim yüzeyleri Next.js ile geliştirildi. Servisler NestJS ve PostgreSQL üzerinde çalışıyor, veri erişiminde Prisma var. Bu dört yüzeyi ayrı projeler gibi düşünmek mümkün, ama BGB'de hepsi aynı ürünün birbirini tamamlayan parçaları. Mobil akışların, verinin ve yönetim araçlarının birlikte işlemesi gerekiyor.

React Native + Expo (mobil)      Next.js (web)      Next.js (yönetim)
            \                         |                    /
             +---------- NestJS servisleri ---------------+
                                 |
                        Prisma -> PostgreSQL

Bu yerleşimin önemli bir sonucu var: hiçbir yüzey kendi başına “bitmiş” sayılamıyor. Mobilde bir ekranın davranışı, servis katmanının ne döndürdüğüne; yönetim panelinde bir aracın kullanışlılığı, verinin nasıl modellendiğine bağlı. Bu yüzden bir yüzeyde yapılan iş, diğerlerinde de kontrol edilmeden tamamlanmış sayılmamalı.

03Bir katmandaki karar

Uçtan uca sorumlulukta en net gördüğüm şey, bir katmanda verilen kararın diğerlerinde mutlaka bir karşılığı olduğu. Veri modelinde bir alanı nasıl tanımladığınız, servisin o alanı nasıl sunduğunu belirliyor. Servisin sunuş biçimi, mobil uygulamanın o veriyi nasıl göstereceğini ve hangi durumları ele alması gerektiğini belirliyor. Yönetim panelinin aynı veriyi nasıl düzenleyebileceği de yine aynı modele bağlı.

Katmanlar farklı kişilerde olduğunda bu zincir toplantılarla ve belgelerle yönetilir. Hepsi aynı kişide olduğunda ise başka bir risk doğuyor: zinciri kafanızda tuttuğunuz için açıkça yazmayı ihmal etmek. Bu yüzden bence uçtan uca çalışırken bile katmanlar arasındaki anlaşmaları açıkça tanımlamak gerekiyor.

Bir katmandaki küçük bir karar, öbür uçta bir ekranın davranışı olarak geri döner.

04Servis sözleşmeleri

Mobil deneyim, servis sözleşmeleri ve yönetim ihtiyaçlarını birlikte ele almaya çalıştım. Servis sözleşmesi derken, bir uç noktanın ne aldığı, ne döndürdüğü ve hangi durumlarda nasıl davrandığı konusundaki anlaşmayı kastediyorum. Mobil uygulamalarda kullanıcıların elindeki sürümler genelde web kadar hızlı güncellenmez. Bu, her mobil üründe geçerli genel bir durum ve sözleşmelerin dikkatle değiştirilmesi gerektiği anlamına geliyor.

TypeScript'in bütün katmanlarda ortak dil olması burada yardımcı oluyor; aynı kavramın mobilde, webde ve serviste aynı biçimde düşünülmesini kolaylaştırıyor. Ama ortak dil tek başına yetmiyor, sözleşmenin kendisinin de bilinçli tasarlanması gerekiyor.

05Yönetim ihtiyaçları da ürünün parçası

Yönetim paneli çoğu projede en son düşünülen yüzey oluyor. Oysa bir ürünün sürdürülebilirliği, onu yönetenlerin işini ne kadar rahat yapabildiğine de bağlı. Arayüz ve backend akışlarını ürünün ortak ihtiyaçları üzerinden ele almak, yönetim tarafını sonradan eklenen bir ek değil, baştan düşünülen bir yüzey yapıyor. Yönetim aracı zayıf kaldığında, ürünün geri kalanı ne kadar iyi olursa olsun günlük işleyiş zorlaşır.

Analiz ve tasarım süreçlerini de yürüttüğüm için, bir ihtiyacı ilk duyduğum andan itibaren onun mobilde, servis katmanında ve yönetim tarafında neye dönüşeceğini birlikte düşünebildim. Bence uçtan uca sorumluluğun en değerli yanı tam olarak bu: kararın bütün sonuçlarını aynı anda görebilmek.

06Bedeli ve kazancı

Bütün katmanlarda sorumluluk almak, bağlam değiştirme yükünü de beraberinde getiriyor. Aynı gün içinde bir mobil ekranın detayından bir sorgunun yapısına geçmek dikkat istiyor. Buna karşılık kazanç da büyük: bir sorunun hangi katmandan kaynaklandığını daha hızlı görmek ve çözümü doğru katmana koymak. Bir hatayı arayüzde gizlemek yerine kaynağında düzeltmek, ancak bütün zinciri gördüğünüzde mümkün oluyor. Ayrıca bir özelliği tasarlarken onun maliyetini bütün katmanlarda birden tahmin edebilmek, kapsam konuşmalarını daha gerçekçi kılıyor.