Menü

Kod Yeniden Düzenleme: Bununla İlgili Bilmeniz Gerekenler

code refactoring what you need know about it

Sorunları Ortadan Kaldırmak Için Enstrümanımızı Deneyin

Kod Yeniden Düzenlemeyi Anlama: Bir Test Uzmanının Perspektifi

'Yeniden düzenleme' terimi, temel olarak gerekli kod temizleme / yeniden tasarımını belirtmek için kullanılır.

Bu eğitimde, yeniden düzenlemenin tanımını anlayacak, kod yeniden düzenleme ihtiyacını tartışacak ve yeniden düzenleme kodunun çeşitli proje ekip üyeleri üzerindeki etkisini gözden geçireceğiz. Ayrıca en önemli sorunun cevabını da tartışacağız - Bir test uzmanı olarak neden yeniden düzenleme hakkında bilgi sahibi olmanız gerekiyor?

Ek olarak, kavramı açıklığa kavuşturmak için birkaç vaka çalışmasını da tartışacağız.

Yeniden yapılandırılan kod

Ne öğreneceksin:

Yeniden Düzenlemeye Giriş

Başlangıç ​​olarak, yeniden düzenlemenin gerçekte ne olduğunu anlayalım.

Yeniden düzenleme, temelde mevcut işlevselliği korurken kodu ve / veya veritabanını iyileştirme uygulaması veya işlemidir. Buradaki fikir, verimsiz ve aşırı karmaşık kodu daha verimli, tercihen daha basit ve daha kolay koda dönüştürmektir.

Kodun yeniden düzenlenmesi, Çevik Yazılım Geliştirme yaklaşımını izleyerek artık daha fazla ekip ile ivme kazandı. Proje ekiplerinin genellikle yeni özellikler uygulamak veya mevcut özelliklerin ve temiz kodun işlevselliğini genişletmek için sınırlı zamanı vardır. Anlaşılması ve bakımı kolay olan kod, yineleme son tarihini karşılamada kesinlikle uzun bir yol kat ediyor.

Kod Yeniden Düzenleme İhtiyacı

Uygulamanın veya modülün orijinal işlevselliğini sürdürüyorsak, şu soru ortaya çıkıyor: Neden yeniden düzenleme yapmakla uğraşıyoruz? Eh, belirli bir modülün veya kod parçasının yeniden düzenlenmesinin gerekebileceği çeşitli nedenler vardır, örneğin:

  1. Kod kokuyor
  2. Teknik borç
  3. Çevik yazılım geliştirme yaklaşımı vb.

Bu noktaları ilerleyen bölümlerde detaylı olarak tartışacağız.

# 1) Kod Kokuyor:

Hepimiz, yiyecek kokmaya başladığında bunun büyük olasılıkla kötüye gittiğini gösterdiğini anlayabiliriz - bu kod için de geçerlidir! Kod kokuları, kodda çok ciddi bir sorunun olabileceğinin göstergesidir.

Aşağıda bazı yaygın kod kokuları verilmiştir:

  • Gereksiz veya aynı kodun varlığı.
  • Kodun geri kalanında herhangi bir yerde kullanılmayan bildirilmiş bir değişken.
  • Aşırı karmaşık kod tasarımı.
  • Çok az şey yapan ve tanımlanan sınıfın varlığını haklı çıkarmayan kod sınıfı. Bu tür sınıflar tembel sınıf veya serbest yükleyici olarak bilinir.
  • Parçalanma ve basitleştirme potansiyeline sahip çok fazla koşul ve döngünün varlığı.
  • Kod, kodun bir bölümündeki bir değişikliğin, değişikliğin diğer yerlerde de uygulanmasını gerektirecek şekilde oluşturulur.

Zaman geçtikçe kod kokuları daha belirgin hale gelir. Uygulama veya sistem büyüdükçe, sonunda bu kod kokuları, aşırı senaryolarda kod geliştirme, bakım ve hatta sistem performansını etkilemeye başlar.

# 2) Teknik Borç:

Bir yazılım geliştirirken, sınırlı süre ve mevcut kaynaklar sırasında, istenen sonuçları elde etmek için genellikle kısayollar kullanabiliriz.

Mevcut bir modüle eklenmesi gereken bir özelliği düşünün. Tartışmadan sonra, ekip bu özelliği eklemek için 2 yaklaşımı daraltır. Yaklaşım A, teslim edilmesi 2 sprint alır, onaylanmış uzun vadeli yaklaşım olacaktır. Yaklaşım B'nin teslim edilmesi yalnızca 5 gün sürüyor ve modüle kısa vadede hizmet vermek için tasarlanmış, karmaşık, sabit kodlu bir hack.

Ekip, özelliği sınırlı bir süre içinde sunma konusunda baskı altındaysa, şimdilik Yaklaşım B'yi izlemeyi ve ileride iş yığınına Yaklaşım A'yı eklemeyi kabul edebilir. Bunu yaparak, bu ekip sadece teknik borcu yarattı.

Basit bir ifadeyle, yazılım geliştirmedeki teknik borç, uygun düzeltmeleri yerine getirmek veya işleri 'doğru şekilde' yapmak için gereken ek yeniden çalışma veya ek yükü ifade eder.

Eski Sistemler, zaman içinde büyük teknik borç alma eğilimindedir ve bu da, uygulamayı başarısız olmaya açık hale getirebilir ve desteklenmesi ve sürdürülmesi zor hale gelebilir.

Daha fazla oku=> Teknik Departman Nedir

# 3) Çevik Yazılım Geliştirme Yaklaşımının İzlenmesi:

Çevik yazılım geliştirme yaklaşımı, artımlı geliştirmeyi savunur. Temiz, iyi yapılandırılmış ve bakımı kolay kod olmadan, ekiplerin her yinelemede mevcut kodu genişletmeleri mümkün olmazdı. Kod, uygun şekilde yeniden düzenleme yapılmadan değiştirilirse, kod kokularına veya teknik borca ​​katkıda bulunabilir.

Bu ilişki aşağıdaki diyagramda gösterilmektedir

Çevik Yazılım Geliştirme Yaklaşımı

Önerilen Okuma => En İyi Kod Analiz Araçları

Bir KG'nin Yeniden Düzenleme Hakkında Bilmesi Neden Gerekir?

Şimdiye kadar bu eğitimde tartıştığımız her şey, kodlama ile ilgili görünüyor ve bir geliştiricinin endişelenmesi gereken şeylere benziyor.

Öyleyse, neden bu alakasız kavramı Yazılım Testi Yardım Topluluğu'nda tartışıyoruz? Bu sorunun cevabı için bu eğiticinin geri kalanını okumaya devam edin.

# 1) Birim Test Edenler / Geliştiriciler İçin

Kod yeniden düzenlenirken, yeni kod eklenirken, eski sınıflar güncelleniyor, yeni sınıflar ekleniyor ve mevcut Birim testleri artık başarısız olabilir. Ek olarak, eski sistemler için hiçbir birim testi uygulanmayabilir. Çoğu durumda bu yeni birim testlerinin sıfırdan oluşturulması ve kurulması gerekecektir.

# 2) Test Uzmanları İçin

Bir özellik yeniden düzenlenirken (herhangi bir yeni işlevsellik eklemediğimizi göz önünde bulundurarak), anlayış, gerekli değişiklikler yapıldıktan sonra, son kullanıcı için işlevlerin çoğunun aynı kalması gerektiğidir.

  • Bir test uzmanı olarak, kodun yeniden düzenlenmesi kabaca = derinlemesine test + regresyon testi anlamına gelir. Tüm işlevlerin daha önce olduğu gibi çalıştığından emin olmak için derinlemesine testin mevcut tüm kullanıcı akışlarını içermesi gerekir. Gerileme testi Tüm uygulamanın (veya etkilenen alanların), bir modülü yükseltmenin diğer modüllerin işlevselliğini istemeden bozmamasını sağlamak için gereklidir.
  • Kullanıcı kabul testleri önemli olacaktır ve yapının piyasaya sürülmeye hazır olarak ilan edilebilmesi için bu testlerin geçilmesi gerekir.
  • Ek olarak, yük testleri gibi gerekli diğer testler, güvenlik testi vb. de gerektiği gibi uygulanmalıdır.

# 3) Otomasyon Test Mühendisleri

Kodun yeniden düzenlenmesi, işlevsel ve işlevsel olmayan otomasyon komut dosyalarının başarısız olmasına neden olabilir.

Bu, aşağıdaki nedenlerden dolayı meydana gelebilir:

  • Sayfa nesneleri, yeniden düzenleme çabasının bir parçası olarak değişirse ve Selenium otomasyon komut dosyalarınız sayfa nesnelerine dayanıyorsa, komut dosyaları başarısız olur ve güncellenmeleri gerekir.
  • Küçük değişiklikler varsa, yeniden düzenleme sırasında eklenen veya kaldırılanları yeniden yönlendirir ve mevcut otomasyon komut dosyaları başarısız olur ve güncellenmesi gerekir.

Fonksiyonel otomasyon testlerinin yalnızca bir özellik kararlı hale geldikten sonra kurulması tavsiye edilir, aksi takdirde özellik geliştikçe çok sayıda yeniden çalışma ile sonuçlanacaktır.

Otomasyon testlerinin geliştiricisi olan otomasyon test mühendislerinin de bir geliştirici gibi düşünmeleri ve temiz ve bakımı kolay bir kod oluşturmayı hedeflemeleri gerekir. IntelliJ IDEA, Eclipse vb. IDE’lerin çoğu, kolay başvuru için yaygın olarak kullanılan yeniden düzenleme yöntemleriyle yerleşik yeniden düzenleme menüsü içerir.

Aşağıda IntelliJ IDEA'da (Topluluk Sürümü) yeniden düzenleme menüsünün bir ekran görüntüsü bulunmaktadır.

çalışmak için en iyi oyun şirketi

yeniden düzenleme menüsü

# 4) Test Talepleri / KG Talepleri İçin

  • Bu tür projeler için Test planlamasının dikkatli bir şekilde yapıldığından emin olmak için Test Liderlerinin / QA Liderlerinin geliştiriciler, Ürün analisti ve hatta paydaşlar dahil olmak üzere ekibin geri kalanıyla birlikte çalışması gerekebilir.
  • Mevcut işlevselliği anlamak önemlidir. Mevcut işlevselliğe bağlı olarak, iş durumları, kullanıcı akışları ve kullanıcı kabul testleri belgelenmelidir. Yeniden düzenlenmiş bir kod test edilirken, tüm bu senaryoların, etkilenen alanların regresyon testiyle birlikte doğrulanması gerekir.
  • Test yaklaşımını planlarken proaktif olun ve test planları . Birden fazla test ortamı veya yeni test aracı gerekliliğini öngörüyorsanız, test aşaması başladığında herhangi bir gecikmeyi önlemek için lütfen talebi erken gönderin.
  • Teste katkıda bulunmaları için proje dışı ekip üyelerini veya son kullanıcıları dahil etmekten çekinmeyin.

Durum çalışmaları

Şimdi doğrudan üzerinde çalışma ya da dolaylı olarak katkıda bulunma fırsatım olan bazı gerçek hayat vaka çalışmalarını tartışacağız.

Örnek Olay # 1

Görev: Sabit kodlanmış değerleri değişkenlerle değiştirmek için bir modülü yeniden düzenleyin ve yeni otomatik teknik belge oluşturma aracı için yorumlar ekleyin.

Zorluklar :Büyük zorluk yok. Modül yeniydi, işlevsel ve kullanıcı kabul gereksinimlerini, kullanıcı akışlarını ve test durumlarını belgeliyordu. Birim testleri, ilk başlatma sırasında kuruldu.

Test Yaklaşımı :Modül için test senaryoları yeniden düzenlendi ve nispeten bilinen etkilenen alanlar yürütüldü. Tüm kusurlar, sürümden önce bildirildi ve çözüldü.

Örnek Olay # 2

Görev :Uygulama ölçeğini büyütmeyi kolaylaştırmak için mevcut saklı yordamı yeniden düzenleyin.

Bu senaryodaki saklı yordam, uygulamanın depolanmış yordamını 10'dan az eşzamanlı oturuma sahip dahili bir uygulama olarak kullanması gerekliliği akılda tutularak birkaç yıl önce tasarlanmış eski bir saklı yordamdı.

Şimdi şirket bu uygulamayı bir Hizmet Olarak Yazılım (SaaS) olarak pazarlamak istiyordu ve başlangıçta beklenen 300 eşzamanlı oturum hacmi ile.

Ekip, bazı ilk yükleme testleri yaptı ve sistemin eşzamanlı 25 oturumluk bir yük ile kırıldığı sonucuna vardı. Ekip kodu gözden geçirdi ve uygulamanın bozulmadan 500'e kadar eşzamanlı oturumu ölçeklendirmesine ve desteklemesine olanak tanıyan mevcut bir çekirdek saklı yordamı yeniden düzenlemeyi önerdi.

Bu saklı yordamla tanımlanan bazı sorunlar, tek bir sorgu içinde birden çok alt sorgu, tablolar yerine görünümlerle yoğun birleşmeler, belirli bir sütun seçmek yerine seçme * kullanılması vb. İdi. Bu kodlama sorunları nedeniyle, uygulama bundan daha fazla veri alıyordu gerçekten gerekliydi, bu nedenle uygulamanın yavaşlamasına ve sonunda çökmesine neden oluyordu.

Zorluklar:

# 1) Proje Yöneticisi / Ürün Analisti

  • Şartlı toplantı - Bu saklı yordam eski bir kod olduğundan, modül ilk tasarlandığında bunun için belgelenmiş gereksinimler yoktu. Ayrıca, son birkaç yılda yapılan yinelemeler için, modüle eklenen veya çıkarılan iş kurallarını ve mantığı gösteren herhangi bir değişiklik günlüğü yoktu.
  • Proje takvimi - Gereksinimler açıkça tanımlanmadığı ve kod bağımlılıkları henüz tam olarak tanımlanmadığı için, geçici programı iletmek zordu.

# 2) Geliştiriciler İçin

  • Net gereksinimlerin ve iş kurallarının eksikliği.
  • İşlevselliğini kaybetmeden kodu temizleme.
  • Bilinmeyen etkilenen alanlar ve / veya kod bağımlılıkları.
  • Somut geliştirme süresi tahminleri sağlanamıyor.
  • Yeni Birim Testleri oluşturmanız gerekiyor.

# 3) Test Uzmanları İçin

  • Net gereksinimlerin ve iş kurallarının eksikliği test planlamasını etkiler.
  • Bilinmeyen etkilenen alanlar, özellikle regresyon testleri için test planlamasını etkiler.
  • Somut test tahminleri sağlanamıyor.

# 4) Paydaşlar

  • Açıkça belgelenmiş gereksinimlerin ve / veya kullanıcı akışlarının eksikliği + sıkı son tarihler = Daha yüksek arıza riski.

Ekibin riskleri azaltmak ve zorlukların etrafında çalışmak için izlediği yaklaşım :

(i) Ekip, gereksinimleri toplamak için işbirliğine dayalı bir yaklaşım izledi : Proje Yöneticisi / Ürün Analisti ve Test Uzmanları, temel işlevleri ve kullanıcı akışını anlamak ve belgelemek için dahili son kullanıcılarla yakın bir şekilde çalıştı.

Geliştiriciler ayrıca kodu incelediler ve gereksinimler belgesine ilgili bilgileri eklediler. Bu, sprint başlangıç ​​gününden önce yapıldı.

(ii) Uygulanmakta olan değişikliği test etmek için alternatif test ortamı oluşturuldu : Bu ortamlara Gamma ve Phi diyelim. Gama eski koda sahip olacak ve Phi her zaman en son yeniden düzenlenmiş saklı yordama sahip olacaktı.

Paralel olarak 2 test ortamına sahip olmak, yaklaşımdan önce ve sonra neredeyse yeniden oluşturmak, ekibin bu 2 test ortamındaki davranışı karşılaştırarak daha derinlemesine ve keşifsel testler yapmasına olanak tanıdı, olası hataları belirleyebildiler.

Ekip, sprint başlangıç ​​tarihinden önce sağlanan alternatif bir test ortamı için gereksinimleri sağladı.

(iii) Erken teste dahil olan son kullanıcılar ve paydaşlar : Ekibe gerekli düzeltmeyi dağıtması ve test etmesi için daha fazla zaman tanınmasının ardından, bariz tüm sorunlar erken tespit edildi ve rapor edildi.

(iv) Çıkış kriterlerinin tanımlanması ve buna bağlı kalınması: Çıkış kriterleri, ilk planlama aşamalarında tanımlandı -% 80 kullanıcı akışı test edildi, hiçbir kritik hata çözülmedi, piyasaya sürülmeden önce paydaşların demosu ve onayı.

(v) Geçici bir yayın tarihi belirleme: Yayın tarihini hizalı ve ekibi ortak bir son noktaya doğru çalışmaya motive etmek. Ekip, projenin kapsamına bağlı olarak, ekibin projeyi yürütmesi için yeterli zaman sağlamak için normal 2 haftalık bir sprint yerine 3 haftalık bir sprintin takip edilmesi önerildi.

Sonuç

Özetlemek gerekirse, kodun yeniden düzenlenmesi, işlevselliğini değiştirmeden bir modülün tasarımını temizleme / basitleştirme işlemidir. Yeniden düzenleme süreci, yorum eklemek, doğru girinti eklemek, statik bir değişkeni kaldırmak vb. Gibi basit olabilir veya karmaşık eski sistemler için karmaşık olabilir.

Kod kokuları, teknik borç nedeniyle veya çevik bir yazılım geliştirme yaklaşımı izleyerek belirli bir modül veya kod parçasının yeniden düzenlenmesi gerekebilir.

Test uzmanları için, kodun yeniden düzenlenmesi kabaca = derinlemesine test + regresyon testi anlamına gelir.

Tüm işlevlerin eskisi gibi çalışıp çalışmadığından emin olmak için tüm mevcut kullanıcı akışlarını test etmek için derinlemesine test gereklidir. Bir modülü yükseltmenin diğer modüllerin işlevselliğini istemeden bozmamasını sağlamak için tüm uygulamanın (veya etkilenen alanların) gerileme testi gereklidir.

Test Liderleri / Kalite Güvencesi Liderlerinin, özellikle eski projeler için geliştiriciler, Ürün analisti dahil olmak üzere ekibin geri kalanıyla birlikte çalışması gerekebilir. Test yaklaşımını ve test planlarını planlarken proaktif olun. Birden fazla test ortamı veya yeni test aracı gerekliliğini öngörüyorsanız, test aşaması başladığında herhangi bir gecikmeyi önlemek için lütfen talebi erken gönderin.

Yazar hakkında: Bu bilgilendirici eğitim, Neha B tarafından yazılmıştır. Şu anda Kalite Güvence Müdürü olarak çalışmaktadır ve şirket içi ve Offshore QA ekiplerini yönetme ve yönetme konusunda uzmanlaşmıştır.

Kodun veya bir modülün / uygulamanın yeniden düzenlenmesini içeren zorlu bir proje üzerinde çalıştınız mı? Cevabınız evet ise, test arkadaşlarımızın öğrenebileceği yorumlar bölümünde deneyimlerinizi paylaşmaktan çekinmeyin.

Önerilen Kaynaklar

^