Bir programcı başkasının başarısızlığını düzeltmeli mi? [kapalı]

Bir programcı SVN deposuna bazı işler yaptı, sonra eve gitti. O gittikten sonra Hudson otomatik inşası başarısız oldu. Başka bir programcı bunu gördü ve kod değişikliklerini inceledikten sonra, sorunun bir kütüphanenin bulunmadığını tespit etti. Bu kütüphaneyi SVN'ye ekledi ve bir sonraki inşa başarıyla tamamlandı.

İkinci programcı doğru şeyi yaptı mı ya da ilk programcı sorunu çözene kadar beklemeli miydi?

Takımınızın genelde nasıl çalıştığına bağlı, ama bunun iyi olduğunu söyleyebilirim. Yapıyı çalışır durumda tutmak herkese zaman kazandırır.

İkinci programcının ilk olarak, kütüphanenin belirli bir sürümüne ihtiyaç duyulması veya başka bir komplikasyon olması durumunda ne yaptığını açıklayan bir e-postayı bırakması kibarlıktır. Ayrıca, yapıyı kırdıklarını belirtmenin biraz daha ince bir yolu.

Değişir.

• Hata bir kütüphane eklemenin onu düzeltmenin yolu olduğu kadar açık mı? Bazen düzeltme, bu kütüphaneye ihtiyaç duymayacak bir çözüm bulmaktır.

• Proje, tüm değişikliklerin mevcut bir biletle ilişkilendirilmesi gereken bir aşamada mı? Eğer öyleyse, bir bilet verdiniz mi? Bu bilet size mi verildi?

Her neyse, sorumluluğu suçlamaya değil, hatayı düzeltmeye odaklan.

Evet tamamdır. Ancak, orijinal programcının derlemenin derlenip derlenmeyeceğini test etmeden önce eve gitmesi profesyonelce yapılmaz.

Şöhretiniz kontrolünüzde% 100'dür. Bu gibi şeyler itibarınızı zedeler ve kararmış bir ünü parlatmaya çalışmak çok zordur.

İletişim kurmak

Bu senaryo için kesin bir kural yoktur (kendi takım kurallarınızın yanında).

Dev2, dev1'e hatasını düzeltebileceğini söyleyebilmeli, hiçbiri bu değişimden kaynaklanan bir şeyden korkmamalı, bir takımın bir parçası değillerdir.

Neden olmasın? Ürününüzün suçlamaları tespit etmekten daha önemliyse, kesinlikle iyidir. Her ne kadar kütüphane değişikliği nedeniyle başarısız bir yapı oldukça topal olsa da, geliştiriciyi test etmediğiniz için kınama yapmanız gerekir.

Derleme başarısızlıkları olur. Günlük bir derlemenin gerçekleşmesi önemliyse, düzelteceğim ve daha sonra düzeltilen kodu gözden geçirmek ve kodun olması gerektiği gibi olduğundan emin olmak için bozuk kodu kontrol eden geliştiriciden rica ediyorum.

Söylendiği gibi, onu tamir eden adam muhtemelen kırdı adam e-posta ve düzeltmenin ne olduğunu detaylandırmak gerekir.

Benim sloganım, öğleden sonra saat 3'ten sonra SVN'ye bağlı kalmamaktır, bu şekilde kendi yapı hatalarınızı düzeltebilirsiniz.

Yapım başarısızlığını onaramazsanız, o zaman herkesin inşaatı da başarısız olur. Uzun vadede zaman kazanmak için düzeltirdim, ancak düzeltmeniz gerektiğinin farkında olduklarından emin olun.

Bir çeşit 'suçlama parmağını işaret' senaryosuna sahip olmak, bunu yapmanın ya da yapıyı kıran kişinin börekler almasını sağlamanın iyi bir yoludur !!

Birinin bunu düzeltmesi gerekiyor ve ilk programcının önce yapıyı bozmadığından emin olmadan eve gitmemesi gerekiyordu. Bununla birlikte, bu kadar kolay çözülemeyen bir problem için, onu düzeltmesi için onu geri çağırmak aşırı olurdu.

Luke Graham'ın açıklayıcı bir e-posta gönderme önerisi ile aynı fikirdeyim, buna rağmen kibar olmaktan çok daha basit - temel iletişim.

Evet evet evet! Kolektif kod sahipliğini teşvik eder ve yüksek standartlar elde etmek ve kırık bir pencere senaryosunun gelişmesine izin vermemek için takımda bir tür sağlıklı akran baskısı oluşturur. Diğer geliştiriciye bildirmek için biraz iletişim kurmak iyi bir fikirdir.

Bence açık olan şeyleri düzeltmenin bir sakıncası yok - yani,% 100 kodunu tamir ettiğiniz adamın aynı - veya büyük ölçüde aynı - düzeltmeyi yapacağından emin olmanız durumunda. Düzeltme daha karmaşıksa, kodunu tamir ettiğiniz kişiyle konuşmak genellikle kibardır - niyetini yanlış anlamış olabilirsiniz veya kırılma sebebi düşündüğünüz gibi değil ya da belki başka bir düzeltmeyi amaçlamış olabilir. ama bir nedenden ötürü henüz bunu tamamlayamadı (hayat olur, bilirsin :).

Genel olarak, kural genellikle şudur: yapıyı bozarsınız - yapıyı düzeltirsiniz, ancak istisnalar vardır, özellikle de düzeltme açıksa ve / veya sorumlu kişi erişilemezse.

Tabii ki, eğer özellikle "teslim edilmiş, eve gitti, günlerce bozuk bir yapı" deseni olan seri yapı kırıcı durumunuz varsa, sorumlu kişinin, CI sistemlerinin ve testlerin neden var olduğu ve birinin nasıl olması gerektiği hakkında konuşması gerekir. kontrol etmeden önce kontrol edin :)

Olur böyle şeyler. Subversion'a yeni bir kod dosyası (kaynak veya derlenmiş olsun) eklenememesi, geliştiricinin bilgisayarında çalıştığını farz edersek, büyük olasılıkla, bozuk yapıların en yaygın nedenidir. CI ortamındaki son işimde, bazen en yaşlıları bile unuttum.

Bence, eğer bir başkası binayı tamir edebildi ve bu yüzden takımı mırıldanmaya devam etseydi, sorun değil. Eve giden programcının en azından ne olduğunu söyleyen dostça bir e-postaya ihtiyaç duyduğunu ve yeni kodun taahhüt edilmeden önce eklendiğinden emin olmasını hatırlatması gerektiğini düşünüyorum. Sık sık ortaya çıkarsa, belki de utanç dansıyla cezalandırılan küçük bir suçu, olayları azaltmaya yardımcı olmak (ve ruh halini hafifletmek) için cezalandırın.

Bu, Takım dinamiğine bağlıdır, ancak ideal bir dünyada, Takımdaki herkes tüm projeye, tüm koda ve dolayısıyla tüm hatalara birlikte "sahip olur". Bu nedenle, bir sorun bulursanız, sorunu giderir ve yalnızca kodun belirli bir katma değeri varsa, hatanın kaynağı ile iletişim kurarsınız.

Bu normal bir durum olmadıkça düzeltmek sorun değil, bu durumda patronun onu aramasını ve onu geri getirip düzeltmesini sağlamış olurum.

Değişir, değişir ...

Programcılar olarak işimiz insanları yargılamak değil, işleri yürütmek. Bu nedenle, yapabileceğiniz en iyi şeyin düzeltmek olduğunu ya da açık değilse, değişiklikleri geri almak ve daha sonra düzeltebilmesi için ilk programcının bildirmesini sağlamak olduğunu söyleyebilirim.

Neyse, garip bir şapka giymek için yapıyı bozan en son çocuğa sahip olmak, bir dahaki sefere daha fazla dikkat etmek için yeterli.

Bazı ortamlarda bu çok kaba ve iyi nedenlerden dolayı. Diğer ortamlarda, beklenen ve iyi nedenlerden dolayı.

Yine de diğer ortamlarda, çok kötü nedenlerden dolayı çok kaba ya da beklenen.

Kırık bir yapının, doğrulanmış bir yapının ne kadar kritik olduğuna karşı ne kadar kritik olduğuna bağlıdır. Ve bir dereceye kadar, düzeltmenin doğru düzeltmenin ve ihtiyaç duyulan tek şeyin ne kadar belirgin olduğuna bağlı.

İlk olarak, 'eve gitti' bir anakronizmdir. Programcılar artık eve gitmiyor - sadece çevrimiçi veya çevrimdışı. Ping ve bekleyebilirsin.

Daha ciddiye, aslında sorunun iki kısmı var. 'kod değişikliklerine bakmak' iyi; Dinlenmek yapılacak doğru şey olmayabilir. Ya eksik bir kütüphane hakkındaki yargıları hatalıysa?