Edwards Lorenz, hava durumunu tahmin etmek için bir model tasarlamaya başlayan ancak sonunda kaos teorisini keşfeden bir meteorolog ve matematikçiydi. Basit bir modeldeki küçük değişikliklerin, güneşli gökyüzünden şiddetli fırtınalara kadar hava durumu üzerinde farklı ve şiddetli etkilere yol açtığını gözlemledi; ve sonuçları önceden tahmin etmenin bir yolu yoktu. Keşfedilmesine yol açan bilgisayarlı hava durumu modeli bir kelebeğe benziyordu ve sonuçta Kelebek Etkisi formüle edildi. Şiirsel anlamda, “Brezilya’da bir kelebeğin küçük bir kanat çırpışı, bir dizi atmosferik olayı tetikleyebilir ve Teksas’ta bir kasırgaya yol açabilir.”
Bu basit kavram, küçük ve görünüşte önemsiz olayların veya oluşumların, çok karmaşık bir sistem üzerinde çok daha büyük, doğrusal olmayan etkiler üretmesine neden olabileceğini öne sürüyor. Küçük değişimler – büyük sonuçlar!
Yazılım mühendisliği dünyasında kelebek etkisi yaptığımız hemen hemen her şeye uygulanabilir. Kod tabanınızdaki küçük bir değişiklik veya gözden kaçan önemsiz bir hata, sonunda yazılımınızın davranışını değiştirecek beklenmedik ve çok önemli sonuçlara yol açan küçük bir dalgalanma olabilir.
Bu, öngörülemeyen felaketleri ortadan kaldırmak için değişikliklerden kaçınılması gerektiği anlamına gelmez. Değişim, yazılım geliştirmenin ayrılmaz bir parçası olduğundan ve yalnızca değişim yoluyla mümkün olduğundan, dayanıklı, müşteri odaklı, sağlam ürünler ortaya çıkarabiliriz. Bu nedenle önemli olan, güvenilirliği sağlayacak süreçleri ve araçları uyarlamak ve böylece yazılım geliştirmede kelebek etkisini etkili bir şekilde yönetmektir.
“En İyi Uygulamalar” göreceli bir terimdir
Hepimiz en iyi uygulamalardan bahsediyoruz ancak yanlış yorumlanırsa tehlikeli bir terim olabilir. Çünkü ayrı ayrı ele alındığında tüm en iyi uygulamalar kazançlıdır, uygulanabilirdir ve benzersiz derecede önemli özelliklere sahiptir. Ancak birlikte her zaman aynı sonucu elde edemeyebilirler. İşin sihri, yazılımınızın uzun vadede başarılı ve dayanıklı olmasını sağlamak amacıyla projeniz için seçtiğiniz en iyi uygulamalar arasındaki tutarlılığı anlamak ve sürdürmektir.
DevOps ve Özellik Bayrakları
Yeni özelliklerin sağlanması ve kontrol edilmesi, ürün geliştirmedeki en büyük zorluklardan biridir. Özellik bayrakları, DevOps’taki en iyi uygulamalardan biridir ve genellikle dağıtılmış sürüm kontrol sistemlerinde meydana gelir ve geliştiricilerin, hiçbir şeyi bozmadan veya test edilmemiş özellikleri yayınlamadan uygulamalarını sürekli olarak güncellemelerine olanak tanır. Daha hızlı sürüm temposuna izin veren özellik bayrakları, ürününüzün farklı sürümleri arasında anında geçiş yapmanızı sağlar. Özellik bayrakları sayesinde sistemin davranışını değiştirmek için herhangi bir rahatsız edici kod değişikliği yapılmasına gerek kalmayacak ve mühendislik ekiplerinin görevleri üzerinde özgürce çalışmasına olanak sağlanacak. Bu, sürekli bir teslimat sürecini rahatlıkla sağlayacaktır.
CI/CD ve Otomatik Test
CI/CD olarak da bilinen sürekli entegrasyon (CI) ve sürekli teslimat (CD), yazılımınızın dinamik kalmasını sağlar. CI/CD, sürekli bir geliştirme, test etme ve entegrasyon döngüsü oluşturarak, sorunları tespit etmek ve sistemde kelebek etkisi yaratmadan önce bunları çözmek için kodlarınızdaki düzenli durum kontrollerini daha da kolaylaştıracaktır.
Otomatik testler, kod değişikliklerinden kaynaklanan beklenmeyen sonuçların önceden tanımlanmasını sağlamak ve risklerin erkenden tanımlanıp azaltılmasını sağlamak için mühendislik ekiplerine zamanında geri bildirim sağlamak amacıyla CI/CD hattının bir parçası olarak çalıştırılabilir. Birim testi, entegrasyon testi, sistem testi ve kullanıcı kabul testi de sorunların daha büyük kusurlara dönüşmeden önce tespit edilmesinde kritik bir rol oynar.
Kod İncelemeleri ve Statik Analiz
Hepimiz önlemenin tedavi etmekten daha iyi olduğunu biliyoruz. Düzenli kod incelemeleri, statik kod analizi ve çift programlama, ilk testler sırasında gözden kaçırılmış olabilecek potansiyel sorunları yakalayabileceğiniz yöntemlerdir. Ek savunma katmanları sağlayarak, statik kod analizi gibi yöntemler, programı çalıştırmaya gerek kalmadan kaynak kodu inceleyerek hata ayıklamanın otomatik olarak yapılmasını sağlayacaktır.
Teknik borcunuzu yeniden düzenleme
Tıpkı finansal borçlar gibi teknik borçlar da ele alınmadığı takdirde faiz biriktirebilir. Yeniden düzenleme, yazılımın işlevselliğini değiştirmeden kodun uygulanmasını, tanımını ve yapısını değiştirme işlemidir. Bu, işlevsellik eklemek veya kaldırmak değil, gelecekteki teknik borçlarla mücadele etmek ve yazılımın sürdürülebilirliğinden ve güvenilirliğinden yararlanarak potansiyel kelebek etkilerinden kaçınmak için kodun bakımını kolaylaştırmakla ilgilidir.
Ölüm öncesi ve ölüm sonrası
Otopsi veya Kök Neden Analizi (RCA), bir ekibin halihazırda sona ermiş bir olayda neyin yanlış gittiğini düşünmesini, bir süreçteki (ve) veya belgelerdeki boşlukları inceleyip tanımlamasını ve bu durumun daha sonra meydana gelmeyeceğinden emin olmayı gerektirir.
Ancak, daha iyi karar almayı desteklemek için projenin başlangıcında geriye doğru çalışılarak bir ön otopsi yapılır. Büyük resme bakıldığında, ön otopsi çeşitli bakış açılarını, kolektif zekayı ve hayal gücünü teşvik eder ve projelerin çok erken bir aşamasında potansiyel kelebek etkisini azaltmada önemli bir rol oynar.
Yazılım Mühendisliğinin Geleceği
Bazıları kurumsal yazılımın sonsuza kadar süreceğini söylüyor. Sonsuza dek, ancak müşterilerin aradığı dijital dönüşümü hızlandırmayı hedefliyorsanız ödüllendirici olabilir. Her zaman yeşil kalabilmek için, yazılım mühendisliğindeki kelebek etkisinin daha fazla görünürlük, öngörülebilirlik ve kontrolle yönetildiğinden emin olarak kuruluşların atması gereken bir yolculuktur; Tüm bu süre boyunca yeniliği, şeffaflığı, sınırsız potansiyeli benimsemek ve büyük hayal kurmaya cesaret etmek.
“Ölçülemez bütünün her yerinde bir şeyleri değiştirmeden tek bir kum tanesini bile yerinden kaldıramazsınız.”
– Fichte, İnsanın Mesleği (1800)
Bu, Sri Lanka’daki IFS Teknoloji ekibinin bir dizi gönderisinin bir parçasıdır. IFS Teknoloji ekibi, Oracle PL\SQL’den Angular’a, Java’ya, Kubernetes’e ve .Net’e kadar çözümlerimize güç veren temel teknolojileri etkinleştirir.
KAYNAK : Sayakkara, T. (2024, February 5). The butterfly effect in software engineering. IFS Blog. https://blog.ifs.com/2024/02/the-butterfly-effect-in-software-engineering/
