W ramach przeglądu wszystkich opisów stanowisk moja firma postanowiła uwzględnić jako kluczowe dane wyjściowe:

tworzenie stron internetowych ukończone na czas, w ramach specyfikacji i bezbłędnie

Biorąc pod uwagę, że specyfikacje regularnie się zmieniają, nie ma formalnego procesu kontroli zmian, a środowiska są, powiedzmy, trochę nieprzewidywalne, jak realistyczny i rozsądny jest ten KPI?

„Bez błędów” jest zdecydowanie zbyt subiektywne . „Niewypełnione żądanie funkcji” jednego człowieka jest „błędem” innego człowieka. Bardziej odpowiednie byłoby coś w rodzaju „Powinny zasadniczo spełniać specyfikacje projektowe”. Nigdy nie widziałem tego, co opisujesz w opisie stanowiska. Widziałem to dla pracy kontraktowej , ale nie dla pracowników.

Zajmę stanowisko przeciwne do większości odpowiedzi i powiem, że jest to absolutnie rozsądne i realistyczne.

Czy cały rozwój zostanie ukończony na czas? Oczywiście, że nie, nie zawsze.

Czy cały rozwój zostanie ukończony zgodnie ze specyfikacją? Chciałbyś mieć taką nadzieję, ale czasami to po prostu nie będzie możliwe i będziesz musiał oznaczyć odchylenie od niemożliwego lub sprzecznego ze sobą specyfikacji.

I czy cały rozwój będzie wolny od błędów? Nigdy .

Ale po to jest KPI. Jest to coś, co można zmierzyć i za pomocą którego można śledzić wydajność i postęp.

Jeśli specyfikacje regularnie się zmieniają, nie ma formalnego procesu kontroli zmian, a środowiska są nieprzewidywalne, trudno będzie utrzymać tę liczbę na poziomie „bezbłędnym”. Ale to wyzwanie jest twoją pracą i jest to praca, którą, miejmy nadzieję, wykonasz całkiem dobrze - a nawet lepiej w przyszłym roku, gdy zdobędziesz więcej praktyki w zarządzaniu własnym smakiem chaosu twojej firmy.

Licznik pytanie: co KPI będzie Ci zaproponować dla programisty? To trudne. Wiele tego, co robimy, jest trudnych do zmierzenia.

Jeśli jest to opis zadania, nie martwiłbym się tym zbytnio, ponieważ praca nad kodem bezbłędnym jest częścią typowego zadania programisty (nawet jeśli nigdy go nie osiągniemy).

Jednak jako wskaźnik KPI jest zbyt daleko idący, ale nie obwiniaj osoby, która go zasugerowała, jeśli nie są programistami. Po prostu wyjaśnij, że to stwierdzenie wyznacza cel, który może być niepożądany dla organizacji. Oznacza to, że „bezbłędny” jest niezwykle wysokim standardem dla oprogramowania, które kosztowałoby fortunę w rzeczywistości. Wyjaśnij, że dobrze zarządzany projekt oprogramowania wymaga podjęcia decyzji, czy każda wada jest warta poświęcenia cennego czasu programistom.

Oto przykład, który ładnie to podkreśla.
Programista odkrywa, że ​​w naszym oprogramowaniu występuje błąd „roku 3000” i przestanie on działać po 31.2999 grudnia. Rozwiązanie problemu zajmie 6-8 miesięcy. W oparciu o KPI zachęca się do podjęcia tego projektu, mimo że nie ma on realnej wartości dla firmy.

Okej, więc ten przykład jest trochę ekstremalny, ale w każdym projekcie oprogramowania odkryje się dosłownie dziesiątki małych defektów, które podobnie nie generują ROI wymaganego do ich naprawy. Jeśli zamiast tego KPI miał sugerować, że programista nigdy nie wprowadza usterki, to czy wydaje się rozsądne, aby ŻADNY pracownik utrzymywał standard, aby nigdy nie popełniać błędu w wykonywaniu swojej pracy?

Nie

To nie tylko niewłaściwe, ale i absurdalne

Testy mogą tylko udowodnić istnienie błędów, a nie ich brak, dlatego każdy program napisany w ramach tego zlecenia musiałby zawierać rygorystyczny dowód poprawności ... i 100% pokrycia testowego

„Strzeż się błędów w powyższym kodzie; udowodniłem tylko, że jest poprawny, a nie wypróbowałem”. - D. Knuth

Oczywiście zadaniem i odpowiedzialnością każdego programisty jest pisanie kodu bezbłędnego. To całkowicie uzasadnione oczekiwanie. Jak możesz zostać profesjonalnym programistą, jeśli wydasz kod, który nie działa? Jak możesz uważać się za profesjonalnego programistę, jeśli wydajesz kod, o którym nie wiesz, że działa?

Jeśli zatrudnisz malarza, oczekujesz, że dobrze wykona swoją pracę. Oczekujesz, że wynik jego pracy będzie wolny od błędów. Jeśli wystąpią błędy, oczekujesz, że weźmie odpowiedzialność za te błędy i naprawi je bezpłatnie. Co więcej, jeśli błędy kosztują twoje pieniądze, oczekujesz, że zwróci ci pieniądze. Dlaczego masz takie oczekiwania? Ponieważ malarz jest profesjonalistą.

Programiści lubią obwiniać innych za swoje błędy. „Mój program ma błędy z powodu wymagań, harmonogramu lub Księżyca w ósmym domu”. Ale tak naprawdę nikogo innego nie można winić. Jeśli program ma błędy, wy je tam umieścić.

Nasz zawód nigdy nie będzie zawodem, dopóki programiści nie zdadzą sobie sprawy, że złotówka się z nimi skończy. Że one są odpowiedzialne za jakość swoich programów.

Czy wiesz, dlaczego firmy stworzyły działy kontroli jakości oprogramowania? Ponieważ programiści nie wykonywali swoich zadań! Programiści wydawali tak dużo bzdur, że firmy musiały tworzyć zupełnie nowe działy, aby je sprawdzić.

Jak długa jest lista błędów? Profesjonalnie jest mieć tysiące błędów w bazie danych błędów? Z całą pewnością tak nie jest. Jest to odbicie złego zachowania, złej dyscypliny i, szczerze mówiąc, hańby.

Nigdy nie będziemy zawodem, dopóki nie uświadomimy sobie, że naszym zadaniem jest upewnienie się, że QA niczego nie znajdzie.

Niestety, brzmi to po prostu dla nich sposób na „zakrycie wszystkich baz”, i wyraźnie nie jest to zalecane i może wywołać rozczarowanie wśród programistów.

Jednak powiedziawszy to, naprawdę ma to znaczenie tylko wtedy, gdy zobaczysz, co robią z tym tekstem w okresie przeglądu. Więc nie reaguj zbyt szybko - na końcu tunelu może być zdrowy rozsądek.

„Bezbłędnie” jak w „perfect?” Jak w „napisanym przez Boga i aniołów, a nie ludzi?” (mówimy tutaj o logice programu i być może błędach logiki sprzętowej)

Nie mogę rzetelnie powiedzieć nawet o jednym wierszu kodu, że jest bezbłędny. To dlatego, że my, ludzie, nie możemy udowodnić żadnych negatywnych hipotez!

Najlepsze, co mogę powiedzieć, to to, że prawdopodobieństwo błędu to liczba od 0 do 1. Osiągam tę liczbę poprzez dobrze lub źle zdefiniowane i źle lub źle zrozumiane zasady opracowywania i testowania oprogramowania; według liczby odnośnych linii oprogramowania źródłowego; rozumiejąc, jak dobrze lub słabo kandyduję, biedny kundel, stosuje te zasady przy tworzeniu tych wierszy kodu; i więcej.

I to zrozumienie mogę wyrazić jedynie jako prawdopodobieństwo. Zatem termin „bez błędów logicznych” oznacza prawie nic.

Gdybym zobaczył reklamę inżyniera oprogramowania, który wyprodukował „bezbłędny” kod, natychmiast zastosowałbym go lub od razu uciekłem: firma nie zastanawiała się zbytnio nad tym, jak się rozwija, testuje i dostarcza swoje oprogramowanie . Będzie to więc świetna okazja lub niekończący się koszmar.

Jednak z dowolnego oprogramowania mogę łatwo - i muszę - powiedzieć, że oczekuję kodu, który nie zawiera błędów wykraczających poza to podstępne, mętne, logiczne oczy: kod, który kompiluje się i łączy bez błędów lub ostrzeżeń; to jest „prawidłowy HTML” lub „prawidłowy css”; JavaScript (powiedzmy), który nie generuje niewyjaśnionych komunikatów o błędach lub błędów przeglądarki. Tę część mogę bezpośrednio zmierzyć i oznaczyć czarno-biało na wykresie.

Ta część jest łatwa jak ciasto. Każdy może zrobić to .

Hej, powodzenia w wyszukiwaniu :-)

Czy jestem głupi, czy „błąd” nie oznacza „fatalnego komunikatu kompilatora w postaci niekompilowalnego kodu”?

Według tej definicji jest to bardzo rozsądny wymóg ...