Belirli koşullarda programcının dikkatini nasıl çekebilirim?


13

Bir örnekle başlayalım.

Diyelim ki, exportağırlıklı olarak DB şemasına bağlı olarak adlandırılan bir yöntemim var . Ve “büyük ölçüde bağlıdır” derken, belirli bir tabloya sık sık (çok sık) yeni bir sütun eklemenin karşılık gelen exportyöntem değişikliğine yol açtığını biliyorum (genellikle yeni alanı dışa aktarma verilerine de eklemelisiniz).

Programcılar genellikle exportyöntemi değiştirmeyi unutur, çünkü buna bile bakmanız gerektiği açık değildir. Amacım programcı zorlamak açıkça o bakmak için unuttum olup olmadığını belirlemek için bir karar exportyöntemle ya da sadece ihracat verilerine bir alan eklemek istemiyorum. Ve ben bu problemin tasarım çözümünü arıyorum.

İki fikrim var, ama her ikisinin de kusurları var.

Akıllı "Tümünü oku" sarmalayıcısı

Tüm verilerin açıkça okunmasını sağlayan akıllı sarmalayıcı oluşturabilirim.

Bunun gibi bir şey:

def export():
    checker = AllReadChecker.new(table_row)

    name    = checker.get('name')
    surname = checker.get('surname')
              checker.ignore('age') # explicitly ignore the "age" field

    result = [name, surname] # or whatever

    checker.check_now() # check all is read

    return result

Bu nedenle, okunmayan başka bir alan içerip içermediğini checkervarsayar table_row. Ama bütün bunlar ağır görünüyor ve (belki) performansı etkilemektedir.

Bu yöntemi kontrol et ” unittest

Sadece son tablo şemasını hatırlayan ve tablo her değiştiğinde başarısız olan birim testi oluşturabilirim. Bu durumda programcı “ exportyöntemi kontrol etmeyi unutma” gibi bir şey görür . Uyarı programlayıcısını gizlemek (veya bu bir sorun değildir) kontrol etmek exportve manuel olarak (bu başka bir sorun) testi yeni alanlar ekleyerek düzeltir.

Birkaç fikrim daha var, ancak uygulanması çok zordur veya anlaşılması çok zordur (ve projenin bir bulmaca olmasını istemiyorum).


Yukarıdaki sorun, zaman zaman karşılaştığım daha geniş sorun sınıflarına bir örnektir. Bazı kod parçalarını ve / veya altyapıyı bağlamak istiyorum, bu yüzden bunlardan birini değiştirmek programcıyı diğerini kontrol etmesi için hemen uyarır. Genellikle ortak mantığı ayıklamak veya güvenilir bir birim testi yazmak gibi bazı basit araçlarınız vardır, ancak daha karmaşık durumlar için aracı arıyorum: belki de şimdi farkında olduğum bazı tasarım kalıpları.


exportŞemaya dayalı olarak oluşturabilir misiniz ?
coredump

Bu aoutmatik olarak oluşturulamaz, bu yüzden programcıdan koda bakıp bir karar vermesini istemeliyim .
Vadim Pushtaev

Dışa aktarma sınıfına iki alan adı listesi (dışa aktarma ve dışa aktarma) eklemek ve bu iki listenin birlikte veritabanındaki alanların tamamını kapsadığını kontrol eden bir birim sınaması yapmak bir çözüm olabilir mi?
Sjoerd Job Postmus

Gerçi exportgerçekçi bir şekilde ihtiyacınız olan her şeye sahip olup olmadığını kontrol eden bir test oluşturabilir misiniz?
biziclop

1
kaynak kodunda bir yorum çok basit bir çözüm? Genellikle bir şeyler hatırlanmaz, çünkü hatırlatma yoktur, bir yorum bunu düzeltir.
gbjbaanb

Yanıtlar:


11

Birim testi fikrinizle doğru yoldasınız, ancak uygulamanız yanlış.

Eğer exportşema ile ilgili ve şema değiştirilir, iki olası durumlar vardır:

  • Ya exporthala mükemmel çalışıyor, çünkü şemadaki küçük bir değişiklikten etkilenmedi,

  • Yoksa kırılır.

Her iki durumda da, bu olası gerilemeyi izlemek yapının amacıdır. Bir grup test - entegrasyon testleri, sistem testleri veya fonksiyonel testler veya başka bir şey - exportprosedürünüzün önceki işlemden bu yana değişip değişmediğinden bağımsız olarak mevcut şema ile çalışmasını sağlar . Bu testler başarılı olursa harika. Başarısızlarsa, geliştiriciye bir şeyi kaçırmış olabileceğinin ve nereye bakması gerektiğinin açık bir göstergesidir.

Uygulamanız neden yanlış? Pek çok nedenden dolayı.

  1. Birim testleri ile ilgisi yok ...

  2. ... ve aslında, bu bir test bile değil.

  3. En kötü yanı, “test” in sabitlenmesinin, aslında “test” in değiştirilmesini gerektirmesi ve bunun tamamen ilgisiz bir işlem yapmasıdır export.

Bunun yerine, exportyordam için gerçek sınamalar yaparak , geliştiricinin export.


Daha genel olarak, bir sınıftaki bir değişikliğin her zaman veya genellikle tamamen farklı bir sınıfta bir değişiklik gerektirdiği bir durumla karşılaştığınızda, bu tasarımınızı yanlış yaptığınızın ve Tek Sorumluluk İlkesini ihlal ettiğinin iyi bir işaretidir.

Özellikle sınıflar hakkında konuşurken, aşağı yukarı diğer varlıklar için de geçerlidir. Örneğin, veritabanı şemasındaki bir değişiklik, kodunuza otomatik olarak, örneğin birçok ORM tarafından kullanılan kod oluşturucular aracılığıyla yansıtılmalı veya en azından kolayca yerelleştirilmelidir: tabloya Descriptionsütun ekler Productve ORM veya kod oluşturucu kullanmazsam, En azından tüm kod tabanı üzerinden arama ve sınıf, örneğin sunum katmanı bazı oluşumları bulmak gerek kalmadan, DAL sınıfı içinde tek bir değişiklik yapmak için bekliyoruz .Data.ProductProduct

Değişikliği makul bir şekilde bir konuma kısıtlayamıyorsanız (ya basitçe işe yaramadığı bir durumda olmanız ya da çok fazla gelişme gerektirmesi nedeniyle), gerileme riski yaratırsınız . Sınıfı değiştirdiğimde Ave Bkod tabanındaki bir yerde çalışmayı bıraktığımda , bir gerileme.

Test, gerileme riskini azaltır ve daha da önemlisi, gerilemenin yerini gösterir. Bu nedenle , bir konumdaki değişikliklerin kod tabanının tamamen farklı bir bölümünde sorunlara neden olduğunu bildiğinizde , bu düzeyde bir gerileme göründüğünde alarmları yükselten yeterli testleriniz olduğundan emin olun.

Her durumda, bu gibi durumlarda sadece yorumlara güvenmekten kaçının. Gibi bir şey:

// If you change the following line, make sure you also change the corresponding
// `measure` value in `Scaffolding.Builder`.

asla çalışmaz. Çoğu durumda sadece geliştiriciler okumaz, aynı zamanda ilgili hattan kaldırılır veya uzaklaştırılır ve anlaşılması imkansız hale gelir.


Evet, bu “test” gerçekten bir test değil, bir çeşit tuzak, bir çeşit If you change the following line...otomatik olarak çalışıyor ve basit göz ardı edilemez. Hiç kimsenin böyle tuzaklar kullandığını hiç görmedim, bu yüzden şüphe.
Vadim Pushtaev

1
Sorun sınıftır Bvermez durdurmak o çalışma belki yanlış çalışmaya başlar. Ama geleceği tahmin edemiyorum ve geleceği öngören testler yazamıyorum, bu yüzden geliştiriciye yeni testi yazmasını hatırlatmaya çalışıyorum.
Vadim Pushtaev

@VadimPushtaev: test söz konusu olduğunda, “belki yanlış çalışmaya başlar” ve “çalışmayı durdurur” tamamen aynı şeydir. Geleceği tahmin edemezsiniz, ancak gereksinimleri tam olarak bilmeli ve bu gereksinimlerin gerçek ürününüz tarafından karşılandığını test edebilmelisiniz.
Arseni Mourzenko

Evet, bu bir şey. Aslında geliştiriciye yeni gereksinimler hakkında düşünmesini hatırlatmak istiyorum . Sadece bir el sallamak istiyorum: “Merhaba, ihracatı unutmadığınızdan emin misiniz? Yöneticiye veya başka bir şeye sorun, bu yaygın bir sorundur ”.
Vadim Pushtaev

Yine de teşekkür ederim, cevabınız düşüncelerimi düzenlememe yardımcı oldu ve şimdi belirli bir planım var.
Vadim Pushtaev

3

Değişikliklerin az olduğu gibi geliyor bana. Posta kodları olmayan bir yerde yaşadığınızı, bu nedenle adres tablosunda bir posta kodu sütununuz olmadığını varsayalım. Sonra posta kodları tanıtılır veya posta kodlarının bulunduğu yerde yaşayan müşterilerle uğraşmaya başlarsınız ve bu sütunu tabloya eklemeniz gerekir.

İş öğesi yalnızca "adres tablosuna posta kodu sütunu ekle" diyorsa, evet, dışa aktarma bozulur veya en azından posta kodlarını dışa aktarmaz. Peki, posta kodlarını girmek için kullanılan giriş ekranına ne dersiniz? Tüm müşterileri ve adreslerini listeleyen rapor? Bu sütunu eklediğinizde değişmesi gereken tonlarca şey var. Bu şeyleri hatırlama işi önemli bir şeydir - geliştiricileri hatırlamaya "tuzaklamak" için rastgele kod eserlerine güvenmemelisiniz.

Anlamlı bir sütun ekleme kararı verildiğinde (yani, yalnızca önbelleğe alınmış toplam veya denormalize edilmiş bir arama veya bir dışa aktarma veya raporda veya giriş ekranına ait olmayan başka bir değer değil) oluşturulan çalışma öğeleri TÜM değişiklikleri içermelidir gerekli - sütun ekleme, doldurma komut dosyasının güncellenmesi, testlerin güncellenmesi, dışa aktarmanın, raporların, giriş ekranlarının vb. güncellenmesi. Bunların hepsi aynı kişiye atanmamış (veya bu kişi tarafından alınmış) olmayabilir, ancak hepsinin yapılması gerekir.

Bazen geliştiriciler bazı büyük değişiklikleri uygulamanın bir parçası olarak sütun eklemeyi tercih ederler. Örneğin, birisi nasıl uygulandığını düşünmeden giriş ekranına ve rapora bir şeyler eklemek için bir iş öğesi yazmış olabilir. Bu çok olursa, iş öğesi ekleyicinizin uygulama ayrıntılarını bilmesi gerekip gerekmediğine (tüm doğru iş öğelerini ekleyebilmek için) veya geliştiricilerin iş öğesinin toplayıcı bazen işleri dışarıda bırakır. Eğer ikinciyse, "sadece şemayı değiştirmeyin; durun ve başka neyin etkilediğini düşünün" kültürüne ihtiyacınız var.

Çok sayıda geliştirici olsaydı ve bu bir kereden fazla olsaydı, takım lideri veya başka bir kıdemli kişinin şema değişiklikleri konusunda uyarılması için bir check-in uyarısı ayarlardım. Bu kişi daha sonra şema değişikliğinin sonuçlarıyla başa çıkmak için ilgili iş öğelerini arayabilir ve iş öğeleri eksikse, onları ekleyemez, aynı zamanda onları planın dışında bırakanları eğitebilir.


2

Neredeyse her zaman, bir ihracat oluştururken de karşılık gelen bir ithalat oluştururum. Dışa aktarılan veri yapısını tam olarak dolduran diğer testlerim olduğu için, daha sonra tamamen doldurulmuş bir orijinali dışa aktarılan ve içe aktarılan bir kopyayla karşılaştıran bir gidiş-dönüş birim testi oluşturabilirim. Bunlar aynıysa, dışa aktarma / içe aktarma işlemi tamamlanır; aynı değilse, birim testi başarısız olur ve ihracat mekanizmasının güncellenmesi gerektiğini biliyorum.


bu, her nesnenin db'den kaydedilip yeniden yüklendiğini kontrol edebilir. Varolan bir db-alanının karşılık gelen nesne alanı olmadığı durumu kapsamaz.
k3b

@ k3b doğru. En azından sistemlerimde, bu genellikle bir şey artık kullanılmıyor, ancak dışa aktarma mekanizmasının kapsamı dışında olan şemadan kaldırılmadıysa oluşur - birim, bir nesnenin her alanının olup olmadığını kontrol etmek için nesne kalıcılığını kontrol eder Kaldı, ancak sistem işlevi üzerinde gözlemlenebilir bir etkisi olmayacak şekilde kullanılmayan sütunları test etmiyorum.
Pete Kirkham
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.