Yazılım geliştiricileri genellikle beklenmeyen olaylar karşısında şaşırırlar: kullanıcılar yeni özellikleri beklenmedik şekillerde kullanır, bu da sunucularda beklenmedik yük oluşmasına neden olur; üçüncü taraf bir kütüphanenin, bir güncellemeden sonra aniden kişisel verileri kaydetmesi, veri koruma yönergelerini ihlal eder; Geri dönüş mekanizması, özellikle veri yoğunluklu bloklar için önbelleğin beklenmedik şekilde dolmasına neden olur. Her yazılım mimarı başka birçok örnek bilir.
Duyurudan sonra devamını okuyun
Alexander Kaserbacher yazılım mimarisi konusunda uzmanlaşmış bir danışmandır. Halen evrimsel mimari ve platform mühendisliği üzerinde yoğun olarak çalışmaktadır.
Bir projenin başlangıcında bu olaylar, daha önce kimsenin bilmediğini bilmediği bilinmeyen bilinmeyenlerdi. Bunlar, yazılım geliştirmedekiler gibi tipik karmaşık problemlerdir ve özellikle dağıtılmış ekiplerin olduğu bir organizasyon yapısında sorunlara yol açarlar. Bu tür yapılarda genellikle teknolojiler, programlama dilleri, modeller ve arayüzler gibi genel yönetişim gereksinimleri bulunur. Merkezi mimari ekipleri bunların tanımıyla ilgilenir. Bununla birlikte, bu tür katı merkezi kurallar, bilinmeyen bilinmeyenlere etkili bir yanıt verilmesini birçok nedenden dolayı sıklıkla engellemektedir:
- Spesifikasyonlar genellikle yazılım kalitesinin güvenlik, sürdürülebilirlik veya güvenilirlik gibi yönleriyle ilgilidir. Merkezi birimlerin ekiplerin spesifikasyonları farklı soyutlama seviyelerinde nasıl uyguladıklarını değerlendirmesi gerekir. Ayrıca planlanan uygulamanın gerçekte istenen kalite standartlarını karşılayıp karşılamayacağını önceden bilmeleri gerekir.
- Birleştirme, yazılım geliştirmeyi yavaşlatır çünkü birçok karar, tüm ekipler arasında sürekli koordinasyon gerektiren merkezi birimler tarafından alınır. Bu çoğu zaman darboğazlara yol açar.
- Spesifikasyonlar geliştirme ekiplerinin sorumluluğunu ortadan kaldırır, dolayısıyla dışarıdan belirlenen konularda kendilerini sorumlu hissetmezler.
- Geliştirme ekipleri spesifikasyonlara sıkı sıkıya bağlı kaldıkları ve onlardan sapmadıkları için inovasyon daha da zorlaşıyor. Bu, bunların gerçekten uygun olup olmadığı veya daha iyi alternatiflerin mevcut olup olmadığı konusunda geri bildirim eksikliği olduğu anlamına gelir.
Dinamik ortamlarda problem çözme
Şaşırtıcı sorunlara yeterli çözümlerin dinamik bir ortamda tahmin edilmesi ve planlanması çoğu zaman imkansız olduğundan, aktörlerin iyi bir cevaba adım adım yaklaşması gerekir. Araştırmacıların hipotezler yoluyla yeni bilgiler elde ettiği bilimde de benzer zorluklar mevcuttur. Deneyler ve resmi kanıtlar bu hipotezleri doğrular veya reddeder, böylece yeni bilgiye yaklaşım yavaş yavaş gerçekleşir. Bir yazılım projesinde ne kadar çok bilinmeyen gizlenirse, geliştiriciler geri bildirim yoluyla düzenli olarak doğrulanan küçük adımlardan (hipotezlerden) o kadar fazla yararlanır. Şekil 1 bu süreci göstermektedir.
Bir hipotez geri bildirim mekanizmaları aracılığıyla doğrulanır (Şekil 1).
Geliştirme ekipleri her sürümü bir tahmin olarak görüyor. Geliştirme ekipleri, merkezi yönergeleri takip etmek yerine, yüksek verim için mesajlaşma teknolojisi ve veritabanlarını veya kullanılabilirliği artırmak için bir yük devretme mekanizmasını seçerek uygun bir yaklaşıma karar verir ve bunu kendi sorumluluk alanlarında uygular. Daha sonra bu yaklaşımı etkili geri bildirimlerle mümkün olan en kısa sürede doğrularlar. Örneğin üretkenlik ve buna bağlı hız önemli bir hedefse, çalışan sistemdeki performans ölçümleri değerli geri bildirimler sağlar. Kullanılabilirlik gibi hedefler de doğrudan ölçülebilirken, sürdürülebilirlik genellikle birleştirme veya siklomatik karmaşıklık (bir programın kontrol akış grafiği) gibi ölçümler kullanılarak elde edilebilir.
Duyurudan sonra devamını okuyun
Geri bildirim mekanizmaları, geliştirme ekiplerine iyileştirme fırsatlarını gösterir ve daha sonra bunları yeni hipotezlere uygularlar. Bu, genetik çeşitliliğin yerel ve merkezi olmayan bir şekilde ortaya çıktığı ve doğal seçilimin kötü değişkenleri ortadan kaldırdığı biyolojideki evrimsel sürece benzer.
BT bağlamında, kendi kendini organize eden ekiplerin iş sonuçlarında farklılıklar meydana gelirken geri bildirim (seçim) mekanizmaları uygun olmayan parçaları hızla keşfeder. Biyolojiye dayanan bu kavrama evrimsel mimari adı verilmektedir. Artan ve ortaya çıkan uygulamalar ve düzenli, niteliksel geri bildirim yoluyla karmaşık ortamlarda dinamik olarak çalışan ürün geliştirmeyi tanımlar.
Hipotezler ve geri bildirim arasındaki etkileşim hızlı ve küçük parçalar halinde gerçekleşmelidir. Dört Temel Metrik gibi ampirik veriler bu dinamiği göstermektedir (Forsgren, N. ve diğerleri: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organities; 2018). Yüksek performanslı ekipleri diğerlerinden ayıran önemli ölçütleri tanımlarlar:
- Dağıtım frekansı geliştirme ekiplerinin Şekil 1'de gösterilen döngüyü ne sıklıkta çalıştırdığını temsil eder.
- Değişiklikler için teslimat süreleri geliştirme ekiplerinin bu döngüden ne kadar hızlı geçtiğini gösteriyor.
- Hizmeti geri yükleme zamanı geldi VE Başarısızlık oranını değiştir Potansiyel olarak yanlış varsayımların uygulanmasıyla ilişkili riski tanımlayın.
Geliştirme ekiplerinin tatmin edici bir sonuca mümkün olduğu kadar etkili bir şekilde yaklaşması için, zarar potansiyeli az olan küçük, sık dağıtımlar çok önemlidir. Manuel sürüm ve kontrol süreçleri dağıtım sıklığını ve değişiklikler için teslim sürelerini uzattığından, klasik yönetişim yaklaşımları (“Klasik yönetişim yaklaşımları nasıl oluşturulur” kenar çubuğuna bakın) genellikle bunu engeller.
Yazılım sistemleri farklı yapı taşlarından oluşur: modüller, hizmetler, uygulamalar; bağlama ve ayrıntı düzeyine bağlı olarak farklı şekilde çağrılabilirler. İster tek bir yazılım ürünü olsun ister bir şirketin tüm BT yapısı olsun, birlikte daha büyük bir sistem oluştururlar. Yazılım mimarları genellikle yapı taşlarını teknik kriterlere göre, özellikle de etki alanı odaklı tasarım veya mikro hizmetler gibi mimari kalıplar gibi teknikleri kullanarak bölerler. Bunun bir örneği ürün kataloğu, arama ve alışveriş sepeti gibi bileşenlerden oluşan bir çevrimiçi mağazadır.
Bu tür sistemler, tek bir ekibin bakımını ve geliştirmesini sağlayamayacağı kadar büyüdüğünde, birçok kuruluş sorumlulukları böler ve bireysel yapı taşlarını ayrı bir ekibe atar. Örneğin, özellikle alışveriş sepeti modülünden sorumlu olabilirsiniz.
Yapı taşlarının ve ekiplerin sayısı arttıkça kuruluşlar artan karmaşıklığı yönetme zorluğuyla karşı karşıya kalır. Teknolojilerin çoğalması gibi tipik sorunlar, genel kural ve spesifikasyonlara yönelik isteklere yol açmaktadır. Merkezi mimari ekipleri daha sonra genel olarak uygulanabilir standartları tanımlar. Bu, teknolojiler, programlama dilleri, modeller ve arayüzlerin yanı sıra özel yapılandırma gereksinimleriyle ilgili kurallar oluşturur.
Umut, standardizasyon ve birleşme yoluyla verimliliği arttırmaktır. Geliştirme ekipleri, kendi başlarına zaman alıcı kararlar almak ve alternatifleri inceleyip değerlendirmek yerine spesifikasyonlara bağlı kalırlarsa daha hızlı çalışabilmelidir. Yapı taşları bir kez geliştirildikten sonra farklı ekipler arasında bile yeniden kullanılabilir. Operasyonel ekipler daha verimli olacaktır çünkü tam olarak tek bir standartlaştırılmış hedef ortamı sürdürmek zorunda kalacaklardır.
İlk bakışta bu klasik yaklaşımlar verimliliğin artmasını vaat ediyor, ancak uzun vadede çoğunlukla hesap verebilirlik sorunlarına ve inovasyonda gecikmeye yol açıyor.
Bir yanıt yazın