Her yazılım uygulaması, web uygulaması veya özel platform er ya da geç teknik borç (technical debt) ile karşılaşır. Başlangıçta bunu pek fark etmezsiniz. Bir son tarihi yakalamak için hızlı bir çözüm seçersiniz, mimari bir ara adımı atlarsınız veya bir temizlik işlemini ertelersiniz. Bu kısa vadede zaman kazandırır, ancak uzun vadede bunun faizini ödersiniz.
Bu faiz, yavaşlama olarak kendini gösterir. Daha önce bir günde inşa edilen bileşenler birdenbire bir hafta sürmeye başlar. Panodaki küçük değişiklikler, yönetim modülünde beklenmedik hatalara yol açar. Geliştiriciler, işletmeniz için yeni değer inşa etmekten çok, eski mantığı çözmeye vakit harcar.
Sorun, nadiren çok az işin fark edilmesidir. Genellikle teknik iyileştirme listesi, dağınık notlar ve bildirimlerle doludur. Sorun, bu teknik borcun nasıl ele alındığıdır. Birçok KOBİ ve girişimci, uygulamaları büyüdükçe aynı tuzaklara düşer.
Aşağıda, teknik borcu yönetirken en sık yapılan dört hatayı ve bunları çözmenin somut yolunu ele alıyoruz.
Hata 1: Aktif bir yol haritası yerine pasif bir backlog
Birçok ekip, teknik sorunları uzun bir listede toplar. Bir geliştirici kodda garip bir şeyle karşılaştığında, backlog'a bir bilet (ticket) eklenir. Zamanla bu listede yüzlerce görev birikir: küçük, eskimiş bağımlılıklardan tam bir veritabanı yapısını yeniden yazmaya kadar.
Sonuç, artık kimsenin önceliklendirmediği bir dilek listesidir. Liste bu kadar uzun olduğu ve iş hedefleriyle bağlantılı olmadığı için, her sprintte yine de yeni işlevsellik sunmak tercih edilir. Teknik backlog, unutulmuş görevlerin biriktiği bir çöplüğe dönüşür.
Somut çözüm
Pasif listeyi aktif bir yol haritasına dönüştürün. Teknik görevlerden oluşan bir liste, ancak her görevi dört sabit faktöre bağladığınızda değer kazanır: ticari etki, sahiplik, mevcut kapasite ve sonucun ölçülebilirliği.
Her teknik sorun için kendinize, çözmezseniz ticari riskin ne olduğunu sorun. Düzeltmeden kimin sorumlu olduğunu ve önümüzdeki yinelemede bunun için ne kadar kapasite ayrılabileceğini belirleyin. Bir düzeltme, ödeme ekranındaki yüklenme sürelerini yarıya indiriyorsa veya kullanıcı oluştururken alınan hata sayısını sıfıra indiriyorsa, bu doğrudan iş sonucunuzu etkiler. Teknik borca, bu etki netleşmeden plana bir yer vermeyin.
Hata 2: Hızlı yamaların kod tabanında birikmeye devam etmesi
Bir uygulamanın hızla değişmesi gerektiğinde, temeli değiştirmeden eski kodun üzerine yeni işlevsellik inşa etme cazibesi büyüktür. Örneğin React ve TypeScript ile oluşturulmuş bir uygulamada bunu sıklıkla, tüm mantığın, görünümün ve veri işlemenin iç içe geçtiği devasa dosyalarda görürsünüz.
Bir hata oluştuğunda, hızlıca ekstra bir kontrol veya istisna eklenir. Bu da kodu giderek daha karmaşık ve anlaşılması zor hale getirir. Yeni geliştiriciler veya dışarıdan gelen yapımcılar, neler olduğunu anlamak için geçmişteki kararların katmanlarıyla boğuşmak zorunda kalır.
Somut çözüm
Aşamalı yeniden inşa ve sıkı izolasyon kuralını uygulayın. Tüm sistemi büyük bir yeniden inşa için bir kerede durdurmak yerine, ayarlanması gereken bileşenleri izole edersiniz.
Büyük bileşenleri net bir göreve sahip küçük, yeniden kullanılabilir modüllere ayırın. Bir modüle hangi verinin girip çıktığını belirlemek için sıkı TypeScript arayüzleri kullanın. Fonksiyonları kullanıcı arayüzünden ayırarak, uygulamanın geri kalanı bozulmadan iç mantığı gözden geçirebilirsiniz. Kısa yinelemeler halinde inşa edin ve belirli bir modül üzerinde çalışırken hemen çevresindeki kodu temizleyin.
Hata 3: Yeni işlevsellik eklerken veritabanı yapısını göz ardı etmek
Bir projenin başında veritabanı yapısı genellikle basittir. Ancak bir platform büyüdükçe yeni tablolar, alanlar ve ilişkiler eklenir. Bu genellikle yeni bir özelliği hızla desteklemek için anlık (ad hoc) olarak yapılır.
Supabase gibi bir veritabanı kullanan platformlarda bunun sonucunu hızla görürsünüz: yavaş sorgular, yinelenen veriler ve indeksleme eksikliği. Veritabanı uygulamanızın temeli olduğundan, kötü bir yapı yazılımın her bölümüne yansır. Sayfalar daha yavaş yüklenir ve panodaki raporlar giderek daha uzun sürer.
Somut çözüm
Sorgu performansı ve veri temizliği üzerinde periyodik olarak bir denetim yapın. Hangi sorguların en çok zaman aldığını inceleyin ve sık sık filtrelenen veya sıralanan alanlara doğru indeksleri ekleyin.
Eğer eski kararlar nedeniyle bir veritabanı yapısı fazla karmaşık hale geldiyse, net bir migrasyon planı oluşturun. İlişkilerin mantıklı bir şekilde kurulması için şemayı düzenleyin ve kullanılmayan alanları kaldırın. Veri akışını sıkı tutarak, yıllar içinde ne kadar veri birikirse birikinsin uygulama hızlı tepki vermeye devam eder.
Hata 4: Net standartların ve dokümantasyonun eksikliği
Teknik borç yalnızca bir kod meselesi değildir, aynı zamanda aktarılan bilginin eksikliğidir. Tek bir geliştirici tüm kararları kafasında tutuyorsa ve yazılımın yapısı hakkında net anlaşmalar yapılmamışsa, bağımlılık ortaya çıkar.
Geçmişte gerekçesi olmadan alınan her karar, bir sonraki yapımcı için bir bilmeceye dönüşür. Neden belirli bir entegrasyon yöntemi seçildi? Kodda neden bu gecikme var? Dokümantasyon olmadan, bir şeylerin bozulacağı korkusuyla kimse eski bileşenlere dokunmaya cesaret edemez.
Somut çözüm
Mimari kararları kodun yaşadığı yerde kayıt altına alın. Kimsenin okumadığı kalın el kitaplarına ihtiyacınız yok. Proje arşivindeki önemli seçimlerle ilgili kısa açıklamalar yeterlidir.
Bunun yanında net kod standartları belirleyin. Kodun üzerinde anlaşılan yapıya ve stil kılavuzuna uyup uymadığını kontrol etmek için inşa sürecinde otomatik araçlar kullanın. Bu, özensizliklerin baştan itibaren ana koda girmesini önler. Herkes aynı yapıya göre inşa ederse, her geliştirici hızla yolunu bulabilir ve ayarlamalar yapabilir.
Teknik borcu yapısal olarak nasıl kontrol altında tutarsınız
Teknik borcu tamamen ortadan kaldırmak bir illüzyondur ve ayrıca verimli de değildir. İş dünyasında hız genellikle belirleyicidir ve bazen geçici bir çözüm doğru ticari tercihtir. Önemli olan bu seçimin bilinçli yapılması ve borcun zamanında ödenmesidir.
Her teslimatta ve her yeni aşamada bakım ve yeniden yapılandırma için zaman ayırın. Yalnızca yeni özelliklerin sunulmadığı, aynı zamanda platformun kararlılığının da tutarlı bir şekilde inşa edildiği kısa yinelemelerle çalışın.
Teknik iyileştirmeleri somut hedeflere bağlayarak, platformu gelecek için hızlı, ölçeklenebilir ve yönetilebilir tutarsınız. Böylece yazılım, işletmenizin yazılımı beklemesi yerine, işletmeniz için çalışmaya devam eder.
Web sitenizin, e-ticaret sitenizin veya platformunuzun teknik durumu hakkında fikir alışverişi yapmak ister misiniz? ferhat.io/contact üzerinden ücretsiz otuz dakikalık bir görüşme planlayın.
