Başka bir şey üzerinde çalışırken önceden var olan hataları düzeltmeli misiniz?

Uzlaşma: Yeni bir özellik üzerinde çalışırken veya bir kusuru giderirken, kodda eski bir sorun bulursunuz. Ne yapmalısın? Düzelt ve kodun davranışını değiştirme riski. Ya şimdiye kadar bir şans eseri çalışıyor ya da kusur tespit edilmedi ya da kimsenin bildirmeye zaman ayırmaya değer. Bunu yalnız bırakmalı ve sorunun daha sonra çalışmasını zorlaştırmasına izin vermeli misiniz? Sorunu çözmek yalnızca orijinal görevinizin zamanına katkıda bulunacak ve sizi regresyon testine zorlayacaktır. Çok az iş takdir edecek. Ancak bunu düzeltmek bir şekilde doğru görünüyor. Daha az problemi olan kodların yeniden düzenlenmesi ve yeniden yapılandırılması daha kolaydır.

Bir web uygulamasını modernize etmeye çalışırken kendimi bu durumda defalarca buluyorum. Bu eski böcekler üzerinde teğet çalıştığımda takıntılı veya onurlu olup olmadığımı söyleyemem. Bu durumlarla nasıl başa çıkıyorsunuz?

Teşekkürler Corey

Çok küçük bir ekip üzerinde çalışıyorum, bu yüzden değişikliğin ne olduğuna bağlı:

Eğer onun küçük, açık bir hata düzeltme, kesinlikle bunun için gitmek. Ben de başkalarının kodu ve bana "boyscout kuralı" kapsamına giren diğer küçük iyileştirmeler yoluyla çalışmak zorunda kalırsanız ekstra yorum atmak.

Kod o kadar dolaşmışsa, "Bu bir şeyi değiştirecek ve test gerektirecek" diye sormanız gerekir, o zaman hayır, değiştirmemelisiniz. Sizi endişelendiriyorsa, hata izleme sisteminize getirin.

Bu arada, daha küçük tip imzalarla daha küçük yöntemleri kodlamaya çalışmamın nedeni de budur. Yan etkileri olmadığını ve giriş ve çıkışların eşleşmesini sağlayabiliyorsanız, iç kodlardan herhangi birini risk almadan düzeltebilir, yeniden düzenleyebilir veya düzenleyebilirsiniz.

Ancak takdir eksikliği, bulduğunuz hataları düzeltmemek veya herhangi bir nedenle kod tabanını geliştirmek için bir neden değildir. Başka bir şey yoksa, başka bir şeyi düzeltmek için oraya geri dönecek olan geleceğe nazik davranıyorsunuz.

EDIT: Ayrıca proje üzerinde zaman izlemeniz gerekir. Açıkçası sıkı son tarihler altında, ana işi bitirmeye odaklanmanız gerekiyor, ancak "normal yük" altındaysanız, o zaman burada biraz temizlik yapmayı düşünüyorum ve uzun vadede herkesi mutlu ediyor.

Her zaman olduğu gibi, duruma göre değişir.

• Önemsizse ve düzeltebileceğinizden eminseniz düzeltin.
• Çok sayıda birim testi varsa, hiçbir şeyi kırmadığınızdan emin olabilirsiniz, düzeltin.
• Aksi takdirde, // TODO ekleyin, hata izlemenize ekleyin, her neyse

Temel olarak bir risk değerlendirmesi yapıyorsunuz: değişme ya da değişmeme riski nedir? Yeterli deneyime sahip olduğunuzu hissetmiyorsanız (genel olarak programlama ile veya özellikle sistemle) ekipten başka birine danışın.

Pragmatik Programcı bunlara 'Kırık Pencereler' diyor.

Kırık pencereleri düzeltmezseniz, kod kalitesinde aşağı doğru bir spiral oluşturma eğilimi vardır. Ve ne kadar fazla olursa, bunları düzeltmek için daha büyük bir iş vardır ve bu nedenle bunların düzeltilmesi daha az olasıdır.

Onları şimdi veya daha sonra düzeltmek bir yargı konusudur. Basit bir düzeltme mi? Kodun düşündüğünüzü yaptığından emin misiniz? Mevcut görevinizden uzaklaşmanız muhtemel mi? Zaman kısıtlamaları altında mısınız? Daha fazla hata getirmesi muhtemel mi?

En azından, izleme sisteminizdeki öğeyi işaretleyin ve daha sonra düzeltildiğinden emin olun. Şimdi düzeltmeye karar verseniz bile, test edildiğinden emin olmak ve değişiklikleri belgelemek için izleme sisteminde işaretlemek önemlidir.

Güvenliği ihlal edecek, verileri bozacak veya kullanıcıya görüntülenecek bir istisna oluşturacak gibi açık bir hata ise, düzeltin. Aksi takdirde, kod tabanını bilen birine sizden daha iyi sorun.

O bağlıdır, onun küçük bir hata nerede senin düzeltme düşük etkisi vardır emin o zaman şahsen ben diğer işin bir parçası olarak düzeltmek ve sonra PM bildirin.

Müşteri, kullanıcılar veya şirket için herhangi bir risk taşıyorsa , Proje Yöneticisine getirin ve bir kursu tartışın. Riski değerlendirmek onların işi, bu yüzden dikkatini ve düzeltmek için davayı getirmek. Sonra kararlarını onurlandırın.

Testçilerimiz bundan nefret ediyor. Çok önemsiz olmadıkça, hata veritabanına kaydederiz, daha sonra bir sürüme ayırır ve regresyon testleri yazarız. Geliştiriciler sadece programda olmayan değişiklikler yapacaklarsa, son teslim tarihini nasıl koruyabilirsiniz?

Kritik olmayan kusurların veya standart ihlallerin "Zayıf Kod" kusuru olarak gönderildiği ekiplerde bulundum. Kritik bir kusur bulan kişinin bir tür bayrak atma sorumluluğu olduğunu söyleyebilirim

hataya bağlıdır. ana endişe yeni hatalar getirmektir. Bilinmeyen bir konuyu değil, bilinen bir konuyu ele almak daha iyidir. Basitse, bir metin değişikliği veya basit bir mantık hatası varsa, düzeltiriz, aksi takdirde yalnız bırakırız.

Unutulmaması gereken bir şey, tho, biz 4 devs küçük bir dükkan ve bir stajyer ve ben düzeltmek hata muhtemelen ben oluşturulan hata.

Kod açıkça yanlışsa, düzeltme oldukça basittir ve kullanıcıları etkileme riskinin düşük olduğuna inanıyorsanız, bunun için gidin. Mesleki muhakeme ile ilgilidir.

Yine de, eğer bulduysanız, muhtemelen kullanıcıların bunu yapmadığını ya da bildirdiklerini hatırlamanız gerekir. Bir kullanıcı tarafından hiç karşılaşılmayacak bir sorunu düzeltmek için zaman harcamak yerine, kullanıcılarınızın sorunlarına neden olan sorunları gidermek için o zamanı harcamanız daha iyi olabilir.

Önce gözlemleri belgeleyin ve daha sonra düzeltip düzeltmeyeceğinize karar verin.

Meslektaşlarınızla bazı resmi tartışmalar (örn. Düzenli toplantıda) veya gayri resmi tartışmalar (örn. Öğle yemeği sırasında) yapın ve düzelteceğiniz kodların davranışları konusunda daha fazla güven kazandıktan sonra değişiklikleri yapın.

Size bir hata / kusur gibi görünse de, aslında bu sefer bir "özellik" olabilir. Önceki sürümün son dakikasında bazı köşe vakalarının etrafından dolaşmak kötü uygulanmış bir çözüm olabilir ve "temiz düzeltmeniz" daha önce çözülmüş bazı sorunları canlandırabilir.

Buradaki eğilimi yakalayacağım. Geliştirme sürecinin ilk prototip aşamasında değilseniz, hemen derhal düzeltmemelisiniz, bir hata raporu göndermelisiniz. Bunun birkaç avantajı vardır:

• Takım bunu değerlendirir. Gerçek bir hata mıdır, düzeltmenin riskleri nelerdir.
• Yönetim, programın bu sürüme dahil edilmesinin zamanlama etkisini alacak kadar önemli olup olmadığına karar verir.
• bunu saptamak için bir yöntem, benzer hataları bulmak için yeterince genel bir şekilde, test paketine eklenebilir.
• önceki aşamalarda kaç hatanın kaydığı hakkında değerli metrikler sağlar