Açık denizde hata düzeltme

Potansiyel bir işveren "geliştiricilerin hataları düzeltmekten nefret ettikleri için hata düzeltmeyi dış kaynaklı kullandıklarını" söylerse, Ne düşünürdünüz? Endişeleriniz ne olabilir?

Kendi hatalarımızı düzeltmek aslında bizi daha iyi bir geliştirici yapar . Ve bu benim için oldukça keyifli bir andı. Özellikle güzelce rapor edildiğinde.

Eğer hataları düzeltmeyi sevmezlerse, sorun başka bir yerde yatar.

Sorunun, hataların yönetim tarafından veya daha kötüsü, kötü tasarım kararları ve / veya hayır (birim) testi ile nasıl algılandığı ve hata düzeltmesinin acı verici olmasına neden olduğundan şüpheleniyorum.

Dış kaynak hata düzeltmesi muhtemelen her şeyi daha da kötüleştirecektir.

Geliştiriciler kaliteyi düşürmeye cazip gelebilir. Kimin umrunda? Bazı denizaşırı adamlar dağınıklığını temizlemek için oradalar.

Kıyı ötesi adamlar karadaki adamların yerini alana kadar.

Bırakın , kaçın ... hızlı ve asla arkana bakma ...

Böyle bir şirkette çalıştım, akıllı olduklarını düşündüler,

• hey biz tüm hataları var ama bizim yaşlılar hataları düzeltmek için çok fazla zaman harcamak şikayet.

• bir offshore ofisi açalım ve diğerlerinin bununla ilgilenmesine izin verelim.

gerçekten iyi bir plan gibi geliyor bir yönetici için ve devs nihayet bir sonraki en iyi şey oluşturma daha ilginç görev mücadele için serbest bırakıldı!

ho ... ama bekle ...

iki yıl sonra, ana ofislerinde her şeyi yeni şeyler oluşturan 2 kişilik bir takıma ve hataları bulan ve düzelten 30 kişilik bir takıma giden 5 devs'lik bir ekipten gittiler.

Biliyor musun ... böcek tamir ekibi mücadele ediyor, ayak uyduramıyorlar.

bu, "yaşlıları" kendi hataları için tamamen sorumsuz hale getirdi. En kötüsü, çünkü o kadar uzakta oldu çünkü yönetim de fark etmedi ve kod kalitesi ÇOK hızlı zaten abysmal kalite seviyesinden düştü.

Ben ayrıldıkları zaman zaten hata düzelticiler için iki ofis daha açtılar ve hala onları yaratan sadece dev şimdi geride kalamazlar. aslında bunun yeni adamlar yeterince zeki olmadıklarını düşünüyorlar ...

yani evet, bundan sonra, eğer bir şirket onlar yurtdışı bir ofise sabitleme onların hata dış kaynak diyorlar bana güven .... koşmak ... hızlı.

Bu Paper Bag yönetim metodolojisidir.

Bir demiryolunda durun, bir trenin gelmesini bekleyin, gördüğünüzde kafanızın üstüne bir kağıt torba koyun ve ... POOF .. tren gitti !!. Büyü!

Şirket benim 'temiz' kodunu almak ve yeni özellikler eklemek dışında benim karışıklık temizlemek için başkasına ödeme yapmak iyi bir fikir gibi geliyor. Ve eğer bunu düzeltemeyecek kadar berbat yaparlarsa, hata ayıklama hata ayıklama olacak.

Ek geliştiriciler işe almak zorunda oldukları için yeterince telafi edilmemek arzu edilmez.

Diğer geliştiricilere bunu kendiniz düzeltebildiğiniz zaman eğitmek için orantısız bir zaman harcamak zorunda kalmak karşı üretken.

Bir parçam, sorun yaratanların bunları düzeltecek olanlar olması gerektiğini düşünüyor ya da ilk etapta hata yaratmaktan kaçınmak için bir teşvik yok.

Geliştiriciler hatalarından öğrenmek istemiyor mu? Belirli bir alan bilgisi olmadan hataları düzeltebilir misiniz ve dış kaynak ortağı bu bilgiye sahip mi? Sabitleme kısmı çoğu zaman en kolay olanıdır, zaman alan analiz kısmıdır. Benim bakış açımdan bu aptalca bir karardır.

Potansiyel bir işveren "geliştiricilerin hataları düzeltmekten nefret ettikleri için hata düzeltmeyi dış kaynaklı kullandıklarını" söylerse, Ne düşünürdünüz? Endişeleriniz ne olabilir?

Çok, çok, çok uzaklara koşardım. Bir geliştirici her zaman, her zaman, kendi hatalarını düzeltmekten her zaman sorumludur. Köpek maması yemek iyi bir mühendisliğin temel ilkesidir.

Ayrıca, hata düzeltmesi de geliştirme kadar önemli. Yani, geliştirme kod yazma, test etme ve hata ayıklama / düzeltme.

Bu şirketten aldığım hata düzeltmesini ikinci sınıf bir görev olarak görüyorlar. Bu kendi başına oldukça rahatsız edicidir ve onların çalışma kalitesini (ve ergo, çalışma ortamını) çok sorgulayacağım. Bu daha rahatsız edici. Açıkçası mühendislik süreçlerinde sosyal tabakalaşma vardır.

Bir kusur her zaman bir değişikliğe kökten kaynaklanır ve genellikle hata, değişikliği kimin yaptıracağının sorumluluğundadır. Hatanın doğasını ve çözümünü anlamak için yaratıcıdan kim daha iyi?

Dünya çapında yetkilendirilmişse, orijinal yazarın açık deniz mühendisine ulaştığından nasıl emin olabilirsiniz?

Hatalar ve son teslim tarihlerinden oluşan bir birikimden başka bir şey olmayan, ancak Metropole'den destek olmayan, açık deniz mühendisini bırakacak mı? Bir kişi ne tür bir hata düzeltmesini gerçekleştirmeyi umabilir? Böceklerini kim düzeltir? Ve Metropole'un geliştiricilerinin ölüm sonrası hata düzeltme yoluyla öğrenmesini ne engelliyor?

Bütün alanlarda pislikler var. Bu özellikle yazılım için geçerlidir. Bu kaçınılmaz olduğu için, tek seçeneğiniz sizden daha fazlasını bilen ya da işleri doğru yapan pislikler ile çalışmaktır . Bu şirket bu tanıma uymuyor gibi görünüyor.

Kısacası, kaç.

Gerçekten bir grup off-shore genç geliştiricinin bir grup üst düzey geliştirici kodunu çözmesini bekliyorlar mı? Tıpkı bir hemşire tüm nöroligistlerin çalışmasını iki kez kontrol etmek ve mistikes yaptığı yerde yeniden yapmak gibi. KÖTÜ BİR FİKİR!

Çalışanlarının geliştirdikleri kodu gerçekten ne kadar iyi tanıdıklarından endişe ediyorum.
Ayrıca, bunun getirdiği ek maliyetleri haklı çıkarmak için yeterli hata olduğunu merak ediyorum. Ayrıca şirketin uzun vadeli geleceği hakkında endişelenirim, web üzerinde bu firmaların iddia ettiği, aynı sektörde bile birden fazla proje için aynı kodu kullanan birçok makale var.

Kırık kodu düzeltme, kod yazma işleminin bir parçasıdır, 6 ay önce neyi yanlış yaptığınızı daha iyi anlamanıza izin verir, bu nedenle aynı hatayı yapmazsınız, başka bir geliştirici hatalarınızı düzeltirse nasıl önlersiniz tekrar tekrar gelen hata?

"Muhtemel işveren" biti dışında bu, önceki işverenime benziyor. Geliştiricileri yıpratmak için kaybediyorlar ve kanun ve yönetmeliklerdeki değişikliklerin gerektirdiği yeni özellikler eklerken mevcut ürünleri destekleyemeyecek kadar çok kaybettiler (ofis gelirlerinin% 60'ı VB6 tabanlı bir üründen geliyor ve MS, VB6 çalışma zamanlarını belirtti. gelecekteki herhangi bir işletim sisteminde dağıtılmayacak, bu yüzden Vista çıktığında olduğu gibi - şeyleri düzeltmek için çılgın bir karıştırma). Bu güçler şirketi yakında halka tanıtmak istiyorlar, bu yüzden bilançonun olduğundan daha iyi görünmesi için kaynak için herkesi aç bırakıyorlar - bu yüzden denizde işe almak piyasada kalmaya yaklaşmanın tek yoludur.

Deneyimlerime dayanarak, teklifin söylediği şey, potansiyel işvereninizin ucuz olmasıdır.

"Hataların düzeltilmesi" ile ne anlama geldiklerine bağlıdır. Bu, dev / test döngüsü sırasında hataları düzeltiyorsa, çok garip, bu orijinal geliştiricilerin işi. Öte yandan, serbest bırakılan bir ürünün dış kaynaklı bakımını yaptıkları anlamına gelirse, bu sıra dışı değildir ve endişeleneceğim bir şey değildir.

Deneyimlerim, gerçek bir hatadan sonra harici bir ekibe katılmanın, sadece kendi hatalarınızı düzeltmek kadar zaman harcayacağıdır - hızlandırılmaları ve geliştirme sürecine getirilmeleri gerekir. Ve sonra sürekli hızlanmaya devam etti. Koordinasyon, kod yazmaktan daha zordur.

Eğer bir kod tabanı üzerinde çalışacaksam, taahhüt ayrıcalıklarına sahip olan herkesin oldukça yetkin olduğuna dair bir güvence istiyorum. Buna Hindistan'daki birkaç kişi dâhildir, ancak genellikle reşit olmayanlar dahil değildir.

Dahası, hatalarımın çoğu kodun daha karmaşık bölümlerinde ve bunlar bir hata düzeltmesi uygulamadan önce offshore programcısının anlaması en az muhtemel olanlardır.

Bu politika aslında bazı şirketlerde bilinçaltında var. Bir işveren için çalışıyorum; kendim ve meslektaşlarım, sahadaki adamlardan daha yetkin programcılar, onlara araçların nasıl kullanılacağını öğretmemizi istiyorlar, ancak bunun diğer tarafı kodlarındaki problemleri onlardan daha hızlı tespit edeceğiz.

Genellikle müşterinin programcıları fiziksel olarak en azından bazı kullanıcılarla aynı binada bulunur, bu nedenle yarımkürelere ulaşmayan bağlam elde etme olasılıkları daha yüksektir. İyi çalıştığını görüyoruz, benim için eksik olan kısım, kodumuzu gözden geçirmemeleridir, bu yüzden sözleşme bittiğinde bazı sürprizler veya sorular olabilir, bizim tarafımızdaki çaput uygulamalardan dolayı değil, sadece olağan sorunlarınız nedeniyle başkasının projesini devralmak.

Her durumda, bizim durumumuzda resmi bir politika olmadığına sevindim, bu yüzden yerinde programcıların BA'lardan biraz daha fazla olmasına neden olacağını düşünüyorum.