Bir üretim sistemi üzerinde yeniden kullanım ve regresyon testi maliyetini ilişkilendiren bir yazılım mühendisliği prensibi var mı?

Emeklilik ve Yatırımlara bakan bir banka için büyük bir finansal işlem sistemi üzerinde çalıştım. 15 yıllık özellik değişikliklerinden sonra, manuel regresyon testi maliyeti yayın başına 200 bin dolara yükselmişti. (10 milyon LOC, günde 10 milyon ABD doları işlem yapılır). Bu sistem aynı zamanda çok sayıda veriyi hareket ettiren şirketin çevresindeki diğer 19 sistemle de bağlantı kurar. Bu sistem Java ile uygulanmıştır.

Ancak gözlemlediğimiz, ne kadar 'tekrar' kullandığımız zaman regresyon testi maliyetlerinin artmasıdır. (Bunun nedeni "dokunduğunuz kodu test etmeniz" gerektiğidir - ve tekrar kullanılan / paylaşılan kod dokunduğunuzda çok sayıda yeri etkiler. Bu yüzden 'KURU - Kendinizi Tekrar Etmeyin' - yani kodu kopyalayıp yapıştırmayın - kodu kopyalayıp yapıştırmak için finansal bir teşvik gözlemliyoruz. Bu, regresyon testi maliyetlerini düşürmek içindir, çünkü paylaşılabilecek kodu değiştirmek istemiyoruz, çünkü bu büyük bir regresyon testi etkisine neden olacaktır.)

Benim sorum, yeniden kullanım ve regresyon testi maliyetleri arasındaki ilişkiyi tanımlayan bir yazılım mühendisliği prensibi var mı?

Bu soruyu sormamın nedeni, sistemin test edilecek daha küçük parçalara ayrıştırılmasında maliyet avantajı olması.

Varsayımlar:

1. 'Regresyon testi', 'kabul testi' anlamına gelir - yani çevre ve veri kurulumları da dahil olmak üzere, işletme adına sisteme yeni testler yazmak ve sisteme karşı eski testleri yeniden kullanmak için zaman harcayan başka bir grup.

2. Biliyorum ki büyük bir regresyon testi maliyetine diz-sarsıntı tepkisi 'daha otomatik testler'. Bu iyi bir prensip. Bu ortamda birkaç zorluk var.

   (a) Otomatik testler, sistem otomatik olarak yüksek bir test kapsamına sahip olmadığı sürece, sistem sınırları boyunca daha az yararlıdır. (Etki alanı meydan okuması).

   (b) Sisteminiz zaten büyük ve karmaşık olduğunda, programlayıcı zamanında ivme veya yüksek otomatik test kapsamına sermaye yatırımı yapmak kültürel olarak zordur.

   (c) Otomatik testleri sürdürmenin maliyeti bir projede gizlidir ve bu nedenle proje düzeyinde kolayca atılırlar.

   (d) Bu sadece bir bankada çalışmanın kültürel gerçekliğidir.

   (e) Bu sorunu farklı bir şekilde çözmek için çalışıyorum (ayrışma).

paylaşılabilecek kodu değiştirmek istemiyoruz, çünkü bu büyük bir regresyon testi etkisine neden olacaktır

Yukarıdaki sesler bana doğru geliyor. Kod ne kadar önemli olursa, o kadar fazla paylaşılır, kalite gereksinimleri o kadar yüksek olur, değiştiğinde daha fazla kalite güvencesi dahil edilmelidir.

Sisteminiz Java'da uygulandığından, Java standart kitaplıklarında (JDK) yukarıda bunun için bir örnek görebilirsiniz. Başlıca sürümleri nadirdir ve çok çaba harcayan testlere eşlik eder. Ve küçük sürümler bile gerilemelerin olmadığını doğrulamak için çok kapsamlı JCK test paketinden geçer.

Bunun bir şekilde paylaşılan kodun evrimini bastırdığını düşünebilirsiniz ve ... evet bu doğru. Kod değişikliği ile ne kadar çok etki ve risk ilişkilendirilirse, bunu yapmak konusunda ne kadar dikkatli olmalısınız, sürümlerini test etmek için daha fazla çaba harcanması gerekir.

İdeal olarak, yaygın olarak paylaşılan kod sürümlerinin kalitesi, büyük değişikliklere ihtiyaç duymayacak şekilde olmalıdır (seyrek geliştirmeler için kaydedin). Bu düşünce hattı Joshua Bloch'un ünlü bir alıntısında yansıtılır :

Elmaslar gibi herkese açık API'lar sonsuza kadar. Doğru bir şansınız var, bu yüzden elinizden geleni yapın.

Yukarıda bahsedilen ile, tarif ettiğiniz bazı sorunların paylaşılan kod geliştirme verimsiz stratejisi kaynaklanıyor gibi görünüyor. Özellikle, yeniden kullanılan kod için sadece iki seçeneğin dikkate alınması özellikle zordur: ya bu kodu çoğaltın ya da hemen "çekirdek" paylaşılan kütüphanelere ekleyin.

Yalnızca bu iki seçeneğe sınırlanmak gereksizdir ve yine, kullandığınız JDK'da bunun nasıl daha iyi yapılabileceğine dair örnekler bulabilirsiniz. java.util.concurrentPaketlere bir göz atın ( JSR 166 ) - Java 5 sürümüne kadar, bunlar temel JDK sürümlerinin bir parçası değil, ayrı bir kütüphane idi.

Bir düşünün, bu göz ardı ettiğiniz üçüncü bir seçenek ve oldukça paylaşılan, yeni paylaşılan kodun "başlangıcında" düşünmeniz gereken seçenek. Eğer sadece bazı anlamaz paylaşılabilir kodu 2-3 bileşenleri arasındaki, hiçbir şey kuvvetleri sen sisteminin çekirdek API içine dahil hemen hiç.

Bu "olgunlaşmamış" paylaşılan kodu, tıpkı Java eşzamanlı yardımcı programlarında yapıldığı gibi ayrı bir kitaplık olarak paketleyebilir ve serbest bırakabilirsiniz. Bu şekilde sizi tam regresyon testi gereksiniminden kurtarır, çünkü yalnızca nispeten az miktarda ilgili bileşen kullanabilirsiniz. Sonuç olarak, bu paylaşılan kodu değiştirmek ve geliştirmek ve üretimde nasıl çalıştığını test etmek için daha fazla boşluğa sahipsiniz.

Kitaplığınız, daha sonraki değişikliklerin mümkün olmadığı konusunda size güven verecek kadar olgunlaştıktan ve stabilize edildikten sonra, tıpkı eşzamanlı yardımcı programların sonunda JDK'ya dahil edildiği gibi, sistemin çekirdek kütüphanelerine dahil edilmesini düşünebilirsiniz.

Yeniden kullanılan kodun değiştirilmesinde ne kadar çaba harcanabileceğinin (testler dahil) somut bir örneği yine JDK'da bulunabilir. 7u6 sürümünde String, substringperformansta bir değişiklik içeren iç temsili değiştirdiler . Reddit'teki bir özellik geliştiricisinin yorumları, bu değişikliğe ne kadar çaba harcadığını özetliyor:

İlk analiz 2007 yılında GC grubundan çıktı ...

Dahili olarak Oracle performans ekibi, performans değişikliklerini değerlendirmek için kullandıkları bir dizi destekleyici ve önemli uygulama ve ölçüt barındırır. Bu uygulama grubu, alt dize değişikliğini değerlendirmede çok önemliydi. Hem performans değişimlerine hem de ayak izindeki değişime yakından baktık. Kaçınılmaz olarak, herhangi bir önemli değişiklikte olduğu gibi, bazı uygulamalarda gerilemeler ve diğerlerinde kazançlar vardı. Performansın hala kabul edilebilir olup olmadığını ve doğruluğun korunup korunmadığını görmek için regresyonları araştırdık ...

Benim cevap ayrıntılı olması amaçlanmamıştır ama ne olduğunu çok kısa özetidir değildir adanmış işin neredeyse altı ay ...

"Regresyon testleri için maliyet / inşa yeniden kullanılan kod LOC" hesaplamak için herhangi bir metrik var sanmıyorum. Ve hiç kimsenin aynı "büyük" sistemi iki kez oluşturmak için çok fazla zaman ve para harcadığını düşünmüyorum.

Ama daha önce sizinki gibi tekrar kullanmanın neden olduğu sorunları gördüm ve belki de bunun nasıl daha iyi ele alınacağına dair bazı düşüncelerinizle ilgileniyorsunuz.

Birincisi, aslında sizin probleminiz olan yeniden kullanım değil - daha çok kendi yeniden kullanılabilir bileşenlerinizi oluşturma ve bunları sisteminizde kullanma girişimi. Sorunlarınızın ortaya çıkmadığı birçok büyük yazılım paketini tekrar kullandığınızdan eminim: kullandığınız tüm Java yığınını veya belki de bazı üçüncü taraf bileşenlerini (bu bileşenlerden memnun olduğunuz varsayılmıştır) düşünün. Ancak, kendi yeniden kullanılabilir bileşenleriniz size çok fazla ek regresyon testi maliyetine neden olurken, bu yazılımdan, örneğin Java kitaplıklarından farklı olan nedir? Farklı olabileceğini düşündüğüm bazı noktalar:

• bu bileşenler çok olgun ve kararlı

• tamamen farklı bir kuruluş tarafından ayrı ayrı geliştirilmiş ve test edilmiştir

• bunları (yeniden) kullanmak için, onları değiştirmeniz gerekmez (aslında, kaynak kodunu korumadığınız için, bunu isterseniz bile yapamazsınız)

• günlük olarak yeni bir sürüm, yalnızca küçük güncellemeler (ayda maksimum) veya yıllık aralıklarla büyük güncellemeler almazsınız

• çoğu güncelleme% 100 aşağı doğru uyumlu olacak şekilde tasarlanmıştır, özellikle küçük güncellemeler

Dolayısıyla, kendi yeniden kullanılabilir bileşenlerinizi daha başarılı hale getirmek için, yukarıdan bazı şeyleri kendi gelişiminize uyarlamanız gerekir:

• yeniden kullanılabilir herhangi bir bileşen için, bakımı kimin yaptığını açık bir sorumluluğa sahip olun ve bir bileşeni yeniden kullanan tüm kişilerin, sorun çıkması durumunda derhal bir hata düzeltmesi yapabileceğinden emin olun.

• katı bir sürüm oluşturma ve yayınlama politikaları oluşturmak. Yeniden kullanılabilir bir bileşen geliştirirken, bunu her gün "herkese" bırakmayın (en azından sistemde tam 200 bin dolarlık bir regresyon testi yapılması anlamına gelmezse). Bunun yerine, yeni sürümlerin yalnızca zaman zaman yayınlanmasına izin verin ve bu bileşenin kullanıcısının yeni sürümdeki değişikliği ertelemesine izin veren mekanizmalar sağlayın.

• bir bileşen ne kadar sık ​​kullanılırsa, kararlı bir arayüz ve aşağı doğru uyumlu davranış sağlaması o kadar önemlidir.

• tekrar kullanılabilen bileşenler, ayrı ayrı test edilmek için çok eksiksiz test takımlarına ihtiyaç duyarlar.

Bunların çoğu, bileşenin kendisini inşa etme maliyetinin artacağı anlamına gelecektir, ancak başarısız gerilemelerin neden olduğu değişikliklerin maliyetini de azaltacaktır.

Daha fazla teste ihtiyaç duyulması nedeniyle maliyette "gözlemlenebilir" bir artış olsa da, bu tür yeniden düzenleme, sistemdeki teknik borcu azalttığınız için gelecekte kodu genellikle daha sürdürülebilir hale getirir.

Bu, umarım gelecekteki hataları azaltmalı ve mevcut özelliklerde yeni özelliklerin veya değişikliklerin uygulanmasını kolaylaştırmalıdır.

Daha kolay olarak, daha az zaman almaları ve bu nedenle daha az maliyetli olmaları gerekir.

Azaltmak, daha kolay ve daha azı burada oldukça belirsiz terimlerdir ve gelecekteki tasarrufların (veya tasarruf için daha çok umulduğu) henüz gerçekleşmediği gibi hesaplanması imkansızdır.

Daha basit bir kod tabanı, yeni çalışanların veya projeye devam eden mevcut çalışanların, özellikle büyük sistemler için daha hızlı hızlanmasına izin vermelidir.

Ayrıca, mevcut proje üyeleri moralinin iyileştirilebilmesi nedeniyle personel devir hızını azaltabilir.

Elbette bu faydaları alacağınız garanti edilmez, ancak bunlar ölçülebilecek maliyetlerle birlikte (artırılmış test gibi) dikkate alınması gereken şeylerdir.

Aslında, daha iyi kod, açıkladığınız şeyden dolayı ilk artış olsa bile, zaman içinde test maliyetlerini azaltmalıdır.