Kıdemsiz programcıların test yazmasını nasıl sağlayabilirim? [kapalı]

Yeterince test yazmayan genç bir programcımız var.
Her iki saatte bir, "testler yazdın mı?"
Denedik:

• Tasarımın daha basit hale geldiğini göstermek
• Kusurları önlediğini göstermek
• Bunu sadece kötü programcıların yapmadığını söyleyen ego bir şey yapmak
• Bu hafta sonu 2 takım üyesi işe gelmek zorunda kaldı çünkü kodunda NULL referansı vardı ve o bunu test etmedi

Çalışmam en yüksek kalitede kararlı kod gerektiriyor ve genellikle herkes bunu 'anlıyor' ve testleri zorlamaya gerek yok. Ona testler yazdırabileceğimizi biliyoruz, ancak hepimiz yararlı testlerin, içine girdiğinizde yazılanlar olduğunu biliyoruz.

Daha fazla motivasyon biliyor musun?

Bu, yapılması en zor şeylerden biridir . İnsanlarının onu almasını sağlamak .

Bazen, kıdemsiz seviyedeki programcıların 'bunu anlamasına' ve yaşlılardan doğru teknikleri öğrenmesine yardımcı olmanın en iyi yollarından biri, biraz çift programlama yapmaktır.

Şunu deneyin: yaklaşan bir projede, genç adamı kendinizle veya başka bir kıdemli programcıyla eşleştirin. Birlikte çalışmalı, sırayla "araba kullanma" (klavyede yazan kişi olmak) ve "koçluk" (sürücünün omzunun üzerinden bakarak ve giderken önerileri, hataları, vb. İşaret ederek). Kaynak israfı gibi görünebilir, ancak bulacaksınız:

1. Bu adamlar birlikte çok hızlı ve daha kaliteli kod üretebilirler.
2. Eğer küçük adamınız kıdemli bir adamla onu doğru yola yönlendirerek "başaracak" kadar öğrenirse (ör. "Tamam, şimdi devam etmeden önce, bu işlev için test yazalım.") Sizin kaynaklarınıza değecek taahhüt et.

Belki de grubunuzdan birinin Kate Rhodes tarafından Unit Testing 101 sunumunu vermesini sağlayın , bence bu, eğer iyi yapılırsa insanları test etme konusunda heyecanlandırmanın harika bir yolu.

Yapabileceğiniz başka bir şey de Jr. Devs'in, Test Driven Development'ı öğrenmelerine yardımcı olacak Bowling Game Kata'yı uygulamalarını sağlamaktır . Java dilindedir, ancak herhangi bir dile kolayca uyarlanabilir.

Her kaydetmeden önce bir kod incelemesi yapın ("Bu değişken adını değiştirdim" 1 dakika olsa bile) ve kod incelemesinin bir parçası olarak, herhangi bir birim testini gözden geçirin.

Testler yerine getirilene kadar taahhüdü imzalamayın.

(Ayrıca - Çalışması test edilmediyse - neden ilk etapta bir üretim yapısındaydı? Test edilmediyse, içeri girmesine izin vermeyin, o zaman hafta sonları çalışmak zorunda kalmazsınız)

Kendim için bulduğum ve düzelttiğim her hatanın bir test olarak ifade edilmesi konusunda ısrar etmeye başladım:

1. "Hmmm, bu doğru değil ..."
2. Olası sorunu bulun
3. Bir test yazın, kodun başarısız olduğunu gösterin
4. Sorunu çöz
5. Yeni kodun geçtiğini gösterin
6. Orijinal sorun devam ederse döngü yapın

Bir şeyleri patlatırken bile bunu yapmaya çalışıyorum ve yaklaşık aynı zamanda, sadece zaten mevcut olan kısmi bir test paketi ile bitiriyorum.

(Ticari bir programlama ortamında yaşamıyorum ve genellikle belirli bir projede çalışan tek kodlayıcı benim.)

Marco adında sahte bir programcı olduğumu hayal edin. Uzun zaman önce okuldan mezun olduğumu ve hiçbir zaman gerçekten testler yazmak zorunda olmadığımı hayal edin. Bunu gerçekten uygulamayan veya bunu istemeyen bir şirkette çalıştığımı hayal edin. TAMAM? iyi! Şimdi, şirketin testleri kullanmaya başladığını ve beni bununla aynı hizaya getirmeye çalıştıklarını hayal edin. Sanki bu konuda araştırma yapmamışım gibi şimdiye kadar bahsedilen maddelere biraz keskin tepkiler vereceğim.

Bunu yaratıcıyla başlayalım:

Tasarımın daha basit hale geldiğini göstermek.

Nasıl daha fazla yazmak, işleri daha basit hale getirir. Şimdi daha fazla vaka alma vb. Konularını takip etmem gerekecekti. Bana sorarsan bu durum daha karmaşık hale geliyor. Bana sağlam detaylar ver.

Gösterilmesi kusurları önler.

Bunu biliyorum. Bu yüzden testler denir. Kodum iyi ve sorun olup olmadığını kontrol ettim, bu yüzden bu testlerin nerede yardımcı olacağını göremiyorum.

Bunu sadece kötü programcıların yapmadığını söyleyen ego bir şey yapmak.

Ohh, yani ben kötü bir programcı olduğumu düşünüyorsun çünkü çok fazla kullanılmış test yapmıyorum. Size hakaret ve kesinlikle kızgınım. Sözler yerine yardım ve destek almayı tercih ederim.

@ Justin Standard : Yeni projeye başlarken, genç adamı kendinizle veya başka bir kıdemli programcıyla eşleştirin.

Ohh, bu o kadar önemli ki, işlerin nasıl yapıldığını görmek için kaynaklar harcanacak ve işlerin nasıl yapıldığına dair bana yardım edecek. Bu yardımcı oldu ve daha fazlasını yapmaya başlayabilirim.

@ Justin Standard : Kate Rhodes tarafından hazırlanan Unit Testing 101 sunumunu okuyun .

Ahh, bu ilginç bir sunumdu ve beni test etmeyi düşündürdü. Üzerinde düşünmem gereken bazı noktaları vurguladı ve görüşlerimi biraz etkilemiş olabilir.

İşleri yapmanın doğru yolu olduğunu düşünmeme yardımcı olacak daha ilgi çekici makaleler ve diğer araçlar görmeyi çok isterim.

@ Dominic Cooney : Biraz zaman ayırın ve test tekniklerini paylaşın.

Ahh, bu, teknikler konusunda benden ne beklendiğini anlamama yardımcı oluyor ve bilgi çantama tekrar kullanabileceğim daha fazla şey koyuyor.

@ Dominic Cooney : Soruları, örnekleri ve kitapları yanıtlayın.

Soruya cevap verecek bir kişinin (kişilerin) olması yararlıdır, bu beni denemeye daha yatkın kılabilir. İyi örnekler harikadır ve bana amaçlanacak ve referans arayacak bir şey verir. Bu konuyla doğrudan ilgili olan kitaplar harika bir referanstır.

@ Adam Hayle : Sürpriz İnceleme.

Ne dersin, benim için tamamen hazırlıksız olduğum bir şey ortaya çıkardın. Bundan rahatsız oluyorum ama elimden geleni yapacağım. Şimdi korkacağım ve bunun tekrar ortaya çıkmasından biraz endişeleneceğim, teşekkür ederim. Ancak, korkutma taktiği işe yaramış olabilir, ancak bir bedeli var. Bununla birlikte, başka hiçbir şey işe yaramazsa, bu sadece gerekli olan itme olabilir.

@ Rytmis : Öğeler yalnızca test senaryoları olduğunda tamamlanmış sayılır.

Ohh, ilginç. Görüyorum ki bunu gerçekten şimdi yapmam gerekiyor, yoksa hiçbir şey tamamlamam. Bu mantıklı.

@ jmorris : Kurtul / Fedakârlık.

bakışlar, bakışlar, bakışlar - Öğrenme şansım var ve destek ve yardımla takımların çok önemli ve işlevsel bir parçası olabilirim. Bu şu anki dezavantajlarımdan biri, ama çok uzun sürmeyecek. Ancak, anlamazsam gideceğimi anlıyorum. Sanırım alacağım.

Sonuçta, ekibimin desteği tüm bunlarda büyük rol oynuyor. Bir kişinin yardım etmesi için zaman ayırması ve beni iyi alışkanlıklar edinmeye başlaması her zaman memnuniyetle karşılanır. Sonrasında iyi bir destek ağına sahip olmak harika olurdu. Birinin daha sonra birkaç kez gelmesi ve her şeyin nasıl aktığını görmek için bir kod üzerinden geçmesi, kendi başına bir incelemede değil, daha çok dostça bir ziyaret olarak her zaman takdir edilecektir.

Akıl Yürütme, Hazırlama, Öğretme, İzleme, Destekleme.

Pek çok programcının test etmenin değerini mantıklı bir düzeyde gördüğünü fark ettim. "Evet, bunu test etmem gerektiğini biliyorum ama bunu gerçekten hızlı bir şekilde halletmem gerekiyor" gibi şeyler duyduysanız, ne demek istediğimi anlarsınız. Bununla birlikte, duygusal düzeyde, yalnızca gerçek kodu yazarken bir şeyler yaptıklarını hissederler.

Öyleyse amaç, bir şekilde, testin aslında bir şey "yapıldığında" ölçmenin tek yolu olduğunu anlamalarını sağlamak ve böylece onlara test yazmak için içsel motivasyon sağlamak olmalıdır.

Korkarım bu olması gerekenden çok daha zor. "Gerçekten acelem var, bunu daha sonra yeniden yazacağım / yeniden yazacağım ve sonra testleri ekleyeceğim" gibi pek çok mazeret duyacaksınız - ve tabii ki, takip asla gerçekleşmiyor çünkü şaşırtıcı bir şekilde 're önümüzdeki hafta meşgul olarak sadece .

İşte yapacağım şey:

• İlk seferde ... "bu projeyi birlikte yapacağız. Ben testleri yazacağım ve siz kodu yazacaksınız. Testleri nasıl yazdığıma dikkat edin, çünkü biz böyle yapıyoruz buralarda ve senden bekleyeceğim şey bu. "

• Bunu takiben ... "Bitirdiniz mi? Harika! Öncelikle, geliştirmenize yön veren testlere bakalım. Oh, test yok mu? Bunun ne zaman yapıldığını bana bildirin, kodunuza bakmayı yeniden planlayalım. Eğer siz ' Testleri formüle etmek için yardıma ihtiyacım var, bana bildirin, ben de size yardımcı olacağım. "

Bunu zaten yapıyor. Gerçekten mi. Sadece yazmıyor. İkna olmadınız mı? Standart geliştirme döngüsünden geçmesini izleyin:

• Bir kod parçası yazın
• Derleyin
• Ne yaptığını görmek için koş
• Sonraki kod parçasını yazın

3. Adım testtir. Zaten test yapıyor, sadece elle yapıyor. Ona şu soruyu sorun: "Yarın bugünkü kodun hala çalıştığını nereden bileceksiniz?" Cevap verecek: "Bu çok az miktarda kod!"

Sor: "Gelecek haftaya ne dersin?"

Cevap alamayınca şunu sorun: "Bir değişiklik dün işe yarayan bir şeyi bozduğunda programınızın size nasıl söylemesini istersiniz?"

Otomatik birim testinin amacı budur.

Kıdemsiz bir programcı olarak, hala test yazma alışkanlığı kazanmaya çalışıyorum. Açıkçası, yeni alışkanlıklar edinmek kolay değil, ancak bunun benim için işe yarayacağını düşündüğümde, kod incelemeleri ve koçluk / eşli programlama hakkındaki yorumları + 1'lemem gerekiyor.

Test etmenin uzun vadeli amacını vurgulamak da faydalı olabilir: dün işe yarayan şeyin bugün, gelecek hafta ve gelecek ay hala çalıştığından emin olmak. Bunu söylüyorum çünkü cevapları gözden geçirirken bahsettiğimi görmedim.

Kod incelemeleri yaparken (bunu yapmaya karar verirseniz), genç geliştiricinizin bunun onu aşağılamakla ilgili olmadığını , kodu daha iyi hale getirmekle ilgili olduğunu bildiğinden emin olun . Çünkü bu şekilde özgüveninin zarar görme olasılığı azalır. Ve bu önemli. Öte yandan, ne kadar az şey bildiğini bilmek de öyle.

Tabii ki gerçekten hiçbir şey bilmiyorum. Ama umarım sözler yararlı olmuştur.

Düzenleme: [ Justin Standard ]

Kendinizi küçümsemeyin, söylemeniz gereken hemen hemen doğrudur.

Kod incelemeleri hakkındaki düşüncenize göre: bulacağınız şey, sadece genç geliştiricinin bu süreçte öğreneceği değil, aynı zamanda gözden geçirenlerin de öğreneceği. Kod incelemesindeki herkes, bunu ortak çalışmaya dayalı bir süreç haline getirip getirmediğinizi öğrenir.

Açıkçası, sen koymak yaşıyorsanız o ona bir şey kadar çok çaba sarf etmeniz gerekiyorsa, o zaman onun takıma uygun olmayabileceği ve gitmesi gerekebileceği düşüncesini kabul etmeniz gerekebilir. Şimdi, bu onu kovmak anlamına gelmiyor ... şirkette yeteneklerinin daha uygun olduğu başka bir yer bulmak anlamına gelebilir. Ama başka yer yoksa ... ne yapacağını biliyorsun.

Onun aynı zamanda oldukça yeni bir işe alındığını (<1 yaş) ve muhtemelen son zamanlarda okul dışında olduğunu varsayıyorum ... bu durumda kurumsal bir ortamda işlerin nasıl yürüdüğüne alışkın olmayabilir. Çoğumuzun kolejde sıyrılabileceği gibi şeyler.

Durum buysa, işe yarayan bir şey bulduğum bir şey, bir tür "sürpriz yeni işe alma incelemesi" yapmaktır. Daha önce hiç yapmamış olman önemli değil ... bunu bilmeyecek. Onu oturtun ve ona performansının üzerinden geçeceğinizi ve ona gerçek sayılar göstereceğinizi söyleyin ... normal inceleme kağıdınızı alın (resmi bir inceleme süreciniz var değil mi?) Ve isterseniz başlığı değiştirin. görevli ve ona nerede durduğunu göster. Ona çok resmi bir ortamda test yapmamasının performans derecelendirmesini olumsuz etkilediğini gösterirseniz, onu sadece "dırdırmak" yerine, umarım anlar. Ona davranışlarının, akıllıca ya da başka bir şekilde ödeme yapmanın onu gerçekten etkileyeceğini göstermelisiniz.

Biliyorum, resmi olmadığı için bunu yapmaktan uzak durmak isteyebilirsiniz ... ama bence bunu yapmak için bir nedeniniz var ve muhtemelen onu kovmaktan ve yeni birini işe almaktan çok daha ucuz olacak.

Ben de genç bir programcı olarak, kendimi küçük geliştiricinize benzer bir durumda bulduğumda nasıl bir şey olduğunu açıkladığımı düşündüm.

Üniversiteden ilk çıktığımda, gerçek dünyayla başa çıkmak için beni ciddi şekilde donatmadığını fark ettim. Evet, JAVA'nın bazı temellerini ve bazı felsefelerini biliyordum (sorma) ama bununla ilgiliydi. İşimi ilk aldığımda en azını söylemek biraz ürkütücüydü. Size muhtemelen etraftaki en büyük kovboylardan biri olduğumu söyleyeyim, yorum / test / dokümantasyon olmadan küçük bir hata düzeltmesi / algoritma kırıp kapıdan gönderirim.

Nazik ve çok sabırlı bir kıdemli programcının gözetiminde olacak kadar şanslıydım . Neyse ki benim için, benimle oturmaya karar verdi ve çok hacklenmiş birleşik kodumun üzerinden 1-2 hafta geçirmeye karar verdi. Nerede yanlış yaptığımı, c ve işaretçilerin daha ince noktalarını açıklardı (çocuk bunu kafamı karıştırdı!). Yaklaşık bir hafta içinde oldukça iyi bir sınıf / modül yazmayı başardık. Söyleyebileceğim tek şey, kıdemli geliştirici bana doğru yolda yardım etmek için zaman ayırmasaydı, muhtemelen çok uzun süre dayanamazdım.

Ne mutlu ki, 2 yıl sonra, bazı meslektaşlarımın beni ortalama bir programcı olarak bile düşünmelerini umuyorum.

Ev puanları alın

1. Çoğu üniversite, öğrencileri gerçek dünyaya hazırlama konusunda çok kötü
2. Eşli programlama bana gerçekten yardımcı oldu. Herkese yardım edeceğini söylemiyorum ama benim için çalıştı.

Endişeniz buysa, bunları "en kaliteli kararlı kod" gerektirmeyen projelere atayın ve jr. geliştirici başarısız. Hatalarını düzeltmek için 'hafta sonu gelecek' onlar olsun. Sık sık öğle yemeği yiyin ve yazılım geliştirme uygulamaları hakkında konuşun (dersler değil, tartışmalar). Zamanla kendilerine verilen görevleri yerine getirmek için en iyi uygulamaları edinecek ve geliştireceklerdir.

Kim bilir, ekibinizin şu anda kullandığı tekniklerden daha iyi bir şey bile bulabilirler.

Kıdemsiz programcı veya herhangi biri testin değerini görmezse, bunu yapmalarını sağlamak zor olacaktır ... nokta.

Küçük programcıya, hatayı düzeltmek için hafta sonunu feda etmesini sağlardım. Eylemleri (veya yokluğu) onu doğrudan etkilemiyor. Ayrıca, test becerilerini geliştirmezse ilerleme ve / veya maaş artışı görmeyeceğini açıkça belirtin.

Sonunda, tüm yardımınıza, cesaretlendirmenize, akıl hocalığınıza rağmen, ekibinize uygun olmayabilir, bu yüzden bırakın gitsin ve onu alan birini arayın.

RodeoClown'un her kaydı gözden geçiren kod hakkındaki yorumunu beğeniyorum. Bunu birkaç kez yaptıktan sonra bir şeyleri test etme alışkanlığı kazanacaktır.

Yine de bu tür işlemlerin engellenmesine gerek var mı bilmiyorum İşyerimde herkesin her şeye ücretsiz olarak bağlılığı vardır ve tüm SVN commit mesajları (farklılıklar içeren) takıma e-posta ile gönderilir.

Not: Bunu yapmayı planlıyorsanız , gök gürültüsü renkli farklar eklentisini gerçekten istiyorsunuz .

Patronum veya ben (2 'kıdemli' kodlayıcı) taahhütleri okumaya başlayacak ve "birim testleri eklemeyi unuttunuz" gibi herhangi bir şey varsa, sadece bir e-postayı fiske atıyoruz veya gidip bu kişiyle sohbet edip nedenini açıklıyoruz. gerekli birim testleri veya her neyse. Neler olup bittiğini görmenin harika bir yolu olduğu için diğer herkes de işleri okumaya teşvik ediliyor, ancak genç geliştiriciler çok fazla yorum yapmıyor.

Düzenli aralıklarla "Hey, bob, bu sabah yaptığımı gördün mü, falan ne olursa olsun yapabileceğin bu harika numarayı buldum, taahhüdü oku ve gör" gibi şeyler söyleyerek insanları bunu alışkanlık haline getirmeye teşvik edebilirsin. nasıl çalışır!"

Not: 2 'kıdemli' geliştiricimiz ve 3 genç geliştiricimiz var. Bu ölçeklenmeyebilir veya süreci daha fazla geliştiriciyle biraz ayarlamanız gerekebilir.

1. Kod kapsamını incelemelerin bir parçası haline getirin.
2. Bir hatayı düzeltmek için "hatayı ortaya çıkaran bir test yazın" ön koşulu yapın.
3. Kodun kontrol edilebilmesi için belirli bir kapsam seviyesi gerektir.
4. Test odaklı geliştirmeyle ilgili iyi bir kitap bulun ve bunu önce testin geliştirmeyi nasıl hızlandırabileceğini göstermek için kullanın.

Pek çok psikoloji ve yardımcı "akıl hocalığı" tekniği, ama dürüst olmak gerekirse, bu sadece "yarın hala bir işin olmasını istiyorsan testler yazmak" anlamına geliyor.

Uygun, sert veya yumuşak olduğunu düşündüğünüz terimleri ifade edebilirsiniz, önemli değil. Ama gerçek şu ki, programcılara sadece kodu bir araya getirmeleri ve kontrol etmeleri için ödeme yapılmıyor - kendilerine kodu dikkatlice bir araya getirmeleri, sonra testleri bir araya getirmeleri, sonra kodlarını test etmeleri, SONRA ise her şeyi kontrol etmeleri için ödeme yapılıyor. (En azından açıklamanıza göre kulağa böyle geliyor.)

Bu nedenle, birisi işini yapmayı reddedecekse, onlara yarın evde kalabileceğini açıklayın ve bu işi YAPACAK birini işe alacaksınız.

Yine, bunun gerekli olduğunu düşünüyorsanız, tüm bunları nazikçe yapabilirsiniz, ancak birçok insan Gerçek Dünyada Yaşam'ın büyük bir sert tokatına ihtiyaç duyar ve siz de onlara vererek onlara bir iyilik yapmış olursunuz.

İyi şanslar.

İş tanımını bir süreliğine yalnızca testler yazmak ve testleri sürdürmek için değiştirin. Birçok şirketin bunu yeni ve deneyimsiz insanlar için başladıklarında bir süre için yaptığını duydum.

Ek olarak, o görevdeyken bir meydan okuma yapın: a) mevcut kodda başarısız olacak a) yazılımın gereksinimlerini karşılayacak testler yazın. Umarım bu, bazı sağlam ve kapsamlı testler oluşturmasına (projeyi iyileştirmesine) ve çekirdek geliştirmeye yeniden entegre olduğu zamanlar için test yazmada daha iyi olmasına neden olur.

düzenleme> yazılımın gereksinimlerini yerine getirme, yani kod asla bu test senaryosunu hesaba katmayı amaçlamadığında veya buna ihtiyaç duymadığında kodu kasıtlı olarak kırmak için testler yazmıyor demektir.

Meslektaşınız yazma testlerinde deneyimden yoksunsa, basit durumların ötesinde test yapmakta güçlük çekiyor olabilir ve bu da yetersiz test olarak kendini gösteriyor. İşte deneyeceğim şey:

• Biraz zaman harcayın ve bağımlılık ekleme, uç durumları arama gibi test tekniklerini meslektaşınızla paylaşın.
• Testle ilgili soruları yanıtlamayı teklif edin.
• Bir süre testlerin kod incelemelerini yapın. İş arkadaşınızdan, iyi bir test örneği niteliğindeki değişikliklerinizi gözden geçirmesini isteyin. Test kodunuzu gerçekten okuyup anlamadıklarını görmek için yorumlarına bakın.
• Ekibinizin test felsefesine özellikle uyan kitaplar varsa, ona bir kopyasını verin. Kod gözden geçirme geri bildirimleriniz veya tartışmalarınız kitaba referans veriyorsa, alması ve takip etmesi gereken bir ileti dizisi olması yardımcı olabilir.

Utanç / suçluluk faktörünü özellikle vurgulamam. Test etmenin yaygın olarak benimsenen, iyi bir uygulama olduğuna ve iyi testler yazmanın ve sürdürmenin profesyonel bir nezaket olduğuna dikkat çekmek önemlidir, bu nedenle ekip arkadaşlarınızın hafta sonlarını işte geçirmeleri gerekmez, ancak bu noktaları vurgulamam.

Gerçekten "sertleşmeniz" gerekiyorsa tarafsız bir sistem kurun; kimse seçilmemiş gibi hissetmekten hoşlanmaz. Örneğin, ekibiniz belirli bir düzeyde test kapsamını korumak için koda ihtiyaç duyabilir (oyun oynanabilir, ancak en azından otomatikleştirilebilir); testlere sahip olmak için yeni kod gerektirir; gözden geçirenlerin kod gözden geçirmeleri yaparken testlerin kalitesini göz önünde bulundurmalarını talep etmek; ve bunun gibi. Bu sistemi kurmak ekip fikir birliğinden gelmelidir. Tartışmayı dikkatlice yönetirseniz, meslektaşınızın testinin beklediğiniz gibi olmadığının altında yatan diğer nedenleri ortaya çıkarabilirsiniz.

Ona Öğretmek onun Mentorunun sorumluluğundadır. Ona NASIL test edeceğini ne kadar iyi öğretiyorsunuz? Onunla eşli programlama mı yapıyorsunuz? Junior büyük ihtimalle xyz için NASIL iyi bir test ayarlayacağını bilmiyor.

Genç bir okuldan yeni çıkmış biri olarak birçok Kavram biliyor. Bazı teknikler. Biraz deneyim. Ama sonuçta, tüm Ufaklıklar POTANSİYELdir. Üzerinde çalıştıkları hemen hemen her özellik, daha önce hiç yapmadıkları yeni bir şey olacaktır. Elbette Ufaklık, sınıftaki bir proje için "kapıları" açıp kapatarak basit bir Durum modeli yapmış olabilir, ancak modellerin gerçek dünyada uygulanmasını asla.

Ne kadar iyi öğrettiğiniz kadar iyi olacaktır. "Sadece al" yapabilselerdi, sizce ilk başta Junior pozisyonu alırlar mıydı?

Tecrübelerime göre, Gençler işe alınır ve Büyükler ile neredeyse aynı sorumluluk verilir, ancak sadece daha az ücret alırlar ve düşmeye başladıklarında görmezden gelinirler. Kızgın görünüyorsam affet, çünkü öyleyim.

@sebnemziyagil

Bir keresinde kıdemli geliştiriciye ve "mimar" a beni ve bir testçiyi (üniversiteden sonraki ilk işimdi) geç kalmadığım ve önceki gece böyle "kolay" bir görevi bitirdiğim için e-postayla azarlattım. Bütün gün çalışıyorduk ve akşam 7'de bıraktık, o gün öğle yemeğinden önce 11: 00'den beri mücadele ediyordum ve ekibimizin her üyesini en az iki kez yardım için rahatsız ettim.

Ekibe cevap verdim ve cc'ledim: "Seni bir aydır hayal kırıklığına uğrattım. Takımdan asla yardım almadım. Bana ihtiyacın olursa sokağın karşısındaki kafede olacağım. Ben üzgünüm, hemen hemen her şeyin bağlı olduğu 12 parametreli 800 satırlı yöntemde hata ayıklayamadım. "

Kahvehanede bir saat soğuduktan sonra ofise geri döndüm, eşyalarımı aldım ve ayrıldım. Birkaç gün sonra beni aradılar mı gelip gelmeyeceğimi sordular, isterim dedim ama belki yarın görüşmem vardı.

"Öyleyse bırakıyorsun?"

Kaynak deponuzda: her kaydetmeden önce kancaları kullanın (örneğin SVN için önceden kesinleştirme kancası)

Bu kancada, her yöntem için en az bir kullanım senaryosu olup olmadığını kontrol edin. Önceden taahhüt kancası aracılığıyla kolayca uygulayabileceğiniz birim test organizasyonu için bir kural kullanın.

Bir bütünleştirme sunucusunda her şeyi derleyin ve bir test kapsamı aracı kullanarak test kapsamını düzenli olarak kontrol edin. Bir kod için test kapsamı% 100 değilse, geliştiricinin herhangi bir taahhüdünü engelleyin. Size kodun% 100'ünü kapsayan test durumunu göndermelidir.

Bir projede yalnızca otomatik kontroller iyi ölçeklenebilir. Her şeyi elle kontrol edemezsiniz.

Geliştiricinin, test senaryolarının kodun% 100'ünü kapsayıp kapsamadığını kontrol edecek bir aracı olmalıdır. Bu şekilde, eğer% 100 test edilmiş bir kodu işlemezse, bu kendi hatasıdır, "ayy, unuttum özür dilerim" hatası değil.

Unutmayın: İnsanlar asla beklediğiniz şeyi yapmazlar, her zaman sizin denetlediğiniz şeyi yaparlar.

Öncelikle, yanıtlayanların çoğunun belirttiği gibi, adam testin değerini görmezse, bu konuda yapabileceğiniz pek bir şey yok ve zaten adamı kovamayacağınızı söylediniz. Ne birkaç şey hakkında o kadar Ancak, başarısızlık bir seçenek burada değil edebilir mi?

Kuruluşunuz 6'dan fazla geliştiriciye sahip olacak kadar büyükse, bir Kalite Güvence departmanına sahip olmanızı şiddetle tavsiye ederim (başlayacak tek kişi olsa bile). İdeal olarak, 1 test kullanıcısı ile 3-5 geliştirici arasında bir oranınız olmalıdır. Programcılar ile ilgili olan şey ... onlar programcıdır, testçi değil. Henüz resmi olarak uygun QA teknikleri öğretilmiş bir programcı ile röportaj yapmadım.

Çoğu kuruluş, test rollerini yeni işe alan kişiye, kodunuza EN AZ maruz kalan kişiye atamanın ölümcül hatasına sahiptir - ideal olarak, kıdemli geliştiriciler, kodda deneyime sahip oldukları için QA rolüne taşınmalıdır. ve (umarım) ortaya çıkabilecek kod kokuları ve başarısızlık noktaları için altıncı bir his geliştirdik.

Dahası, hatayı yapan programcı muhtemelen kusuru bulamayacaktır çünkü bu genellikle bir sözdizimi hatası değildir (derlemede yakalanırlar), ancak bir mantık hatasıdır - ve aynı mantık, kodu yazarken olduğu gibi test edin. Kodu geliştiren kişinin bu kodu test etmesine izin vermeyin - herkesten daha az hata bulacaktır.

Sizin durumunuzda, yeniden yönlendirilmiş çalışma çabasını karşılayabiliyorsanız, bu yeni adamı QA ekibinizin ilk üyesi yapın. Ona "Gerçek Dünyada Yazılım Testi: Süreci İyileştirmek" adlı kitabı okumasını sağlayın, çünkü belli ki yeni görevinde biraz eğitime ihtiyacı olacak. Hoşuna gitmezse, istifa eder ve sorununuz çözülür.

Biraz daha az intikamcı bir yaklaşım, bu kişinin iyi olduğu şeyi yapmasına izin verilebilir (bu kişinin işe alındığını varsayıyorum çünkü aslında işin programlama kısmında yetkin olduğu için) ve testi yapmak için bir veya iki test görevlisi işe alması ( Üniversite öğrencileri genellikle staj veya "kooperatif" terimlerine sahiptir, maruz kalmaya bayılır ve ucuzdur)

Yan Not: Sonunda, QA ekibinin bir QA direktörüne veya en azından bir yazılım geliştirici yöneticisine rapor vermesini istemeyeceksiniz, çünkü QA ekibinin birincil hedefi ürünü bitirmek olan yöneticiye rapor vermesi, faiz.

Organizasyonunuz 6'dan küçükse veya yeni bir ekip oluşturmaktan kurtulamıyorsanız, eşli programlamayı (PP) öneririm. Ekstrem programlama tekniklerini tamamen değiştirmiyorum, ancak kesinlikle eşli programlamaya inanıyorum. Ancak, eşleştirilmiş programlama ekibinin her iki üyesi de kendini adamalıdır, yoksa bu işe yaramaz. İki kurala uymaları gerekir: müfettiş ekranda neyin kodlandığını tam olarak anlamalı veya kodlayıcıdan açıklamasını istemelidir; kodlayıcı yalnızca açıklayabildiği şeyi kodlayabilir - "göreceksiniz" veya "bana güvenmeyin" veya el sallamaya izin verilmez.

PP'yi yalnızca ekibiniz bunu yapabiliyorsa öneririm, çünkü test gibi, hiçbir tezahürat veya tehdit, ego dolu içedönükleri eğer bunu yapmakta kendilerini rahat hissetmezlerse birlikte çalışmaya ikna edemez. Bununla birlikte, ayrıntılı işlevsel özellikler yazma ve kod incelemeleri yapma ile eşleştirilmiş programlama arasında seçim yapma arasında, PP'nin genellikle kazandığını görüyorum.

PP sizin için değilse, TDD sizin için en iyi seçenektir, ancak sadece kelimenin tam anlamıyla alınırsa. Test Güdümlü Geliştirme, testleri İLK olarak yazmanız, gerçekten başarısız olduklarını kanıtlamak için testleri çalıştırmanız ve daha sonra çalışması için en basit kodu yazmanız anlamına gelir. Takas, artık binlerce testten oluşan bir koleksiyona sahip olmanızdır, ki bu da koddur ve üretim kodunun hatalar içermesi kadar muhtemeldir. Dürüst olacağım, TDD'nin büyük bir hayranı değilim, esasen bu nedenle, ancak test senaryoları yerine test komut dosyaları yazmayı tercih eden birçok geliştirici için işe yarıyor - bazı testler hiç yoktan iyidir. Daha iyi bir test kapsamı olasılığı ve komut dosyasında daha az hata için TDD'yi PP ile birleştirin.

Her şey başarısız olursa, programcıların bir küfür eşdeğeri olmasını sağlayın - programcı yapıyı her kırdığında, favorinize giden bir kavanozun içine 20 $, 50 $, 100 $ (personeliniz için orta derecede acı verici olan) koymaları gerekir ( kayıtlı Bağış. Ödeyene kadar, onlardan uzak dur :)

Tüm şakalar bir yana, programcınızın testler yazmasını sağlamanın en iyi yolu programlamasına izin vermemektir. Bir programcı istiyorsanız, bir programcı kiralayın - Test istiyorsanız, bir test uzmanı tutun. 12 yıl önce test yaparak genç bir programcı olarak başladım ve bu benim kariyer yoluma dönüştü ve hiçbir şey için takas etmem. Düzgün bir şekilde beslenen ve yazılımı geliştirme gücü ve yetkisi verilen sağlam bir Kalite Güvence departmanı, yazılımı ilk başta yazan geliştiriciler kadar değerlidir.

Bu biraz kalpsiz olabilir, ancak durumu tarif etme şeklin, bu adamı kovman gerekiyor gibi görünüyor. Ya da en azından netleştirin: ev geliştirme uygulamalarını takip etmeyi reddetmek (testler yazmak dahil) ve diğer insanların temizlemek zorunda olduğu buggy kodunu kontrol etmek, sonunda kovulmanıza neden olacaktır.

Genç mühendislerin / programcıların test komut dosyalarını tasarlamak ve gerçekleştirmek için çok fazla zaman harcamamasının ana nedeni, çoğu CS sertifikasının bunu yoğun bir şekilde gerektirmemesidir, bu nedenle diğer mühendislik alanları, tasarım kalıpları gibi üniversite programlarında daha ayrıntılı olarak ele alınır.

Tecrübelerime göre, genç profesyonelleri alışkanlık haline getirmenin en iyi yolu, bunu açıkça sürecin bir parçası haline getirmektir. Yani, bir yinelemenin alması gereken süre tahmin edilirken, vakaların tasarım, yazma ve / veya yürütme zamanı bu zaman tahminine dahil edilmelidir.

Son olarak, test komut dosyası tasarımının gözden geçirilmesi, bir tasarım incelemesinin parçası olmalıdır ve gerçek kod, kod incelemesinde gözden geçirilmelidir. Bu, programcıyı yazdığı her kod satırını uygun şekilde test etmekle yükümlü kılar ve kıdemli mühendis ve meslektaşları, kod ve yazılı test hakkında geri bildirim ve rehberlik sağlamakla yükümlüdür.

Yorumunuza dayanarak, "Tasarımın daha basit hale geldiğini göstererek" TDD uyguladığınızı varsayıyorum. Gerçek olduktan sonra bir kod incelemesi yapmak işe yaramayacaktır. TDD ile ilgili her şey, bunun bir test felsefesi değil bir tasarım olmasıdır. Testleri tasarımın bir parçası olarak yazmadıysa, gerçeklerden sonra test yazmaktan çok fazla fayda sağlamazsınız - özellikle de genç bir geliştiriciden. Sonunda pek çok köşe vakasını kaçıracak ve kodu hala berbat olacak.

En iyi bahsiniz, çok sabırlı bir üst düzey geliştiricinin onunla oturup bazı çift programlama yapmasıdır. Ve o öğrenene kadar devam edin. Ya da öğrenmiyor, bu durumda onu daha uygun olduğu bir göreve atamanız gerekir çünkü gerçek geliştiricilerinizi hayal kırıklığına uğratırsınız.

Herkes aynı düzeyde yetenek ve / veya motivasyona sahip değildir. Geliştirme ekipleri, hatta çevik olanlar, "A Takımı" ndaki kişilerden ve "B-Takımı" ndaki kişilerden oluşur. A Takımı üyeleri çözümü tasarlayan, önemsiz olmayan tüm üretim kodunu yazan ve işletme sahipleriyle iletişim kuran kişilerdir - kalıpların dışında düşünmeyi gerektiren tüm işler. B-Ekibi, yapılandırma yönetimi, komut dosyaları yazma, hatalı hataları düzeltme ve bakım çalışmaları gibi işleri - başarısızlık için küçük sonuçları olan katı prosedürleri olan tüm işleri - halleder.