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   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. Lotus Notes  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.  Mimari Teknoloji Borcu (ATD)  Carnegie Mellon Üniversitesi'ndeki Mimari Teknik Borç (ATD) Kütüphanesi, ATD'nin aşağıdaki   sağlar: tanımını  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, "   ”2015 araştırması Carnegie Mellon tarafından yayınlandı. Ö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ç  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önetmek  ATD'yi yönetmeden önce sorunu anlamalıyız.   bir zamanlar bilgece şöyle demişti: "Bir fili yemenin tek yolu vardır: her seferinde bir ısırık." Desmond Tutu  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:  Dayanıklılık için sola kaydırma — dayanıklılık üzerinde etkisi olan kaynakları belirleme ve ardından bunları performansta ortaya çıkmadan önce düzeltme.  Güvenlik için sola kaydırma — geliştirme yaşam döngüsü sırasında güvenlik sorunlarını tespit edin ve azaltın.  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  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"   teknik borcu düzeltmenin maliyetini 1,52 trilyon dolar olarak bildirmişti. makalesinde  Başarılı olmak için mühendislik liderliğinin aşağıdaki organizasyonel hedeflerle tam uyumlu olması gerekir:  Dayanıklılık — beklenmedik olaylardan hızla kurtulmak için.  Ölçeklenebilirlik — müşteri talebine uygun şekilde ölçeklendirmek.  Hız — ürün beklentilerine uygun özellikler ve geliştirmeler sunmak.  Bulut Uygunluğu — eski çözümleri verimli bulutta yerel hizmet tekliflerine dönüştürüyor.  Yakın zamanda   aşağıdaki çıktılara odaklanan yapay zeka odaklı mimari gözlemlenebilirlik platformunu keşfettim: vFunction'ın  Statik ve dinamik analiz yoluyla çözümlerin gerçek mimarisini   . keşfedin  Hizmetlerin nasıl geliştiğine ilişkin gerçek zamanlı görünümler aracılığıyla mimarinin kaymasını   . önleyin  Uygulama etki alanları ve bunlarla ilişkili kaynaklar arasındaki gereksiz bağımlılıkları ve iyileştirmeleri ortadan kaldırarak uygulamaların   artırın. dayanıklılığını  Yapay zeka odaklı gözlemlenebilirlik aracılığıyla teknoloji borcunu yönetin ve   . düzeltin  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.  Çözüm  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   onlar hakkında daha fazla bilgi edinebilirsiniz. buradan  Gerçekten harika bir gün geçirin!

This story contains new, firsthand information uncovered by the writer.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Mimari Teknoloji Borcunu Yönetmek

Mimari Teknoloji Borcunu Yönetmek

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Floki'den Valhalla Hindistan'ın Sri Lanka Turuna Yardımcı Sponsor Olarak Katıldı

Görünmeyen Katmanlar: Kullanıcı Görüşmeleri Neden Yeri doldurulamaz bir Varlıktır?

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Floki'den Valhalla Hindistan'ın Sri Lanka Turuna Yardımcı Sponsor Olarak Katıldı

Görünmeyen Katmanlar: Kullanıcı Görüşmeleri Neden Yeri doldurulamaz bir Varlıktır?

Yapay Zekanın Gücünü Ortaya Çıkarıyoruz. En Son Tekniklerin Sistematik Bir İncelemesi: Özet ve Giriş

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps