Bilinen bir hata giderildiğinde yeni hataların başka bir yerde görünmesinin nedeni ne olabilir?

Bir tartışma sırasında meslektaşlarımdan biri, hataları çözmeye çalışırken mevcut projesiyle ilgili bazı zorlukları olduğunu söyledi. “Bir hatayı çözdüğümde, başka bir yerde başka bir şey çalışmayı bırakıyor” dedi.

Bunun nasıl olabileceğini düşünmeye başladım, ama anlayamıyorum.

• Bazen doğru iş yapmak ve üzerinde çalıştığım kod parçası genel bir görünümü için çok yorgun / uykulu olduğumda benzer sorunları var. Burada, sorun birkaç gün veya hafta sürüyor gibi görünüyor ve meslektaşımın odağıyla ilgili değil.
• Ayrıca , takım arkadaşlarının kimin ne yaptığını ve başkalarının çalışmaları üzerinde hangi etkinin yaptıklarını değiştirebileceği hakkında hiçbir fikri olmadığı çok kötü yönetilen çok büyük bir projede ortaya çıkan bu problemi hayal edebiliyorum . Burada da durum böyle değil: sadece bir geliştiriciye sahip oldukça küçük bir proje.
• Aynı zamanda , bir değişikliğin sonuçlarını yıllar önce gerçekten terk edebilen tek geliştiricilerin yıllar önce şirketten ayrıldığı eski, kötü bakım yapılmış ve hiç belgelenmemiş kod tabanı ile ilgili bir sorun olabilir. Burada proje yeni başladı ve geliştirici kimsenin kod tabanını kullanmıyor.

Peki , çalışmasına odaklanan tek bir geliştirici tarafından yazılan taze, küçük boyutlu bir kod tabanında böyle bir sorunun nedeni ne olabilir ?

Ne yardımcı olabilir?

• Birim testleri (hiç yok)?
• Uygun mimari (kod temeli hiç mimarisi yoktur ve hiçbir ön düşünme ile yazılmış eminim), tüm yeniden düzenleme gerektiren?
• Çiftler programı?
• Başka bir şey?

Odak, proje boyutu, dokümantasyon veya diğer süreç sorunları ile ilgisi yoktur. Bunun gibi sorunlar genellikle tasarımdaki aşırı bağlantının bir sonucudur , bu da değişiklikleri izole etmeyi çok zorlaştırır.

Sebeplerden biri, yazılımınızın bileşenleri arasında sıkı bağlantı olabilir : bileşenler arasında basit, iyi tanımlanmış arabirimler yoksa, kodun bir bölümündeki küçük bir değişiklik bile, yazılımın diğer bölümlerinde beklenmeyen yan etkiler yaratabilir. kodu.

Örnek olarak, son zamanlarda uygulamamda bir GUI bileşeni uygulayan bir sınıf üzerinde çalışıyordum. Haftalarca yeni hatalar rapor edildi, düzeltildi ve başka bir yerde yeni hatalar ortaya çıktı. Sınıfın çok büyüdüğünü, çok fazla şey yaptığını ve birçok yöntemin düzgün çalışması için doğru sırayla çağrıldığına bağlı olduğunu anladım.

Son üç hatayı düzeltmek yerine, bazı güçlü yeniden düzenleme yaptım: bileşeni bir ana sınıfa ve MVC sınıflarına (üç ek sınıf) ayırın. Bu şekilde kodu daha küçük, daha basit parçalara ayırmak ve daha net arayüzler tanımlamak zorunda kaldım. Yeniden düzenleme işleminden sonra tüm hatalar çözüldü ve yeni bir hata rapor edilmedi.

Bir hatanın diğerini maskelemesi kolaydır. Diyelim ki "A" hatası girdiyi işlemek için yanlış işlevin çağrılmasına neden oluyor. "A" hatası düzeltildiğinde, aniden doğru test çağrılır ve bu daha önce hiç test edilmemiştir.

Bunun asıl nedeni, iki yanlışın bir doğru yapmak veya en azından açık bir şekilde yanlış yapmamaktır. Kodun bir kısmı, diğer parçanın yanlış davranışını telafi ediyor. Veya ilk bölüm bu şekilde "yanlış" değilse, iki bölüm arasında kod değiştirildiğinde ihlal edilen bazı yazılı olmayan anlaşmalar vardır.

Örneğin, A ve B işlevlerinin bir miktar için sıfır tabanlı bir kural kullandığını varsayalım, bu nedenle birlikte doğru çalışırlar, ancak C bir tanesini kullanır, A'yı C ile çalışmak için "düzeltebilir" ve sonra B ile ilgili bir sorun keşfedebilirsiniz.

Daha derin sorun, münferit parçaların doğruluğunun bağımsız olarak doğrulanamamasıdır. Birim testleri buna yönelik olarak tasarlanmıştır. Ayrıca uygun girdilerin spesifikasyonu olarak da işlev görürler. Örneğin, iyi bir test seti A ve B fonksiyonlarının 0 tabanlı girdi ve C 1 tabanlı olduğunu açıkça ortaya koyacaktır.

Spesifikasyonların doğru yapılması, projenin ihtiyaçlarına bağlı olarak, resmi belgelerden koddaki iyi yorumlara kadar başka yollarla da yapılabilir. Anahtar, her bir bileşenin ne beklediğini ve ne vaat ettiğini anlamaktır, böylece tutarsızlıkları bulabilirsiniz.

İyi mimari, kodu anlama sorununa yardımcı olarak bunu kolaylaştırır. Çift programlama, ilk etapta hataları önlemek veya daha hızlı bulmak için yararlıdır.

Bu yardımcı olur umarım.

Sıkı bağlantı, test eksikliği, bunlar muhtemelen en yaygın suçlular. Temel olarak ortak sorun sadece kalitesiz standartlar ve prosedürdür. Başka bir doğru kod ile bir süre şanslı yönetmek yanlış kod yönetme. memcpyLinus Torvalds'ın, uygulamayı değiştirmenin, örtüşen kaynak ve hedef ile memcpykullanmaları gereken yerlerde kullanılan istemcilerde hatalara (neden değil) maruz kaldığı hatayı düşünün memmove.

Bu "yeni" hatalar aslında "yeni" hatalar gibi görünmüyor. Kırılan diğer kod aslında düzeltilinceye kadar sadece bir sorun değildi. Başka bir deyişle, iş arkadaşınız, tüm zaman boyunca aslında iki böceğin olduğunu fark etmiyor. Bozulması kanıtlanmayan kod kırılmamış olsaydı, diğer kod parçası gerçekten düzeltildikten sonra başarısız olmazdı.

Her iki durumda da daha iyi bir otomatik test rejimi yardımcı olabilir. İş arkadaşınızın mevcut kod tabanını birim olarak test etmesi gerektiği anlaşılıyor. Gelecekte regresyon testi mevcut kodun çalışmaya devam edeceğini doğrulayacaktır.

Otomatik test rejiminizin genişliğini artırın . Kod değişikliklerini gerçekleştirmeden önce DAİMA testlerin tamamını çalıştırın. Bu şekilde, değişikliklerinizin zararlı etkisini tespit edersiniz.

Bir test yanlışken bu sorunla karşılaştım. Test, doğru olan bir izin durumunu kontrol etti. Kodu güncelledim ve izin testini yaptım. İşe yaradı. Sonra tüm testleri yaptım. İşaretli kaynağı kullanan tüm diğer sınamalar başarısız oldu. Testi ve izin kontrolünü düzelttim, ama ilk başta biraz panik vardı.

Tutarsız özellikler de gerçekleşir. Daha sonra, bir hatayı düzeltmenin başka bir hata yaratacağı neredeyse garanti edilir (spesifikasyonun belirli bir kısmı projede daha sonraya kadar kullanılmadığında heyecan verici).

Eksiksiz bir ürününüz olduğunu düşünün. Daha sonra yeni bir şey eklersiniz, her şey yolunda görünüyor, ancak yeni bir özelliğin çalışması için değiştirdiğiniz bazı kodlara bağlı olan başka bir şey kırdınız. Herhangi bir kodu değiştirmeseniz bile , sadece mevcut olanlara işlevsellik ekleyin, başka bir şey kırılabilir.

Temel olarak neredeyse kendinize cevap verdiniz:

• gevşek bağlantı
• test eksikliği

Sadece TDD prensibini uyarlamayı öğrenin (en azından yeni özellikler için) ve olabilecek her durumu test etmeye çalışın.

Çift programlama harika, ama her zaman "mevcut" (zaman, para, her ikisi de ..). Ancak, kod incelemeleri (örneğin iş arkadaşlarınız tarafından) günde / haftada / taahhütler kümesinde, özellikle inceleme test paketini içerdiğinde de çok yardımcı olacaktır. (Suitleri test etmek için hata yazmak zor buluyorum ... bazen testi dahili olarak test etmeliyim (akıl sağlığı kontrolü) :)).

Diyelim ki A geliştiricisi bir hata içeren bazı kodlar yazdı. Kod tam olarak ne yapması gerektiği değil, biraz farklı bir şey. Geliştirici B, A'nın kodunun tam olarak ne yapıldığını yapmasına dayanan bir kod yazdı ve B'nin kodu çalışmıyor. B araştırır, A kodundaki yanlış davranışı bulur ve düzeltir.

Bu arada geliştirici C'nin kodu sadece A'nın yanlış davranışına güvendiği için doğru çalıştı. A'nın kodu şimdi doğru. Ve C'nin kodu durur. Bu, kodu düzelttiğinizde, bu kodu kimin kullandığını ve davranışlarının sabit kodla nasıl değişeceğini çok dikkatli bir şekilde kontrol etmeniz gerektiği anlamına gelir.

Başka bir durumum var: Bazı kodlar hatalı davranıyor ve bir özelliğin X bazı durumlarda çalışmasını tamamen durdurdu. Bu yüzden hatalı davranışı değiştirdim ve bu özelliği çalıştırdım. Talihsiz yan etki, tüm özelliğin X durumunda önemli sorunlara sahip olması ve her yerde başarısız olmasıydı - bu durum daha önce hiç ortaya çıkmamış olduğu için herkes tarafından tamamen bilinmiyordu. Bu zor.