Teknik borcu düşündüğümde, uygunsuz bir mimarinin sonuçlarını fark etmemi sağlayan ilk oluşturduğum uygulamayı hala hatırlıyorum. Bu, 1990'ların sonlarında, danışman olarak işe ilk başladığım dönemde gerçekleşti.
Müşteri, müşterileri için bir satın alma sistemi oluşturmak amacıyla Lotus Notes platformunun kullanılmasını talep etmişti. Son kullanıcılar, Lotus Notes istemcisini ve özel bir uygulamayı kullanarak, uygulama tarafından izlenecek ve ürün sahibinin ekibi tarafından yerine getirilecek isteklerde bulunabiliyordu. Teorik olarak, bu gerçekten harika bir fikirdi; özellikle web üzerinde geliştirilen uygulamaların yaygın olmaması ve herkesin Lotus Notes'u günlük olarak kullanması nedeniyle.
Temel sorun, verilerin tasarım açısından oldukça ilişkisel olması ve Lotus Notes'un ilişkisel bir veritabanı olmamasıydı. Çözümün tasarımı, her Lotus Notes belgesinde şema yönetimi gerektiriyordu ve veri nitelikleri arasındaki ilişkileri simüle etmek için bir dizi çoklu değer alanına dayanıyordu. Dağınıktı.
Daha iyi bir platform önerilseydi, Lotus Notes uygulamasında çok fazla mantığa ihtiyaç duyulmazdı. Kaynak kodunun desteklenmesi karmaşıktı. Veri yapısındaki iyileştirmeler, mevcut verileri dönüştürmek için sunucu tabanlı işlerin çalıştırılmasının yanı sıra, temel kodun büyük ölçüde yeniden düzenlenmesiyle sonuçlandı. Beni rapor oluşturmanın ardındaki çabaya sokma.
Kariyerimin başlarından beri daha iyi bir çözüm sunmaya çalışmak yerine müşterinin istediği çözümü sağlamaya odaklandım. Bu kesinlikle kariyerimin başlarında öğrendiğim bir dersti, ancak o projeden bu yana geçen yıllarda, mimari teknik borcun sonucunun hepimizin karşılaştığı talihsiz bir gerçeklik olduğunun farkına vardım.
Mimarlık teknoloji borcu kavramını makro düzeyde biraz daha inceleyelim.
Carnegie Mellon Üniversitesi'ndeki Mimari Teknik Borç (ATD) Kütüphanesi, ATD'nin aşağıdaki tanımını sağlar:
Mimari teknik borç, kısa vadede amaca uygun olan ancak aynı işin mimari yeniden çalışmayı gerektirdiği ve daha sonra yapmanın şimdi maliyetinden daha yüksek maliyetli olduğu (zaman içinde artan maliyet dahil) bir teknik bağlam yaratan bir tasarım veya inşaat yaklaşımıdır. .
Gartner Group, "Hızlı Cevap: Mimarlık Teknik Borcu Nasıl Yönetilir" (22.09.2023'te yayınlandı) belgesinde ATD'yi şu şekilde tanımlıyor:
Mimari teknik borç, mimari sürüklenmeden, optimal olmayan mimari kararlardan, tanımlanmış hedef ürün mimarisinin ve yerleşik endüstri mimarisi en iyi uygulamalarının ihlallerinden ve daha hızlı yazılım teslimatı için yapılan mimari ödünleşimlerinden kaynaklanan bu tür teknik borçtur.
Her iki durumda da, genellikle kısa vadeli kutlamalara yol açan faydalar, uzun vadeli zorluklarla karşılanabilir. Bu, girişte bahsettiğim Lotus Notes örneğime benzer.
Sorunları daha da karmaşık hale getirmek için, yazılım mimarisine yönelik teknoloji borcunun belirlenmesine ve yönetilmesine yardımcı olacak araçların, yazılım geliştirmenin diğer yönleriyle karşılaştırıldığında eksik olması:
Kod kalitesi, gözlemlenebilirlik ve SCA için Sonarqube, Datadog, New Relic, GitHub ve Snyk gibi ürünlerde kanıtlanmış araçlar mevcuttur. Ancak yazılım mimarisi segmenti kanıtlanmış herhangi bir çözüm olmaksızın geride kalmıştır.
ATD'nin sürekli olarak en büyük ve en zarar verici teknik borç türü olduğu göz önüne alındığında, " Ölç" bölümünde de belirtildiği gibi bu talihsiz bir durumdur. Yönet? Boşver? Yazılım Uygulayıcıları ve Teknik Borç ”2015 araştırması Carnegie Mellon tarafından yayınlandı.
Aşağıdaki çizim, bu rapordaki Şekil 4'ü özetlemekte ve kötü mimari seçimlerinin teknik borç kaynaklarında açık bir şekilde lider olduğu sonucuna varmaktadır.
ATD, yönetilmediği takdirde, bu basit örnekte de gösterildiği gibi, zaman içinde artan bir hızla büyümeye devam edebilir:
Azaltma yapılmazsa, mimari borç, ölçülen temel çözüm açısından eninde sonunda bir kırılma noktasına ulaşacaktır.
ATD'yi yönetmeden önce sorunu anlamalıyız. Desmond Tutu bir zamanlar bilgece şöyle demişti: "Bir fili yemenin tek yolu vardır: her seferinde bir ısırık."
Sola kaydırma yaklaşımı, belirli bir yönü yaşam döngüsünün sonuna göre başlangıca yaklaştırma kavramını benimser. Bu konsept, test aşamasının, geliştirme tamamlandıktan sonra tamamlanacak ayrı bir olay değil, geliştirme sürecinin bir parçasına kaydırıldığı test için sola kaydırma ile popülerlik kazandı.
ATD yönetiminde sola kaydırma iki farklı şekilde uygulanabilir:
Test için sola kaydırmada olduğu gibi, geliştirme aşamasında dirençlilik ve güvenliğe öncelikli olarak odaklanmak, beklenmeyen olayların yaşanma olasılığını azaltacaktır.
Mimari gözlemlenebilirlik, mühendislik ekiplerine, hizmetleri dahilindeki mimari sapmaları makro düzeyde aşamalı olarak ele alma yeteneği verir. Aslında Wall Street Journal, bu yılın başlarında "Görünmez 1,52 Trilyon Dolarlık Sorun: Hantal Eski Yazılım" makalesinde teknik borcu düzeltmenin maliyetini 1,52 trilyon dolar olarak bildirmişti.
Başarılı olmak için mühendislik liderliğinin aşağıdaki organizasyonel hedeflerle tam uyumlu olması gerekir:
Yakın zamanda vFunction'ın aşağıdaki çıktılara odaklanan yapay zeka odaklı mimari gözlemlenebilirlik platformunu keşfettim:
Ek olarak vFunction platformu, monolitlerden bulutta yerel çözümlere geçiş için bir geçiş yolu sağlama gibi bir yan fayda da sağlar. Ekipler platformlarını modernize ettikten sonra, devam eden sürüklenme için onları sürekli olarak gözlemleyebilirler. Şirketlerin halihazırda mikro hizmetleri varsa, dağıtılmış uygulamalardaki karmaşıklığı tespit etmek ve esneklik ile ölçeklenebilirliği etkileyen bağımlılıkları gidermek için vFunction'ı kullanabilirler. Her iki durumda da, bir kez uygulandığında mühendislik ekipleri ATD'yi kırılma noktasına ulaşmadan çok önce hafifletebilir.
Yukarıdaki çizimde, mühendislik ekipleri, vFunction platformunun uygulanması ve temelde sola kaydırma yaklaşımı sayesinde, her sürümün bir parçası olarak teknik borcu azaltabiliyor.
Okuyucularım, her BT uzmanına uygulanabileceğini düşündüğüm aşağıdaki misyon beyanına odaklandığımı hatırlayabilirler:
“Zamanınızı fikri mülkiyetinizin değerini artıran özellikler/işlevsellik sunmaya odaklayın. Diğer her şey için çerçevelerden, ürünlerden ve hizmetlerden yararlanın.” -J.Vester
vFunction platformu, mühendislik ekiplerinin hizmetlerinin makro düzeyde dayanıklılığı ve güvenliğine yönelik sola kaydırma yaklaşımını kullanmasına yardımcı olarak misyon beyanıma bağlı kalıyor. Bu önemli bir ayrımdır, çünkü böyle bir araç olmadan ekiplerin mikro düzeyde hafifletilmesi ve organizasyonel açıdan pek önemli olmayan teknoloji borcunun çözülmesi muhtemeldir.
Teknoloji borcuyla ilgili zorlukların farkına varmamı sağlayan o uygulamayı tekrar düşündüğümde, bu çözümün, sunulan her özellikte fayda sağlamaktan çok nasıl daha fazla soruna yol açtığını düşünmeden edemiyorum. Elbette, dayanıklılık için sola kaydırmanın tek başına kullanılması, alternatifleri dikkate alma maliyetinin uygun olacağı bir noktada, temeldeki mimariyle ilgili sorunların yüzeye çıkmasına yardımcı olabilirdi.
vFunction çözümü hakkında daha fazla bilgi edinmek istiyorsanız buradan onlar hakkında daha fazla bilgi edinebilirsiniz.
Gerçekten harika bir gün geçirin!