Gdyby przyszły pracodawca powiedział ci, że „zlecał naprawę błędów, ponieważ programiści nienawidzą naprawiania błędów”, co byś pomyślał? Jakie mogą być twoje obawy?
Deweloperzy nie znoszą naprawiania błędów? Myślę, że bardziej nienawidzą znaleźć wiarygodnego sposobu na odtworzenie błędu, do czego właśnie służą testerzy. Jeśli zlecasz naprawę błędów, równie dobrze możesz zlecić cały zespół programistów. Nikt nie rozumie kodu ani osoby, która go napisała .
Rob
1
Brzmi jak okropny pomysł.
Andres F.,
1
@AndresF. +1. Stworzy to środowisko, w którym deweloperzy po prostu rzucą bzdury na ścianę i mają nadzieję, że się przylegają. Czy to nie ich problem, jeśli tak nie jest, prawda?
MrFox
Odpowiedzi:
25
Naprawianie własnych błędów sprawia, że jesteśmy lepszym programistą . To dla mnie bardzo przyjemny moment. Zwłaszcza gdy są ładnie zgłaszane.
Jeśli nie lubią naprawiać błędów, problem leży gdzie indziej.
Podejrzewam, że problem polega na tym, jak błędy są postrzegane przez kierownictwo lub gorzej, przez złe decyzje projektowe i / lub brak testów (jednostkowych), powodując bolesne naprawianie błędów.
Naprawianie błędów w outsourcingu prawdopodobnie pogorszy sprawę.
Programiści mogą ulec pokusie obniżenia jakości. Kogo to obchodzi? Niektórzy przybrzeżni faceci są tutaj, aby posprzątać swój bałagan.
Dopóki faceci na morzu nie zastąpią facetów na lądzie.
@Aditya: nic strasznego tutaj, właśnie to dokładnie dzieje się u mojego ostatniego pracodawcy. Faceci na morzu cały czas mieli dość naprawiania błędów, a ich menedżer (amen) zaczął organizować szkolenia. W pewnym momencie byli wystarczająco dobrzy, aby rozpocząć proste refaktory, porządki itp. Tymczasem w głównym biurze nic się nie zmieniło. Widzę bardzo łatwo, że w ciągu następnego roku faceci na morzu wykonają większość pracy, a faceci z głównego biura ... no cóż ... szkoda, że nie widzieli nadjeżdżającego pociągu ;-P
Newtopian
15
Wyjdź , uciekaj ... szybko i nigdy nie oglądaj się za siebie ...
Pracowałem dla takiej firmy, myśleli, że są mądrzy,
hej, mamy wszystkie błędy, ale nasi seniorzy narzekają, że spędzają zbyt dużo czasu na naprawianiu błędów.
otwórzmy biuro offshore i pozwólmy sobie z tym poradzić.
dla menedżera, który brzmi jak naprawdę dobry plan, a deweloperzy w końcu zostali uwolnieni, aby zająć się bardziej interesującym zadaniem stworzenia następnej najlepszej rzeczy !!
ho ... ale czekaj ...
po dwóch latach przeszli z zespołu 5 deweloperów w ich głównym biurze, który zajął się tym wszystkim, do zespołu 2, który tworzy nowe rzeczy i zespołu 30, który znajduje i naprawia błędy.
wiesz co ... zespół zajmujący się naprawą błędów walczy, nie może nadążyć.
sprawiło to, że „seniorzy” byli całkowicie nieliczni z własnych błędów. Co gorsza, ponieważ to wszystko zdarzyło się tak daleko, zarządzanie również nie zdawało sobie z tego sprawy, a jakość kodu spadła BARDZO szybko z już i tak fatalnego poziomu jakości.
Kiedy odszedłem, otworzyli już dwa kolejne biura do usuwania błędów i nadal nie mogą nadążyć za jedynym teraz twórcą, który je tworzy. myślą, że to dlatego, że nowi faceci nie są wystarczająco mądrzy ...
więc tak, od teraz, jeśli firma twierdzi, że zleciła naprawę błędu zagranicznemu biuru, zaufaj mi ... uciekam ... szybko.
Jest to metodologia zarządzania torbą papierową .
Stań na linii kolejowej, poczekaj na pociąg, kiedy ją zobaczysz, załóż papierową torbę na głowę i ... POOF .. pociąg odjechał !!. Magia !
To, że firma płaci komuś innemu za posprzątanie mojego bałaganu, wydaje się dobrym pomysłem, chyba że spodziewam się, że wezmę „czysty” kod i dodam nowe funkcje. A jeśli zrobią to tak zepsute, że nie będą w stanie tego naprawić, będziesz debugować debugowanie.
Niewłaściwe wynagrodzenie, ponieważ muszą oni zatrudnić dodatkowych programistów, nie jest pożądane.
Konieczność poświęcania nieproporcjonalnej ilości czasu na edukowanie innych programistów, kiedy można to naprawić samodzielnie, przynosi efekt przeciwny do zamierzonego.
Część mnie uważa, że to ci, którzy stwarzają problemy, powinni naprawiać je lub nie ma motywacji, aby unikać tworzenia błędów.
Czy programiści nie są zainteresowani uczeniem się na własnych błędach? Czy potrafisz naprawić błędy bez określonej wiedzy na temat domeny i czy partner outsourcingowy ma taką wiedzę? Część mocująca jest najłatwiejsza przez większość czasu, jej część analizująca wymaga czasu. Z mojej perspektywy jest to głupia decyzja.
Gdyby przyszły pracodawca powiedział ci, że „zlecał naprawę błędów, ponieważ programiści nienawidzą naprawiania błędów”, co byś pomyślał? Jakie mogą być twoje obawy?
Uciekłbym daleko, daleko, daleko. Deweloper jest zawsze, zawsze, zawsze odpowiedzialny za naprawianie własnych błędów. Jedzenie psiej karmy to podstawowa zasada dobrej inżynierii.
Co więcej, naprawa błędów jest równie ważna, być może nawet ważniejsza niż programowanie. Mam na myśli, że rozwój to pisanie, testowanie i debugowanie / poprawianie kodu.
To, co otrzymuję od tej firmy, to to, że traktują naprawę błędów jako zadanie drugiej kategorii. To samo w sobie jest dość niepokojące i bardzo chciałbym zakwestionować ich jakość pracy (i ergo, ich środowisko pracy). Bardziej niepokojące jest to, że delegują to, co dla nich jest pracą drugiej kategorii, na pracowników na morzu. To bardziej niepokojące. Wyraźnie widać, że w ich procesie inżynieryjnym uwarunkowane jest rozwarstwienie społeczne.
Wada jest zawsze spowodowana pierwotną zmianą i zazwyczaj za błąd odpowiada ten, kto wprowadził zmianę. Kto lepiej niż twórca, aby zrozumieć naturę błędu i jego rozwiązanie?
Jeśli jest delegowany na cały świat, w jaki sposób upewnić się, że oryginalny autor jest dostępny dla offshored inżyniera?
Czy w ogóle będzie dostępny, pozostawiając offshored inżyniera, który nie ma nic poza zaległymi błędami i terminami, ale nie ma wsparcia ze strony Metropole ? Jaki rodzaj naprawy błędu może wykonać osoba? Kto naprawia jego błędy? A co uniemożliwia programistom Metropole naukę poprzez naprawianie błędów pośmiertnie?
We wszystkich polach są dupki. Jest to szczególnie prawdziwe w oprogramowaniu. Ponieważ jest to nieuniknione, jedyną opcją jest praca z dupkami, które wiedzą więcej od ciebie lub robią wszystko dobrze. Ta firma nie pasuje do tego opisu.
„Ponadto usuwanie błędów jest równie ważne, być może nawet ważniejsze niż programowanie”. Wiem, co masz na myśli, ale posunę się aż do stwierdzenia: nie mogę pojąć takiej dychotomii. Naprawianie błędów jest nieodłącznym, podstawowym aspektem rozwoju.
Dan Ray
1
@ Dan - tak, twoje stwierdzenie jest znacznie bardziej poprawne. Nie istnieje taka dychotomia.
luis.espinal
4
Czy naprawdę oczekują, że grupa młodszych programistów off-shore będzie w stanie naprawić grupę starszych programistów? To tak, jakby pielęgniarka dwukrotnie sprawdzała, czy wszyscy neuroligiści pracują, i robiła to tam, gdzie popełnił błędy. ZŁY POMYSŁ!
Byłbym zaniepokojony tym, jak dobrze ich pracownicy znają kod, który opracowują.
Zastanawiam się również, dlaczego jest wystarczająco dużo błędów, aby uzasadnić dodatkowe koszty, które to powoduje. Martwiłbym się również o długoterminową przyszłość firmy, istnieje wiele artykułów w Internecie, które twierdzą, że te firmy używają tego samego kodu do wielu projektów, nawet w tej samej branży.
Naprawianie uszkodzonego kodu jest częścią procesu pisania kodu, pozwala lepiej zrozumieć, co zrobiłeś źle 6 miesięcy temu, więc nie popełniasz tego samego błędu, jeśli jakiś inny programista naprawi twoje błędy, jak temu zapobiec błąd się powtarzał?
Brzmi to niejasno jak mój poprzedni pracodawca, z wyjątkiem bitu „potencjalny pracodawca”. Tracą deweloperów na ścieranie i stracili zbyt wielu, aby wesprzeć istniejące produkty, jednocześnie dodając nowe funkcje wymagane przez zmiany przepisów i regulacji (60% przychodów biura pochodzi z produktu opartego na VB6, a MS stwierdziło, że środowiska wykonawcze VB6 nie będzie dystrybuowany w żadnym przyszłym systemie operacyjnym, więc będzie tak, jak w momencie pojawienia się Visty - szalona walka o naprawę). Potęgi, które wkrótce będą chciały upublicznić firmę, więc głodują wszystkich, aby zdobyć zasoby, aby bilans wyglądał lepiej niż jest w rzeczywistości - więc zatrudnienie za granicą jest jedynym sposobem na zbliżenie się do pozostania na rynku.
Z moich doświadczeń wynika, że cytat mówi, że twój potencjalny pracodawca jest tani.
@Ramhound, David, Greg, To było lepsze miejsce, kiedy zaczynałem, opuściłem to miejsce pod koniec grudnia (krótko po mojej 5. rocznicy). Nikt nie został zatrudniony, odkąd zostałem zatrudniony, aw ciągu ostatnich 2 lat 6 programistów zrezygnowało. Ostatni, który odszedł, był tam 11 lat.
Tangurena
3
To zależy, co rozumieją przez „naprawianie błędów”. Jeśli to naprawia błędy podczas cyklu tworzenia / testowania, jest to bardzo dziwne, jest to zadanie dla oryginalnych programistów. Z drugiej strony, jeśli oznaczają, że zlecili konserwację wydanego produktu, to nie jest to niczym niezwykłym i nie martwię się o to.
@Greg & Steve - Nie sądzę, żeby to było szczere. Jeśli naprawiają błędy, powiedzmy w wersji Release, w jaki sposób poprawki te mogą zostać scalone z wersją testową, jeśli programiści nie piszą błędów, aby je naprawić.
Ramhound,
Jeśli poprawki błędów są sprawdzane w celu kontroli źródła, mogą być łatwo przeniesione przez inny zespół do innej gałęzi. To wcale nie jest wielka sprawa.
Steve
Masz rację, choć naprawdę zatwierdzam ten scenariusz tylko w przypadku, gdy aplikacja jest starszym systemem, który nie jest już aktywnie rozwijany, ale z jakiegoś powodu musi być nadal funkcjonalny. Powiedz nową generację, która jest kompletnym przepisaniem od tej, o której mowa.
Newtopian
2
Z mojego doświadczenia wynika, że sprowadzenie zewnętrznego zespołu po tym, jak fakt ten spędzi tyle samo czasu, co naprawienie własnych błędów - należy je przyspieszyć i wprowadzić w proces rozwoju. A potem ciągle na bieżąco. Koordynacja jest trudniejsza niż pisanie kodu.
Jeśli mam pracować nad bazą kodu, chciałbym mieć pewność, że każdy z uprawnieniami do zatwierdzania jest w miarę kompetentny. Dotyczy to, powiedzmy, kilku osób w Indiach, ale nie tych, którym zwykle towarzyszy offshoring.
Co więcej, większość moich błędów znajduje się w bardziej skomplikowanych sekcjach kodu i są to te, które programista offshore najmniej zrozumie przed zastosowaniem poprawki.
Ta polityka faktycznie istnieje podświadomie w niektórych firmach. Pracuję dla outsourcera; ja i moi koledzy jesteśmy bardziej biegłymi programistami niż faceci na miejscu, proszą nas, abyśmy nauczyli ich, jak korzystać z narzędzi itp., ale z drugiej strony to, że wykryjemy problemy w kodzie szybciej niż oni.
Zasadniczo programiści klienta są fizycznie zlokalizowani w tym samym budynku co najmniej niektórzy użytkownicy, więc bardziej prawdopodobne jest uzyskanie kontekstu, który nie dociera przez półkule. Uważamy, że działa dobrze, brakuje mi tego, że nie sprawdzają naszego kodu, więc kiedy umowa dobiegnie końca, mogą mieć pewne niespodzianki lub pytania, niekoniecznie z powodu tandetnych praktyk z naszej strony, ale tylko zwykłe problemy, które masz, gdy przejmowanie czyjegoś projektu.
W każdym razie cieszę się, że w naszym przypadku nie jest to oficjalna polityka, dlatego uważam, że zniszczyłoby to programistów na miejscu, ponieważ byliby niewiele więcej niż licencjatami.
Odpowiedzi:
Naprawianie własnych błędów sprawia, że jesteśmy lepszym programistą . To dla mnie bardzo przyjemny moment. Zwłaszcza gdy są ładnie zgłaszane.
Jeśli nie lubią naprawiać błędów, problem leży gdzie indziej.
Podejrzewam, że problem polega na tym, jak błędy są postrzegane przez kierownictwo lub gorzej, przez złe decyzje projektowe i / lub brak testów (jednostkowych), powodując bolesne naprawianie błędów.
Naprawianie błędów w outsourcingu prawdopodobnie pogorszy sprawę.
Programiści mogą ulec pokusie obniżenia jakości. Kogo to obchodzi? Niektórzy przybrzeżni faceci są tutaj, aby posprzątać swój bałagan.
Dopóki faceci na morzu nie zastąpią facetów na lądzie.
źródło
Wyjdź , uciekaj ... szybko i nigdy nie oglądaj się za siebie ...
Pracowałem dla takiej firmy, myśleli, że są mądrzy,
hej, mamy wszystkie błędy, ale nasi seniorzy narzekają, że spędzają zbyt dużo czasu na naprawianiu błędów.
otwórzmy biuro offshore i pozwólmy sobie z tym poradzić.
dla menedżera, który brzmi jak naprawdę dobry plan, a deweloperzy w końcu zostali uwolnieni, aby zająć się bardziej interesującym zadaniem stworzenia następnej najlepszej rzeczy !!
ho ... ale czekaj ...
po dwóch latach przeszli z zespołu 5 deweloperów w ich głównym biurze, który zajął się tym wszystkim, do zespołu 2, który tworzy nowe rzeczy i zespołu 30, który znajduje i naprawia błędy.
wiesz co ... zespół zajmujący się naprawą błędów walczy, nie może nadążyć.
sprawiło to, że „seniorzy” byli całkowicie nieliczni z własnych błędów. Co gorsza, ponieważ to wszystko zdarzyło się tak daleko, zarządzanie również nie zdawało sobie z tego sprawy, a jakość kodu spadła BARDZO szybko z już i tak fatalnego poziomu jakości.
Kiedy odszedłem, otworzyli już dwa kolejne biura do usuwania błędów i nadal nie mogą nadążyć za jedynym teraz twórcą, który je tworzy. myślą, że to dlatego, że nowi faceci nie są wystarczająco mądrzy ...
więc tak, od teraz, jeśli firma twierdzi, że zleciła naprawę błędu zagranicznemu biuru, zaufaj mi ... uciekam ... szybko.
Jest to metodologia zarządzania torbą papierową .
Stań na linii kolejowej, poczekaj na pociąg, kiedy ją zobaczysz, załóż papierową torbę na głowę i ... POOF .. pociąg odjechał !!. Magia !
źródło
To, że firma płaci komuś innemu za posprzątanie mojego bałaganu, wydaje się dobrym pomysłem, chyba że spodziewam się, że wezmę „czysty” kod i dodam nowe funkcje. A jeśli zrobią to tak zepsute, że nie będą w stanie tego naprawić, będziesz debugować debugowanie.
Niewłaściwe wynagrodzenie, ponieważ muszą oni zatrudnić dodatkowych programistów, nie jest pożądane.
Konieczność poświęcania nieproporcjonalnej ilości czasu na edukowanie innych programistów, kiedy można to naprawić samodzielnie, przynosi efekt przeciwny do zamierzonego.
Część mnie uważa, że to ci, którzy stwarzają problemy, powinni naprawiać je lub nie ma motywacji, aby unikać tworzenia błędów.
źródło
Czy programiści nie są zainteresowani uczeniem się na własnych błędach? Czy potrafisz naprawić błędy bez określonej wiedzy na temat domeny i czy partner outsourcingowy ma taką wiedzę? Część mocująca jest najłatwiejsza przez większość czasu, jej część analizująca wymaga czasu. Z mojej perspektywy jest to głupia decyzja.
źródło
Uciekłbym daleko, daleko, daleko. Deweloper jest zawsze, zawsze, zawsze odpowiedzialny za naprawianie własnych błędów. Jedzenie psiej karmy to podstawowa zasada dobrej inżynierii.
Co więcej, naprawa błędów jest równie ważna, być może nawet ważniejsza niż programowanie. Mam na myśli, że rozwój to pisanie, testowanie i debugowanie / poprawianie kodu.
To, co otrzymuję od tej firmy, to to, że traktują naprawę błędów jako zadanie drugiej kategorii. To samo w sobie jest dość niepokojące i bardzo chciałbym zakwestionować ich jakość pracy (i ergo, ich środowisko pracy). Bardziej niepokojące jest to, że delegują to, co dla nich jest pracą drugiej kategorii, na pracowników na morzu. To bardziej niepokojące. Wyraźnie widać, że w ich procesie inżynieryjnym uwarunkowane jest rozwarstwienie społeczne.
Wada jest zawsze spowodowana pierwotną zmianą i zazwyczaj za błąd odpowiada ten, kto wprowadził zmianę. Kto lepiej niż twórca, aby zrozumieć naturę błędu i jego rozwiązanie?
Jeśli jest delegowany na cały świat, w jaki sposób upewnić się, że oryginalny autor jest dostępny dla offshored inżyniera?
Czy w ogóle będzie dostępny, pozostawiając offshored inżyniera, który nie ma nic poza zaległymi błędami i terminami, ale nie ma wsparcia ze strony Metropole ? Jaki rodzaj naprawy błędu może wykonać osoba? Kto naprawia jego błędy? A co uniemożliwia programistom Metropole naukę poprzez naprawianie błędów pośmiertnie?
We wszystkich polach są dupki. Jest to szczególnie prawdziwe w oprogramowaniu. Ponieważ jest to nieuniknione, jedyną opcją jest praca z dupkami, które wiedzą więcej od ciebie lub robią wszystko dobrze. Ta firma nie pasuje do tego opisu.
W skrócie, uciekaj.
źródło
Czy naprawdę oczekują, że grupa młodszych programistów off-shore będzie w stanie naprawić grupę starszych programistów? To tak, jakby pielęgniarka dwukrotnie sprawdzała, czy wszyscy neuroligiści pracują, i robiła to tam, gdzie popełnił błędy. ZŁY POMYSŁ!
źródło
Byłbym zaniepokojony tym, jak dobrze ich pracownicy znają kod, który opracowują.
Zastanawiam się również, dlaczego jest wystarczająco dużo błędów, aby uzasadnić dodatkowe koszty, które to powoduje. Martwiłbym się również o długoterminową przyszłość firmy, istnieje wiele artykułów w Internecie, które twierdzą, że te firmy używają tego samego kodu do wielu projektów, nawet w tej samej branży.
Naprawianie uszkodzonego kodu jest częścią procesu pisania kodu, pozwala lepiej zrozumieć, co zrobiłeś źle 6 miesięcy temu, więc nie popełniasz tego samego błędu, jeśli jakiś inny programista naprawi twoje błędy, jak temu zapobiec błąd się powtarzał?
źródło
Brzmi to niejasno jak mój poprzedni pracodawca, z wyjątkiem bitu „potencjalny pracodawca”. Tracą deweloperów na ścieranie i stracili zbyt wielu, aby wesprzeć istniejące produkty, jednocześnie dodając nowe funkcje wymagane przez zmiany przepisów i regulacji (60% przychodów biura pochodzi z produktu opartego na VB6, a MS stwierdziło, że środowiska wykonawcze VB6 nie będzie dystrybuowany w żadnym przyszłym systemie operacyjnym, więc będzie tak, jak w momencie pojawienia się Visty - szalona walka o naprawę). Potęgi, które wkrótce będą chciały upublicznić firmę, więc głodują wszystkich, aby zdobyć zasoby, aby bilans wyglądał lepiej niż jest w rzeczywistości - więc zatrudnienie za granicą jest jedynym sposobem na zbliżenie się do pozostania na rynku.
Z moich doświadczeń wynika, że cytat mówi, że twój potencjalny pracodawca jest tani.
źródło
To zależy, co rozumieją przez „naprawianie błędów”. Jeśli to naprawia błędy podczas cyklu tworzenia / testowania, jest to bardzo dziwne, jest to zadanie dla oryginalnych programistów. Z drugiej strony, jeśli oznaczają, że zlecili konserwację wydanego produktu, to nie jest to niczym niezwykłym i nie martwię się o to.
źródło
Z mojego doświadczenia wynika, że sprowadzenie zewnętrznego zespołu po tym, jak fakt ten spędzi tyle samo czasu, co naprawienie własnych błędów - należy je przyspieszyć i wprowadzić w proces rozwoju. A potem ciągle na bieżąco. Koordynacja jest trudniejsza niż pisanie kodu.
źródło
Jeśli mam pracować nad bazą kodu, chciałbym mieć pewność, że każdy z uprawnieniami do zatwierdzania jest w miarę kompetentny. Dotyczy to, powiedzmy, kilku osób w Indiach, ale nie tych, którym zwykle towarzyszy offshoring.
Co więcej, większość moich błędów znajduje się w bardziej skomplikowanych sekcjach kodu i są to te, które programista offshore najmniej zrozumie przed zastosowaniem poprawki.
źródło
Ta polityka faktycznie istnieje podświadomie w niektórych firmach. Pracuję dla outsourcera; ja i moi koledzy jesteśmy bardziej biegłymi programistami niż faceci na miejscu, proszą nas, abyśmy nauczyli ich, jak korzystać z narzędzi itp., ale z drugiej strony to, że wykryjemy problemy w kodzie szybciej niż oni.
Zasadniczo programiści klienta są fizycznie zlokalizowani w tym samym budynku co najmniej niektórzy użytkownicy, więc bardziej prawdopodobne jest uzyskanie kontekstu, który nie dociera przez półkule. Uważamy, że działa dobrze, brakuje mi tego, że nie sprawdzają naszego kodu, więc kiedy umowa dobiegnie końca, mogą mieć pewne niespodzianki lub pytania, niekoniecznie z powodu tandetnych praktyk z naszej strony, ale tylko zwykłe problemy, które masz, gdy przejmowanie czyjegoś projektu.
W każdym razie cieszę się, że w naszym przypadku nie jest to oficjalna polityka, dlatego uważam, że zniszczyłoby to programistów na miejscu, ponieważ byliby niewiele więcej niż licencjatami.
źródło