Her müşteri kendine özel geliştirme istiyor: ürünü tek kod tabanında nasıl tutarsınız?

Müşteri "bizde onay iki aşamalı olacak" dediğinde cevabınız üç kovadan birine düşmeli: ayarı veri olarak tutan bir konfigürasyon, planın ya da sözleşmenin verdiği bir hak (entitlement), veya ürünün önceden açtığı bir uzantı noktası. Dördüncü seçenek, yani o müşteriye özel bir kod dalı, bir çözüm değil ertelenmiş bir fatura. Microsoft'un çok kiracılı çözümler için yayımladığı mimari kontrol listesi bunu açıkça dağıtım antipatterni sayıyor: her kiracı için çözümün ayrı sürümlerini çalıştırmak, kiracıya özel yapılandırmayı veya iş mantığını koda gömmek ve elle dağıtıma güvenmek. Zor olan kısım mekanizmayı kurmak değil, gelen her talebi doğru kovaya koyacak kararı verebilmek.

"Özel geliştirme" tek bir şey değil

Aynı cümleyle gelen dört farklı talep var ve dördü farklı maliyet taşıyor.

Görünüm ve markalama. Logo, renk, kendi alan adı, e-postanın altındaki imza bloğu. Burası neredeyse her zaman konfigürasyondur ve kod yazmayı gerektirmez.

İş kuralı parametresi. Onay eşiği, vade günü, vardiya başlangıcı, kaç gün sonra hatırlatma gideceği. Bunlar da veridir, ama başıboş veri değil: her birinin tipi, varsayılanı ve geçerlilik kuralı olmalı.

Entegrasyon ucu. Müşterinin kendi ERP'sine, muhasebesine veya kargo sağlayıcısına bağlanma. Bu ne ayar ne kural, ayrı bir eşleme katmanı.

Gerçekten yeni davranış. Başka hiçbir müşterinin istemediği bir ekran ya da hesaplama. Tartışmaya değen tek kova bu. Diğer üçü için zaten hazır bir mekanizmanız olmalı, yoksa her sözleşme size yeni bir dal açtırır.

Ayarı koda değil veriye yazın

Pratik bir test var: bir müşterinin ayarını değiştirmek için yayın almanız gerekiyorsa, o ayar yanlış yerde duruyor. Kiracıya özel değerler kodda if (musteriId == 42) olarak değil, bir yapılandırma tablosunda durmalı. Bunun maliyeti düşük, geri dönüşü yüksek: aynı sürüm herkeste çalışır, destek ekibi sizi aramadan ayarı değiştirir, bir sonraki sürümde o satır kimseyi şaşırtmaz.

Her ayarın beş alanı olsun: anahtar adı, tipi, varsayılan değeri, kimin değiştirebileceği ve geçerlilik kuralı. Varsayılan ürün genelinde tanımlıdır, müşteri bazlı değer onun üzerine yazar. Bir de kim ne zaman değiştirdi kaydı tutun. Üç ay sonra "bu eşik niye 7 gün olmuş" sorusunun cevabı sadece denetim izinde olacak.

Lisans hakkı ile özellik bayrağı aynı şey değil

Burada çok yaygın bir hata var: paket farklarını özellik bayrağıyla yönetmek. Microsoft'un aynı rehberi bunu doğrudan uyarıyor. Belirli müşteriler için belirli özellikleri açmanız gerekebileceğini, bunun genellikle fiyat kademeleriyle ilgili olduğunu, ancak özellik bayraklarının bu senaryolar için doğru araç olmadığını söylüyor ve her müşterinin lisans haklarını izleyip uygulayan ayrı bir süreç kurmayı öneriyor.

Sebebi ömür farkı. Martin Fowler'ın sitesinde yayımlanan ve Pete Hodgson'ın yazdığı feature toggle sınıflandırması dört tip tanımlıyor ve bunları ömürlerine göre ayırıyor. Release toggle geçicidir, kararı statiktir, iş bitince silinir. Permissioning toggle ise diğer kategorilere kıyasla çok uzun ömürlü olabilir ve kararı her istekte yeniden verilir. İkisini aynı tabloda tutarsanız iki yıl sonra kimse hangi anahtarın temizlenebileceğini bilemez, bir bayrağı silerken müşterinin para ödediği bir özelliği kapatırsınız.

Ayrımı en baştan kurun. Bayrakların sahibi ve son kullanma tarihi vardır, mühendislik temizler (kademeli yayın yazısında anlattığımız düzen). Hakların sözleşmesi vardır, satış ve destek değiştirir, faturalamaya bağlanır. İki ayrı mekanizma, iki ayrı ekran.

Gerisi için uzantı noktası açın

Büyük platformlar bu problemi yıllar önce çözdü ve çözümün adı uzantı noktası. Shopify, ödeme adımını özelleştirmek isteyen geliştiricileri tema dosyasını düzenlemekten çıkarıp uygulama uzantılarına taşıdı. Kendi dokümanında bunun gerekçesini de yazıyor: özelleştirme seçeneklerinin kurulumu kolay ve yükseltmeye dayanıklıdır (upgrade-safe), böylece platform yeni özellik yayımladığında satıcılar bundan faydalanmaya devam eder. Çekirdeğin yapısı platformun elinde kalır, dışarıya sadece belirli noktalar açılır.

SAP'ın S/4HANA için anlattığı "clean core" yaklaşımı aynı fikrin kurumsal versiyonu. Hedef tek cümleyle özetleniyor: özel uzantılar yükseltmeyi bozmaz, yükseltmeler de uzantıyı bozmaz. Şart ise uzantının standart nesnelere sadece serbest bırakılmış (released), yükseltmeye dayanıklı arayüzler üzerinden erişmesi. SAP ayrıca bir sıra öneriyor: önce yönetici araçlarıyla yapılabilecek alan ve kural eklemeleri, sonra çekirdeğin yanında ayrı çalışan uzantılar.

Küçük bir üründe bunun karşılığı pahalı değil. Kullanıcı tanımlı alanlar, belge ve e-posta şablonları, dışa ve içe aktarım, basit kural ifadeleri, bir API ve giden webhook. Tek uyarı: açtığınız her kanca bir sözleşmedir. Bugün eklediğiniz uzantı noktası yarın uymak zorunda olduğunuz bir arayüz olur, o yüzden sürümleme ve geriye dönük uyumluluk kuralları burada da geçerli.

Müşteriye özel dal neden en pahalı yol

Fork'un maliyeti ilk gün görünmez. Dal açılır, müşteri memnun olur, satış kapanır. Fatura altıncı aydan sonra gelmeye başlar. Kritik bir güvenlik yaması çıktığında onu her dal için ayrı uygularsınız. Kütüphane yükseltmesinde her dalda ayrı çakışma çözersiniz. Bir hata raporu geldiğinde önce "bu müşteri hangi sürümde" sorusunu cevaplarsınız.

En sinsi kısım ise şu: forklu müşteri bir süre sonra yükseltmeyi reddetmeye başlar, çünkü her yükseltme onun özel kısmını riske atıyordur. Böylece kendi ürününüzün en eski sürümünü yıllarca desteklemek zorunda kalırsınız. WordPress dünyasının yıllardır tekrarladığı "ana temayı değiştirme, alt tema yaz" kuralı tam olarak bu yüzden var: üzerine yazdığınız her satırı bir sonraki güncelleme siler. Bu yük muhasebe defterinde görünmez ama teknik borç olarak her sprintten pay alır.

Konfigürasyon da bedava değil

Tersi yöne de fazla sapmayın. Her yeni ayar test yüzeyini büyütür. Birbirinden bağımsız on açma kapama ayarı 1024 olası kombinasyon demek ve hiçbir ekip bunu test etmiyor. Ayarları sınırsız çoğaltan ürünler bir süre sonra "bizde çalışıyor" ile "bizde çalışmıyor" arasındaki farkı açıklayamaz hale gelir.

Üç kural işi kurtarıyor. Her ayarın bir varsayılanı olur ve asıl test edilen yol varsayılan yoldur. Kapatılabilen her özellik için kapalı hâlin de bir testi olur, çünkü kapalıyken patlayan ekranları kimse fark etmez. Kombinasyonları değil profilleri test edin: gerçek müşterilerinizden türetilmiş üç beş "örnek kiracı" tanımlayıp regresyonu onların üzerinde koşturun. Test piramidi ve kapsama tartışması burada somut bir karşılık buluyor.

Bir de şunu kabul edin: ayar eklemek de bir ürün kararıdır. Adı, dokümanı, varsayılanı ve geri alma yolu olmayan ayar, destek ekibine bırakılmış bir tuzaktır.

Talebi hangi kovaya koyacağınıza beş soruyla karar verin

Her "bize özel" talebi geldiğinde sırayla şunları sorun.

• Kaç müşteri bunu ister? Bir müşteri isterse hak veya uzantı. Üç ve üzeri isterse konfigürasyon. Çoğunluk isterse zaten varsayılan davranışı değiştirmeniz gerekiyor.
• Standart akışın yanına mı ekleniyor, içine mi giriyor? Yanına ekleniyorsa uzantı noktası yeter. İçine giriyorsa bu bir ürün kararı ve yol haritasına girmesi gerekir.
• Veriyle mi çözülür, kodla mı? Cevabı "bir alan daha" olan taleplerin çoğu aslında veri modeli konusudur, orada yanlış kurulmuş bir yapıyı veri modeli yazısındaki hatalarla birlikte okuyun.
• Müşteri ayrılırsa geri alınabilir mi? Geri alınamayan her şey kalıcı bakım yüküdür.
• Üç yıl sonra kim bakacak ve bunun bedelini kim ödüyor? Cevabı olmayan talep, cevabı "herkes" olan taleple aynı şeydir.

Bir onay kapısı koyun

SAP'ın kurumsal ölçekte kullandığı yaklaşımın can alıcı tarafı teknik değil yönetişimsel: uzantı yolları sınıflandırılıyor, bir kısmı önerilen, bir kısmı ancak başka seçenek kalmadığında ve mimari onayıyla kabul edilen, bir kısmı ise doğrudan yasak olarak işaretleniyor.

Beş kişilik bir ekipte bunun karşılığı komite kurmak değil, tek bir isim belirlemek. Standart dışı her talebin ürün sahibinin onayından geçmesi ve kararın tek paragrafla yazılı olması yeter: talep ne, hangi kovaya kondu, neden, bakımını kim üstleniyor. Belge önemli değil, "hayır" diyebilen bir mercinin varlığı önemli. Böyle bir merci yoksa mimarinizi satış görüşmeleri belirler ve bunu altı ay boyunca fark etmezsiniz.

Özel geliştirme satıyorsanız doğru fiyatlayın

Müşteriye özel iş yapmak yanlış değil, onu ürün fiyatının içine gömmek yanlış. Üç kalem ayrı dursun: bir defalık geliştirme bedeli, o işin yıllık bakım bedeli ve ileride standart ürüne dönme seçeneği. Sözleşmede kodun kime ait olduğu, hangi sürüm hattında destekleneceği ve yükseltme sorumluluğunun kimde olduğu yazılı olsun. Sabit fiyat ile zaman malzeme arasındaki risk dağılımı ve bakım sözleşmesinde olması gereken maddeler bu konuşmanın zeminini kuruyor.

Elinizde zaten fork varsa

Dört adımlı bir çıkış planı işe yarıyor. Önce envanter: kaç dal var, hangi müşteriye ait, hangi dosyalara dokunuyor. Sonra fark analizi: dalları çekirdekle karşılaştırıp değişikliklerin listesini çıkarın. Üçüncü adım ortak paydayı bulmak, çünkü pratikte farkların büyük kısmı birkaç ayara ve bir iki şablona iner. Son adım kalan gerçek farkları uzantı noktasına taşıyıp dalı kapatmak.

Bu bir yeniden yazma projesi değil, bir temizlik işi. Her dalı aynı anda kapatmaya çalışmayın, en çok acıtan iki tanesiyle başlayın ve sonraki yükseltmede kaç saat kazandığınızı ölçün.

Bu haftaya sığan üç adım

Bir: son altı ayda "bu müşteriye özel" diye yazılmış kodu arayın. Müşteri kimliğinin koşul olarak geçtiği yerler ve ana hattan ayrılmış dallar iyi bir başlangıç listesi verir.

İki: özellik bayraklarınızla paket haklarınızı aynı yerde tutuyorsanız ayırın. Hangi anahtar mühendisliğin geçici anahtarı, hangisi müşterinin parasını ödediği hak, bu listeyi bugün çıkarabilirsiniz.

Üç: bir sonraki özel talep geldiğinde beş soruyu yazılı cevaplayın ve kararı bir yere kaydedin. Üç ay sonra bu kayıt, hangi kovanın gerçekten işe yaradığını gösteren tek veri olacak.

Wedevit olarak ürünü tek kod tabanında tutan konfigürasyon katmanını kuruyor, lisans haklarını özellik bayraklarından ayırıyor, uzantı noktalarını sürümlenebilir bir arayüz olarak tasarlıyor ve mevcut müşteri dallarını çekirdeğe geri taşıyan plan çıkarıyoruz. Somut ilk adım: bugün bir güvenlik yaması yayımlasanız, bunu kaç ayrı sürüme uygulamanız gerektiğini tek bir ekrandan söyleyebilir misiniz?