Yazılım bakımını sistemi yazan ekip sürdürür, sonradan gelen bir ekip devralır ya da işletme kendi ekibiyle üstlenir. Hangisinin üstleneceği kodun nasıl kurulacağını baştan belirlediği için karar sistem kurulurken verilmiş olur; lansman günü yalnız fark edilir. AlgoCar’da iş emrine yazılan parça aynı anda stoktan düşer; bağ koptuğunda sistem hata vermez, fark ay sonunda stok tutarsızlığı olarak çıkar.
Lansman günü sorulan bakım sorusu geç kalmıştır
AlgoKlima’da teknisyen kapsama alanının dışındayken kayıt açar. Kayıt önce telefonun yerel kuyruğuna yazılır, uygulama bağlantı beklemez; bağlantı döndüğünde kuyruk oluşturulma sırasına göre boşalır. Kaydın ilk nerede yazıldığı bir kuruluş kararıdır. Ama kararın bir devamı var: kuyruğun çalışır kalması lansmandan sonra birinin işi olmak zorundadır. Kayıt yapısına yeni bir alan eklendiğinde, ofis paneli bir kuralı değiştirdiğinde ya da telefon tarafındaki depolama davranışı değiştiğinde kuyruk kendiliğinden uyum sağlamaz. O “biri” kimdir sorusu, kuyruk kurulurken cevaplanmıştır — cevap hiçbir yere yazılmamış olsa bile.
AlgoCar’da benzer bir bağ duruyor. Parça tüketimi iş emrine yazıldığı anda stoktan düşer; depo hareketi ayrı bir ekranda ikinci kez girilmez. Bu, iki kaydın birbirini tetiklemesi demektir. Bağ koptuğu gün sistem hata vermez, ekranda kırmızı bir uyarı çıkmaz. Stok sayımı sessizce yalan söylemeye başlar ve fark, ay sonunda depo ile iş emri arasındaki tutarsızlıkta görülür. Yani bağın kopmadan kalması, ürün yaşadığı sürece birinin sorumluluğudur.
Bu iki örneğin ortak yanı şu: bakım, üründe bir arıza çıktığında başlayan bir iş değil. Sistem çalışırken de sürüyor. Çünkü çalışan bir sistemde bakım, mevcut davranışın her değişiklikten sonra da geçerli kalmasını sağlamaktır.
Algoriel’in 5 kendi ürünü var; AlgoKlima ve AlgoCar canlı olarak işletiliyor, kalanları inşa ediyoruz. Bakım maliyetini bu iki ürün üzerinde kendimiz ödüyoruz.
Bakım sorusu, bir mimari kararı geri almanın bedelinin özel bir hâli: geç sorulduğunda cevabı verecek kararlar çoktan verilmiş oluyor ve geriye verilen kararla yaşamak kalıyor.
Bakım dediğimiz şey gerçekte neyi kapsar
Bakımı “hata düzeltme” olarak tarif etmek, kapsamın küçük bir dilimini almaktır. SsangYong kurumsal sitesinde katalog okumaları Redis önbelleğinden karşılanıyor; MySQL’e iş ancak veri değiştiğinde düşüyor. Bu düzenin ayakta kalması bakımın kendisi. Kataloğa yeni bir model eklendiğinde önbelleğin eski veriyi göstermemesi kendiliğinden olmaz; önbelleğin ne zaman tazeleneceği bir kuraldır ve o kural her yeni özellikte yeniden düşünülmek zorundadır.
Aynı sitede araç görselleri tek bir adlandırma ve klasör düzenine taşındı. Bu düzenin değeri kurulduğu gün ölçülmez. Değer, sonraki her model eklemesinde ortaya çıkar: düzene uyulduğu sürece hangi modelin hangi dosyayı kullandığı kod okunmadan görülür. Uyulmadığı anda “yeni model eklemek dosya arama işi” geri gelir. Düzeni ayakta tutmak bakımdır ve bu bakımın bir kısmı kod değil disiplindir — kimsenin derlemediği, kimsenin test etmediği bir sözleşmenin sürdürülmesi.
Üçüncü bir yüzü AlgoKlima’da görüyoruz. Sahadan ve ofisten gelen değişiklikler çakışma çözümüyle tek kayıtta birleşiyor. Ürüne yeni bir alan ya da yeni bir ekran eklendiğinde kuyruğun taşıdığı kayıt biçimi ve çakışma kuralı birlikte güncellenmek zorunda. Birini güncelleyip diğerini bırakmak, sahadan gelen kaydın ofisteki değişikliği sessizce ezmesi demek. Çevrimdışı senkronizasyonun “çalışır kalması” tam olarak bu iki şeyin aynı anda güncellenmesidir.
Bunun tersi de doğru. Verisi hiç değişmeyen statik bir tanıtım sayfasında bu kapsamın büyük bölümü ortaya çıkmaz: tazelenecek önbellek yoktur, dağılacak bir depolama düzeni yoktur, birleşecek iki değişiklik yoktur. Bakım yükü sistemin büyüklüğüyle değil, hareketli parça sayısıyla orantılıdır. Bu yüzden “bakımı kim sürdürecek” sorusunun ağırlığı her projede aynı değildir; soruyu ağırlaştıran şey birbirini tetikleyen kayıtların sayısıdır.
Sorunun üç gerçek cevabı ve taşıdıkları maliyet
Cevap üçe ayrılır ve her cevabın maliyet yapısı farklıdır. Yazan ekip kodu okuma maliyeti ödemez; hareketli parçaların bağı zaten hafızasındadır. Devralan ekip önce okumak zorundadır ve okuma bir kerelik değil, dokunduğu her yeni alan için tekrarlanan bir masraftır. İşletmenin kendi ekibi ise yığındaki her aracı bilmek zorundadır; onun maliyeti okuma değil, öğrenme. Bu üç maliyetin hangisinin ödenebilir olduğu, hangi cevabın hangi işletme için mantıklı olduğunu belirler.
Maliyet farkının pratik sonucu devir anında görülür. Yazan ekip sürdürecekse yazılı olması gereken şey azdır; bilgi zaten işi yapan kişilerde durur. Devralan ekip gelecekse aynı bilginin kodun dışında bir yerde durması gerekir: hangi kuralın nerede olduğu, hangi işin hangi kayıtla başladığı. İç ekip sürdürecekse bu yazının yanına bir de araç listesi eklenir, çünkü öğrenilecek şey yalnız sistem değil, sistemin üzerinde durduğu zemindir.
Üçüncü satır iki cevabı birden taşıyor: SsangYong sitesini biz devraldık, ama uzun vadeli bakım marka tarafında kalacaktı ve bu iki gerçek aynı kararı iki ayrı yönden sıkıştırdı.
| Bakımı kim sürdürür | Kodu ne kadar bilmesi gerekir | Ne zaman mantıklı | Portföydeki durum |
|---|---|---|---|
| Yazan ekip | Okuma maliyeti yok; çevrimdışı kuyruk ve çakışma çözümü gibi hareketli parçaların bağı yazanın hafızasında | Sistem yaşadıkça değişecekse ve içinde sürekli işleyen parçalar varsa | AlgoKlima — canlı; saha uygulamasının senkronizasyon kuyruğunu yazan ekip işletmeye devam ediyor |
| Yazan ekip | İş emri–stok–fatura zincirinin hangi ucunun neyi tetiklediğini bilmek gerekir; zincir tek ekipte kalınca kopmadan uzuyor | Kayıtlar birbirine zincirle bağlıysa; bir ucu değiştiren diğer ucu görmek zorundaysa | AlgoCar — canlı; parça tüketimi iş emrinden düşüyor, zincirin bakımı yazan ekipte |
| Devralan ekip — uzun vadede işletmenin kendi ekibine teslim | Sıfırdan okumak zorunda; bu yüzden müdahale okunan ve sayfa yükünü taşıyan bölümlerle sınırlı tutulur, kalıcı bakımı sürdürecek marka ekibinin çalıştığı çatı ve ön yüz seti değiştirilmez | Sistemi kuran ekip artık masada değilse, sistem ayakta duruyorsa ve kalıcı bakım işletmede kalacaksa | SsangYong kurumsal site — devraldık; kod önce okundu, çalışan bölümler yerinde kaldı, çatı ve ön yüz seti değişmedi |
| Yazan ekip — bakım lansmandan önce planlanıyor | Zemin zaten günlük işletilen zemin; yeni ürün yeni öğrenme yükü getirmiyor | Bakım sorusu daha kuruluş anında cevaplanmak istendiğinde | AlgoRandevu — inşa aşamasında; AlgoKlima ve AlgoCar ile aynı Laravel–Inertia zemini üzerine kuruyoruz |
Dördüncü bir cevap gibi görünen bir seçenek daha var: kimse bakmaz. Bu aslında bir cevap değil, ertelemedir. Karar verilmemiş olması mekanizmaları durdurmaz. Önbellek tazelenmemeye, depolama düzeni dağılmaya, kuyruk formatı ürünle birlikte eskimeye devam eder. Fark yalnız şudur: bu üç şeyin bozulduğu gün, onları kimin tamir edeceği hâlâ belli değildir ve tamiri yapacak kişi işe kod okuyarak başlar.
Yazan ekip sürdürünce: kendi ürünlerimizde yaşadığımız bakım
Ofis paneli ile saha uygulamasının aynı çekirdeğe bağlandığı AlgoKlima’da panel Laravel ve Inertia ile, saha uygulaması React Native (Expo) ile kurulu; ikisi de aynı MySQL çekirdeğine bağlanıyor. Bakım burada iki yüzeyi birlikte götürmek demek. Çekirdekteki bir kayıt yapısı değişikliği hem panel ekranını hem saha uygulamasının yerel kuyruğunu ilgilendiriyor. Yazan ekip bu bağı okumadan biliyor; sürdürmesinin ucuz olmasının nedeni de bu. Bağ bir belgede değil, kararı verenlerin elinde duruyor.
Aynı üründe garanti, bakım ve arıza kayıtları müşteri kartında değil cihazın altında duruyor. Aynı adresteki birden çok klimanın dosyası birbirine karışmıyor, cihaz el değiştirse de geçmişi kendisiyle kalıyor. Bu veri modeli kararının değeri yıllar içinde birikiyor — ve biriken geçmişin cihaza bağlı kalmaya devam etmesi, her yeni özellikte bu kararın kasten korunmasını gerektiriyor. Kaydı müşteriye bağlamak her zaman daha kolay görünür; kolay olanı seçmemek bakımın günlük hâli.
İş emri, tüketilen parça ve faturanın tek zincirde ilerlediği AlgoCar’da bakım geçmişi plaka ve şasi kaydına bağlı; araç el değiştirdiğinde geçmişi kendisiyle geliyor. Zincire eklenen her yeni kayıt tipi zincirin her halkasını birden ilgilendiriyor. Bir alan eklemek tek ekranı değil, o alanın stoktan mı yoksa faturadan mı okunacağını da belirlemek demek. Zinciri kuran ekip bu soruyu her seferinde yeniden keşfetmiyor.
Bu cevabın bedeli de var. Yazan ekibin sürdürmesi, işletmeyi o ekibe bir süreklilik bağıyla bağlar. Ekip müsait olmadığında ya da ilişki bittiğinde, işletme okuma maliyetini hiç ödememiş bir sistemle baş başa kalır. SsangYong vakası tam da bu nedenle tersini seçti. Yazan ekip cevabı her işletme için doğru cevap değildir; kendi ürünlerimizde doğru olması, bizim hem yazan hem işleten taraf olmamızdan geliyor.
Devralan ekip: önce oku, çalışana dokunma
Devraldığımız bir Laravel kurumsal site olan KGM SsangYong sitesinde ilk iş yazmak değil okumaktı. Siteyi biz kurmadık; iş bize yayındayken geldi. Kod tabanı önce okundu, çalışan bölümler olduğu gibi yerinde bırakıldı.
Devralan ekibin ilk çıktısı kod değil, bir haritadır: neyin çalıştığı, neden çalıştığı ve hangi davranışın hangi koda bağlı olduğu. Bu harita çıkarılmadan yazılan her satır bir tahmindir. Tahminin bedeli de gecikmeli ödenir; yazıldığı gün değil, dokunulan bölümün başka bir yeri sessizce beslediği fark edildiği gün.
Müdahale sayfa yükünü taşıyan yerlerle sınırlı tutuldu. Model sayfalarında görsel boyutları ve jQuery ile yapılan istekler elden geçirildi; ağır çalışan bölümler tek tek ele alındı. Devralan ekip her şeye dokunmaz, çünkü dokunduğu her yer okumak zorunda olduğu alanı büyütür. Sınırlı müdahale bir çekingenlik değil, maliyet hesabıdır: okunmamış bir bölümü değiştirmek, o bölümü okumayı da işin içine katar.
Devralmanın ikinci çıktısı, bir sonraki devralmanın maliyetini düşüren izlerdir. Görsel depolama düzeni öyle kuruldu ki hangi modelin hangi dosyayı kullandığı kod okunmadan görülüyor. Bu düzeni kuran ekip artık masada olmasa bile bilgi ortada duruyor. İyi yapılmış bir devralma, kendisinden sonraki devralmayı ucuzlatır.
“Çalışana dokunma” ilkesi, sistem gerçekten ayakta olduğu için uygulanabildi. Devralınan sistemde çalışan bölüm kalmamışsa, yapılan iş devralma değil yeniden kurmadır ve maliyeti de ona göre hesaplanır. Devralınan kodu önce okuyup çalışan bölümleri yerinde bıraktığımız işleri yazılım danışmanlığı tarafında hep bu sırayla yürütüyoruz: önce harita, sonra müdahale.
İç ekip sürdürecekse yığın onun bildiği araçlardan seçilir
SsangYong kurumsal sitesinde Laravel, Tailwind ve jQuery setinin dışına çıkılmadı; önbellek dışında hiçbir araç girmedi. Bunun nedeni teknik bir tercih değildi. Uzun vadeli bakımı marka tarafı sürdürecekti; çatıya eklenen her yeni araç, marka ekibinin öğrenmek zorunda olacağı bir şeye dönüşecekti. jQuery’nin yerinde kalması modernlik ölçütüyle değil, sürdürülebilirlik ölçütüyle verilmiş bir karardır.
Kararın bize maliyeti şuydu: hazır bir bağımlılık, elden geçirdiğimiz istekleri yazma işini kısaltırdı. Ama kısalttığı süre bizim tarafımızdaydı, uzattığı süre marka tarafındaydı ve o taraf işi çok daha uzun süre taşıyacaktı. Yığın seçimi burada bir zevk meselesi olmaktan çıkıp doğrudan bakım kararının kendisi hâline geliyor. Yığını kimin bildiğine göre seçmek, bakım cevabını koda yazmaktır.
Aynı ilkeyi kendi ürünlerimizde kendimize uyguluyoruz. AlgoRandevu’yu AlgoKlima ve AlgoCar ile aynı Laravel ve Inertia zemini üzerine kuruyoruz. Bakımı sürdürecek ekip — bu kez biz — o zemini zaten her gün işletiyor. Yeni ürün yeni bir öğrenme yükü getirmiyor; panelin ekran mantığı da aynı aileden geliyor.
Yığın kararının yanında ikinci bir kaldıraç var: bakım yükünün bir bölümünü koddan ayara taşımak. AlgoRandevu’da randevunun süresi ve arka arkaya diziliş aralığı sektöre gömülmek yerine ürün ayarı olarak bırakılıyor. Kural değiştiğinde kod değişmiyor, ayar değişiyor. Bu, bakımı yapacak kişinin kod okuma ihtiyacını doğrudan azaltıyor.
İç ekibin bildiği araç seti problemin gerektirdiği şeyi taşımıyorsa bu kural tek başına yetmez. Çevrimdışı çalışan bir saha uygulaması, tanıdık bir araçla yazıldığı için çevrimdışı çalışmaz. O noktada ya araç seti bilinçli olarak büyütülür ve öğrenme maliyeti kabul edilir, ya da bakım cevabı değişir. Bakımı kimin sürdüreceği kararının yığın seçimini nasıl belirlediğini sistem mimarisi çalışmalarımızda ilk konuştuğumuz başlıklardan biri yapıyoruz.
Bakımı lansmandan önce planlamak: şu an inşa ettiğimiz üç ürün
Randevu tanımının sektöre gömülmediği AlgoRandevu’yu şu an inşa ediyoruz. Hedef, sektör başına ayrı sürüm çıkarmamak: randevu tanımı ürünün içinde yapılandırılabilir kaldığı sürece klinik de salon da atölye de aynı kod gövdesinden besleniyor. Bakım dallanması ürün kurulurken engelleniyor, çünkü dallanmış bir kod tabanında her düzeltme kaç sürüme uygulanacağı sorusuyla birlikte gelir.
Secretum’da karakter kaydını MongoDB dokümanı olarak tutuyoruz. Karakter yeni özellikler kazandıkça doküman yapısı esniyor; her eklemede şemayı baştan kurmamız gerekmiyor. Görsel işini Redis kuyruğuna alıyoruz, üretilen dosyayı S3’e yazıyoruz ve akışta yeniden üretmiyoruz — böylece aynı görselin maliyeti bir kez ödeniyor. Canlı güncellemeyi Laravel tarafında kurduğumuz tek Reverb yayınından hem Vue 3 web arayüzü hem React Native (Expo) istemcisi dinliyor. Bakılacak yayın yolunu bire indirmek, ileride iki istemcinin farklı davranmasını baştan engelliyor. Ürün şu an inşa aşamasında.
QRVizit’te ayrım baştan kuruluyor: basılı QR kodun adresi bir kez sabitleniyor, arkasındaki sayfa panelden değişiyor. Güncelleme kartlara değil kayda gidiyor. Sayfa içeriğini Redis’te önbelleğe alıyoruz ki aynı kod tekrar tekrar okutulsa da her okutma MySQL’e inmesin. Panel ile ziyaretçi sayfası tek Laravel uygulamasında toplandığı için içerik değişikliğinde güncellenecek ikinci bir servis olmuyor. Ürünün sattığı şeyin kendisi bir bakım vaadi — o vaadi taşıyacak mekanizmalar da lansmandan önce kuruluyor.
Bu üç ürünün ortak yanı, bakım sorusunun mimari kararların içine gömülmüş olması. Ayar mı kod mu, tek yayın mı iki yayın mı, esnek doküman mı sabit şema mı — hepsi bakımı kimin, nasıl sürdüreceği sorusuna verilmiş cevaplar. Lansman gününde bu soruların hiçbiri sorulmuyor, çünkü cevapları çoktan koda yazılmış oluyor. Sorulmadığı için de bakım planlanmış bir iş olarak başlıyor.
