Jak zostać programistą bez błędów? [Zamknięte]

168

Mój szef zawsze mi mówił, że dobry programista powinien być w stanie zapewnić, że kod, który zmienia, jest niezawodny, poprawny i dokładnie weryfikowany; że powinieneś całkowicie zrozumieć wszystkie wyniki i skutki, jakie spowodują twoje zmiany. Starałem się jak najlepiej być programistą - testując raz za razem - ale błędy nadal występują.

Jak mogę być programistą bez błędów i wiedzieć, co spowoduje każda postać mojego kodu i na co wpłynie?

8
źródło
Za pierwszym razem nikt tak naprawdę nie tworzy idealnego kodu, oprócz mnie. Ale jest tylko jeden ze mnie. - Dyskusja techniczna: Linus Torvalds na git, Google, 15 sierpnia 2007 izquotes.com/quote/273558
JensG
Nie ma czegoś takiego jak programowanie bez błędów. Przeczytaj matematyka Godela, aby zrozumieć, dlaczego.
Michael Martinez,

Odpowiedzi:

365

W ogóle nie koduj.

Tylko w ten sposób możesz zostać programistą bez błędów.

Błędy są nieuniknione, ponieważ programiści są ludźmi, wszystko, co możemy zrobić, to starać się im zapobiegać, szybko reagować w przypadku wystąpienia błędu, uczyć się na błędach i być na bieżąco.

dzikie piki
źródło
73
+1 Kontynuacja: Albo możesz zostać niekodującym architektem (wieża z kości słoniowej) i nadal otrzymywać dużo pieniędzy! To jest najlepsze.
Martin Wickman
26
Błędem jest ludzkie, naprawić boskie błędy.
Ward Muylaert
11
Miałem kiedyś współpracownika, który był faworyzowany przez szefa, ponieważ konsekwentnie miała małą liczbę błędów. Jak ona to zrobiła? Proste, przypisała błędy, których nie chciała, komuś innemu i zawsze przyjmowała najłatwiejsze / najmniejsze funkcje.
toby
46
Nie wiem, kto pierwszy to powiedział, ale „Jeśli debugowanie polega na usuwaniu błędów, programowanie musi być procesem ich wprowadzania”.
Bruce Alderman
8
Jeszcze lepiej: zostań szefem i spraw, aby twoi podwładni czuli się nieszczęśliwi, bez konieczności brania odpowiedzialności za cokolwiek.
biziclop 30.01.11
124

Zero błędów jest niemożliwe w nietrywialnym programie.

Można się zbliżyć, ale wydajność spada. I jest to opłacalne tylko w przypadku niektórych programów wysokiego ryzyka. Oprogramowanie Space Shuttle przychodzi mi do głowy. Ale ich wydajność jest rzędu kilku linii dziennie. Wątpię, żeby twój szef tego chciał.

To oprogramowanie jest wolne od błędów. Jest doskonały, tak doskonały, jak to osiągnęli ludzie. Rozważ te statystyki: w trzech ostatnich wersjach programu - każda o długości 420 000 linii - wystąpił tylko jeden błąd. Ostatnie 11 wersji tego oprogramowania zawierało 17 błędów.

Podejmij aktualizację oprogramowania, aby umożliwić wahadłowiecowi nawigację z satelitami Global Positioning Satellites, zmiana obejmująca zaledwie 1,5% programu lub 6 366 linii kodu. Specyfikacje tej zmiany obejmują 2500 stron, o objętości większej niż książka telefoniczna. Specyfikacje dla bieżącego programu zajmują 30 woluminów i obejmują 40 000 stron.

CodesInChaos
źródło
3
Niemożliwe. Ale bardzo mało prawdopodobne.
Billy ONeal 30.01.11
36
Co sprawia, że ​​myślisz, że FB nie zawiera błędów? Model bezpieczeństwa i prywatności Facebooka to jeden wielki błąd. Na przykład konto Facebook szefów Facebooka zostało zhakowane w zeszłym tygodniu z powodu słabości bezpieczeństwa.
Stephen C
6
@Elaine Filozofią Facebooka jest „idź szybko i psuj rzeczy” ( geek.com/articles/news/… ) i mieli niezliczone błędy ( facebook.com/board.php?uid=74769995908 ), w tym wiele, które uruchomiłem w siebie. Twitter nie jest inny, znany z tego, że często nie działa ( engineering.twitter.com/2010/02/anatomy-of-whale.html ) i błędów, takich jak „follow bug” ( status.twitter.com/post/587210796/... ).
Jewgienij Brikman
9
Nie zapomnij o ruchomych słupkach bramki. Funkcja w twoim PerfectProgramie 1.0 może być błędem w wersji 2.0
Carlos
4
@CodesInChaos: Teoria mówi, że istnieją programy, dla których niemożliwe jest udowodnienie ich zachowania. Nie mówi, że nie można udowodnić zachowania wszystkich programów. Domyślam się, że większość popularnych programów jest typu możliwego do udowodnienia, a twierdzenie: „Mój kod nie jest wolny od błędów z powodu problemu zatrzymania” jest błędnym zastosowaniem teorii.
endolith
98

„Zero-bug programmer” to oksymoron, jak cichy piosenkarz, ale w ciągu ostatnich 60 lat programowanie przyniosło pewne destylowane fragmenty mądrości, które uczynią cię lepszym programistą, takim jak:

  • Bądźcie pokorni - jesteście i będziecie popełniać błędy. Wielokrotnie.
  • Bądź w pełni świadomy ograniczonego rozmiaru twojej czaszki. Podejdź do zadania z pełną pokorą i unikaj sprytnych sztuczek, takich jak zaraza. [Edsger Dijkstra]
  • Walcz z eksplozją kombinatoryczną
  • Pozbądź się stanu zmiennego (tam, gdzie to możliwe). Tak, naucz się programowania funkcjonalnego.
  • Zmniejsz liczbę możliwych ścieżek kodu
  • Zrozum (wielkość) wielkości przestrzeni wejściowej i wyjściowej (swoich funkcji) i spróbuj je zmniejszyć, aby zbliżyć się do 100% zasięgu testu
  • Zawsze zakładaj, że Twój kod nie działa - udowodnij, że jest inaczej!
Maglob
źródło
2
Z przyjemnością udowodnię, że mój kod działa ... ale testy mogą tylko udowodnić, że tak nie jest. Mówisz tutaj o formalnym dowodzie lub planujesz zadanie debugowania?
Matthieu M.
Pierwsza przydatna odpowiedź w tym wątku. @ Matthieu: Możesz udowodnić dla każdej możliwej kombinacji dwóch bajtów, że funkcja zwróci poprawny wynik (na przykład: max), który jest bajtem ponownie. Możesz mieć dwie i więcej takich funkcji, a teraz możesz je połączyć i uzyskać dużą liczbę możliwych kombinacji takich funkcji, które ponownie wygenerują tylko bajt. Pomysł, że możesz tylko udowodnić, że coś jest nie tak, jest zły. Popularny, ale zły.
użytkownik nieznany
@Matthieu M .: Testowanie dowodzi, że wszystko działa zgodnie z oczekiwaniami. Jeśli możesz udowodnić, że wszystkie elementy działają zgodnie z oczekiwaniami, stamtąd dowiadujesz się, że masz do czynienia z zachowaniem wejściowym, którego się nie spodziewałeś. Po ustaleniu, co to jest i jakie powinno być, piszesz dla niego nowy test. To teraz część oczekiwanego zachowania.
deworde
1
@deworde: Rozumiem pomysł testowania, jednak poza niszowymi sytuacjami większość prawdziwej pracy, którą wykonałem, nie mogła zostać wyczerpująco przetestowana, po prostu dlatego, że możliwa liczba kombinacji była zbyt duża (i nawet nie dodam problemy z synchronizacją). Poza sytuacjami niszowymi testy idą jednak tak daleko (nadal warto sprawdzić, czy przynajmniej nominalna liczba przypadków się udała!)
Matthieu M.,
„unikaj sprytnych sztuczek, takich jak plaga” - to samo dałoby dobrą odpowiedź. Tak jak jest - jest świetnie.
BЈовић
25

TDD

Chodzi o to, że TDD nie pisze jednego wiersza kodu, jeśli nie ma testu wymagającego tego wiersza kodu. Aby osiągnąć maksymalny poziom, zawsze zaczynasz opracowywać nową funkcję, pisząc test akceptacyjny. Przekonałem się, że pisanie testów w stylu ogórka jest idealne.

Podejście TDD daje co najmniej dwie korzyści.

  • Cały kod jest napisany w celu rozwiązania określonej funkcji, dzięki czemu nie ma niepotrzebnej nadprodukcji.
  • Za każdym razem, gdy zmienisz istniejący wiersz kodu, jeśli złamiesz funkcję, zostaniesz o tym powiadomiony

Nie dowodzi zero błędów, ponieważ byłoby to niemożliwe (zostały już wskazane przez niezliczone inne odpowiedzi). Ale po tym, jak nauczyłem się TDD i stałem się w tym dobry (tak, jest to także umiejętność, która wymaga praktyki), mam znacznie większe zaufanie do własnego kodu, ponieważ jest on dokładnie testowany. Co ważniejsze, mogę zmienić istniejący kod, którego nie rozumiem całkowicie, nie martwiąc się o zerwanie funkcjonalności.

Ale TDD nie pomaga ci całkowicie. Nie możesz napisać kodu wolnego od błędów, jeśli nie rozumiesz dokładnie architektury systemu i pułapek tej architektury. Na przykład, jeśli piszesz aplikację internetową, która obsługuje wiele żądań jednocześnie, musisz wiedzieć, że nie możesz udostępniać zmiennych danych między wieloma żądaniami (nie wpadnij w pułapkę dla początkujących, aby buforować zmienne dane w celu zwiększenia wydajności).

Uważam, że zespoły programistów, które są dobre w TDD, dostarczają kod z najmniejszą liczbą wad.

Pete
źródło
19

Chodzi o to, że błędy to rzeczy, których nie rozpoznajesz. Jeśli nie masz encyklopedycznej wiedzy na temat języka programowania / kompilatora, a także wszystkich środowisk, w których będzie działać Twoja aplikacja, naprawdę nie możesz oczekiwać, że stworzysz w 100% wolny od błędów kod.

Możesz zmniejszyć liczbę błędów przez wiele testów, ale w końcu prawdopodobnie pojawi się trochę marginesu, który nie zostanie uwzględniony. Joel Spolsky napisał szczególnie fajny artykuł na temat naprawiania błędów .

użytkownik7007
źródło
1
+1. Słowami Twisted Sister: To, czego nie wiesz na pewno, może cię zranić / To, czego nie widzisz, powoduje, że krzyczysz.
Inżynier
17

Tak, nigdy nie ma błędu w kodzie, ale nie jest mniej błędów. Postawa, że ​​„To głupie, zawsze będziesz mieć błędy” jest po prostu policjantem, aby uniknąć zmniejszenia liczby błędów w kodzie. Nikt nie jest doskonały, ale możemy i powinniśmy starać się być lepsi. W moich własnych wysiłkach na rzecz poprawy znalazłem następujące punkty pomocne.

  • To nie jest łatwe. Nie poprawisz się w ciągu nocy. Więc nie zniechęcaj się i nie poddawaj się.
  • Pisz mniej i pisz mądrzej. Mniej kodu to zazwyczaj lepszy kod. To naturalne, że chcesz planować z wyprzedzeniem i próbować tworzyć niesamowite wzorce projektowe, ale na dłuższą metę pisanie tego, czego potrzebujesz, oszczędza czas i zapobiega błędom.
  • Złożoność jest wrogiem. Mniej nie liczy się, jeśli jest to niejasny, skomplikowany bałagan. Code golf jest fajny, ale piekło jest zrozumiałe, a gorsze - do debugowania. Ilekroć piszesz skomplikowany kod, otwierasz się na świat problemów. Spraw, by wszystko było proste i krótkie.
  • Złożoność jest subiektywna. Kod, który kiedyś był skomplikowany, staje się prosty, gdy stajesz się lepszym programistą.
  • Doświadczenie ma znaczenie. Jednym z dwóch sposobów, aby stać się lepszym programistą, jest ćwiczenie. Praktyka to NIE pisanie programów, które umiesz pisać z łatwością, to pisanie programów, które trochę ranią i sprawiają, że myślisz.
  • Innym sposobem na poprawę jest czytanie. Do nauczenia się programowania jest wiele trudnych tematów, ale nigdy nie będziesz w stanie się ich nauczyć poprzez programowanie, musisz je przestudiować. Musisz przeczytać trudne rzeczy. Rzeczy takie jak bezpieczeństwo i współbieżność są niemożliwe, uczy się poprawnie po prostu pisząc kod, chyba że chcesz się uczyć poprzez usuwanie katastrof. Jeśli nie wierzysz mi, spójrz na epickie problemy bezpieczeństwa, takie jak gawker. Gdyby poświęcili czas, aby nauczyć się, jak prawidłowo robić bezpieczeństwo, a nie tylko zrobić coś, co zadziałałoby, bałagan nigdy by się nie wydarzył.
  • Czytaj blogi. Istnieje mnóstwo interesujących blogów, które dadzą ci nowe i ciekawe sposoby patrzenia i myślenia o programowaniu, które pomogą ci ...
  • Naucz się brudnych szczegółów. Bardzo ważne są drobne szczegóły dotyczące tego, jak niejasne są części twojego języka i aplikacji. Mogą utrzymywać tajemnice, które pomogą ci uniknąć pisania skomplikowanego kodu lub mogą zawierać części, które zawierają własne błędy, których musisz unikać.
  • Dowiedz się, jak myślą użytkownicy. Czasami Twoi użytkownicy są całkowicie szaleni i będą pracować z Twoją aplikacją w sposób, którego nie rozumiesz i nie możesz przewidzieć. Musisz dotrzeć do ich głowy na tyle, aby poznać dziwniejsze rzeczy, które mogą spróbować, i upewnić się, że Twoja aplikacja sobie z tym poradzi.
AmaDaden
źródło
8

Osobiście uważam, że dążenie do programowania bez błędów wydaje się droższe (zarówno pod względem czasu, jak i pieniędzy). Aby osiągnąć błąd zero, a nawet błąd prawie zerowy, musisz dokładnie przetestować programistę. Oznacza to, że regresja przetestuje wszystko przed przesłaniem kodu do przeglądu poprawek. Ten model nie wydaje mi się opłacalny. Lepiej jest, gdy programiści przeprowadzą rzetelne testy i pozostawią szczegółowe testy zespołowi ds. Kontroli jakości. Oto dlaczego:

  • Programiści są do dupy podczas testowania. To prawda i wiesz o tym. (Jestem programistą!) Dobry zespół ds. Kontroli jakości zawsze znajdzie najlepsze przypadki, o których programiści nigdy nie myślą.
  • Programiści są dobrzy w kodowaniu. Pozwól im wrócić do tego, w czym się wyróżniają (i zwykle do tego, co wolą robić).
  • Zespół kontroli jakości może znaleźć błędy związane z wieloma zadaniami programisty w jednym przebiegu.

Zaakceptuj, że podczas pisania kodu będą rejestrowane błędy. Właśnie dlatego masz proces kontroli jakości, a wszystko to jest częścią bycia programistą. Oczywiście nie oznacza to, że przesyłasz coś, gdy tylko napiszesz swój ostatni średnik. Trzeba jeszcze zapewnić jakość w swojej pracy, ale można przesadzić.

Ile zawodów możesz wymienić, które zawsze wykonują swoje zadanie za pierwszym razem bez recenzji i / lub testowania?

Sebastien Martin
źródło
8

Zero błędów? Wygląda na to, że potrzebujesz Lispa (podążaj sceptyczną ścieżką i unikaj teledysku).

Niezwykle trudno jest uzyskać wolny od błędów kod w głównych środowiskach programistycznych (Java, C #, PHP itp.). Skoncentrowałbym się na tworzeniu dobrze przetestowanego i recenzowanego kodu w krótkich kontrolowanych iteracjach.

Utrzymanie kodu tak prostego, jak to tylko możliwe , pomoże ci uniknąć błędów.

Upewnij się, że korzystasz z narzędzi do analizy kodu (takich jak FindBugs , PMD itd.), Które - w połączeniu ze ścisłymi ostrzeżeniami kompilatora - ujawnią wszelkiego rodzaju problemy z kodem. Zwróć uwagę na to, co ci mówią, naprawdę staraj się zrozumieć naturę błędu, a następnie podejmij kroki, aby zmienić idiom programistyczny, aby kod był nienaturalny w sposób, który ponownie wprowadza ten błąd.

Gary Rowe
źródło
3
Czasami robaki są jak żyjące tam ukryte potwory, chowają się podczas moich wielokrotnych testów i weryfikacji własnego kodu ... ale kiedy dokonałem przeglądu, zauważyłem, że potwory były niewiarygodnie widoczne i nagle wyskoczyły do ​​mnie. To naprawdę dziwne. W zależności od ludzkiego „oka” i „mózgu” wydaje się niemożliwe dotknięcie linii wolnej od błędów. test jednostkowy nie jest wykonalny we wszystkich przypadkach. Narzędzia do analizy kodu? brzmi ekscytująco, nigdy tego nie użyłem, będę prowadził badania w tej dziedzinie.
Elaine
Powiedziałbym, że potrzebujesz Ady, ale Lisp jest bardziej zabawny. ;-)
Orbling 30.01.11
1
@Elaine Tam, gdzie pracuję, jest środowisko Java, a kod może być udostępniany zespołowi tylko wtedy, gdy przeszedł przez Findbugs i PMD. Nowi członkowie zespołu przechodzą pięć etapów: zaprzeczenie, gniew, targowanie się, depresja, a następnie akceptacja. Potem nigdy nie oglądają się za siebie.
Gary Rowe,
@ Gary Rowe, rozumiem te reakcje, lol, kiedykolwiek byłem w firmie, gdzie był dział kontroli jakości. Pracownicy tam co tydzień sprawdzali wszystkie kody wyprodukowane w tym tygodniu, aby sprawdzić, czy wszystkie wiersze kodu są zgodne z regułą „ „(Nie mam pojęcia, czy korzystali z niektórych narzędzi, takich jak Findbugs / PMD), ale brzmi to trochę jak krok, w którym się znajdujesz.
Elaine
1
@Gary: Żadnych argumentów ode mnie, ale w kilku miejscach, w których pracowałem, naruszenia stylu traktują jak odpowiedniki błędów. I zwykle mieli reguły stylu, takie jak: „każda klasa musi deklarować pola statyczne CLS_PKG i CLS_NAME, które zawierają nazwy pakietów i klas”. Zasadniczo popieram standardy kodowania, ale nie kiedy zmieniają się w takie rzeczy!
TMN
8

Wszystkie „W ogóle nie koduj”. odpowiedzi zupełnie nie mają sensu. Ponadto twój szef zdecydowanie nie wydaje się kretynem!

Nie pamiętam, jak często widziałem programistów, którzy po prostu nie wiedzieli, co robi ich kod. Ich jedyna filozofia rozwoju wydawała się metodą prób i błędów (i często także kopiowania / wklejania / modyfikowania). Chociaż metoda prób i błędów jest dobrym sposobem na rozwiązanie niektórych problemów, często możesz przeanalizować domenę problemu, a następnie zastosować bardzo konkretne rozwiązanie w oparciu o Twoją wiedzę na temat używanych narzędzi oraz przy odrobinie dyscypliny i staranności, których nie będziesz mieć rozwiązał problem, ale także większość przypadków narożnych (potencjalne błędy) przed jego wdrożeniem po raz pierwszy. Czy możesz zagwarantować, że kod jest wolny od błędów? Oczywiście nie. Ale z każdym napotkanym lub przeczytanym błędem możesz dodać go do rzeczy, o których możesz pomyśleć następnym razem, gdy coś napiszesz / zmienisz. Jeśli to zrobisz, zyskasz duże doświadczenie w pisaniu kodu, który jest prawie wolny od błędów. - Istnieje mnóstwo zasobów, w jaki sposób stać się lepszym programistą, który może pomóc w podróży ...

Osobiście nigdy nie zatwierdziłbym kodu, w którym nie mogę wyjaśnić każdej linii. Każda linia ma powód, aby tam być, w przeciwnym razie należy ją usunąć. Oczywiście czasami przyjmujesz założenia wewnętrznego działania metod, które nazywasz, w przeciwnym razie musiałbyś znać wewnętrzną logikę całego frameworka.

Twój szef ma całkowitą rację mówiąc, że powinieneś zrozumieć wyniki i wpływ kodu, który piszesz na istniejący system. Czy pojawią się błędy? Tak oczywiście. Te błędy będą jednak spowodowane niepełnym zrozumieniem systemu / narzędzi, z którymi pracujesz, a każda poprawka zapewni lepszy zasięg.

Patrick Klug
źródło
„z każdym napotkanym błędem lub o nim czytającym możesz dodać go do rzeczy, o których możesz pomyśleć następnym razem, gdy coś napiszesz / zmienisz” - to świetna kwestia. W tym celu stworzyłem dokument Google związany z błędami, które widziałem lub kodowałem.
Ben,
7

Jak już poprawnie zauważyły ​​inne komentarze, nie ma trywialnego oprogramowania bez błędów.

Jeśli chcesz przetestować oprogramowanie, zawsze pamiętaj, że testy te mogą jedynie udowodnić obecność błędów, a nie ich brak.

W zależności od dziedziny pracy możesz spróbować formalnej weryfikacji oprogramowania. Za pomocą metod formalnych możesz być całkiem pewien, że twoje oprogramowanie dokładnie spełnia specyfikację.

Oczywiście nie oznacza to, że oprogramowanie robi dokładnie to, co chcesz. Napisanie kompletnej specyfikacji jest w prawie wszystkich przypadkach również niemożliwe. Zasadniczo zmienia miejsce, w którym mogą wystąpić błędy z implementacji na specyfikację.

Dlatego w zależności od definicji „błędów” możesz spróbować formalnej weryfikacji lub po prostu znaleźć tyle błędów, ile możesz w swoim oprogramowaniu.

FabianB
źródło
6

Nie pisz nic bardziej skomplikowanego niż „Hello World!” lub jeśli powiesz każdemu, aby nigdy go nie używał.

Zapytaj swojego szefa o kilka przykładów tego tak zwanego kodu wolnego od błędów.

JeffO
źródło
5

Zgadzam się z pozostałymi. Oto jak podejdę do problemu

  • Zdobądź testera. Zobacz dlaczego test Joela.
  • Używaj bibliotek w szerokim zakresie; prawdopodobnie zostały lepiej debugowane. Jestem wielkim fanem CPAN dla Perla.
Brian Carlton
źródło
1
… Ale jeśli korzystasz z bibliotek, upewnij się, że ich błędy nie mogą cię przeciągnąć w dół (na przykład poprzez posiadanie źródła, abyś mógł je skontrolować lub naprawić błędy, jeśli zajdzie taka potrzeba).
millenomi 30.01.11
5

Możesz starać się być programistą zero błędów. Staram się być programistą zero błędów, kiedy piszę kod. Jednak ja nie

  • stosować wiele technik testowania (inne niż ATDD)
  • tworzyć formalne weryfikacje naszego oprogramowania
  • mieć osobny zespół kontroli jakości
  • wykonaj dokładną analizę każdej zmiany dokonanej w bazie kodu
  • używaj języka, który skłania się bardziej w kierunku bezpieczeństwa i ostrożności

Nie robię tych rzeczy, ponieważ są one kosztowne dla oprogramowania, które piszę. Gdybym to zrobił, prawdopodobnie byłbym bardziej w kierunku zerowych błędów, ale nie miałoby to sensu biznesowego.

Tworzę narzędzia wewnętrzne, z których korzysta duża część naszej infrastruktury. Moje standardy testowania i kodowania są wysokie. Istnieje jednak równowaga. Nie oczekuję zero błędów, ponieważ nie mogę pozwolić, aby ludzie poświęcali tyle czasu na jedną pracę. Mogłoby być inaczej, gdybym tworzył oprogramowanie do sterowania aparatem rentgenowskim, silnikami odrzutowymi itp. Brak życia na linii, jeśli moje oprogramowanie się psuje, więc nie angażujemy się w ten poziom pewności.

Dopasowałbym poziom pewności do zamierzonego użytkowania oprogramowania. Jeśli piszesz kod, że wahadłowiec NASA użyje być może zerowa tolerancja na błędy jest rozsądna. Wystarczy dodać kilka dodatkowych i bardzo drogich praktyk.

dietbuddha
źródło
4

Myślę, że dobrym pierwszym krokiem do zostania programistą „zero błędów” jest zmiana twojego podejścia do błędów. Zamiast mówić „rzeczy się zdarzają”, „uzyskać lepszą kontrolę jakości i testerów” lub „programiści są do dupy podczas testów”, powiedz:

Błędy są niedopuszczalne i zrobię wszystko, co w mojej mocy, aby je wyeliminować.

Gdy stanie się to twoją postawą, błędy będą szybko spadać. Poszukując sposobów na wyeliminowanie błędów, natkniesz się na rozwój oparty na testach. Znajdziesz mnóstwo książek, postów na blogu i ludzi oferujących bezpłatne porady na temat lepszych technik. Przekonasz się, jak ważne jest doskonalenie umiejętności poprzez ćwiczenie (np. Kodowanie katas lub wypróbowywanie nowych rzeczy w domu). Zaczniesz osiągać lepsze wyniki w pracy, ponieważ zaczniesz pracować nad swoim rzemiosłem w domu. I miejmy nadzieję, że kiedyś zobaczysz, że jest możliwe, aby napisać dobry program, swoją pasję do rzemiosła wzrośnie.

Darren
źródło
2

W pewnym sensie twój szef ma rację. Możliwe jest pisanie oprogramowania zbliżającego się do zerowych błędów.

Problem polega jednak na tym, że koszt pisania (prawie) programów z zerowym błędem jest zbyt wysoki . Musisz robić takie rzeczy jak:

  • Użyj formalnych specyfikacji swoich wymagań. Formalny, jak w przypadku użycia Z lub VDM lub innej matematycznie poprawnej notacji.

  • Użyj technik dowodzenia twierdzeń, aby formalnie udowodnić, że Twój program implementuje specyfikację.

  • Twórz rozbudowane pakiety testów i uprzęży do testowania jednostek, regresji i systemu w celu testowania wszystkich błędów. (I to samo w sobie nie wystarczy.)

  • Poproś wiele osób o sprawdzenie wymagań (formalnych i nieformalnych), oprogramowania (i dowodów). testy i wdrożenia.

Jest bardzo mało prawdopodobne, że twój szef jest gotów zapłacić za to wszystko ... lub znieść tyle czasu, ile potrzeba na zrobienie tego wszystkiego.

Stephen C.
źródło
1

Osiągnąłem status „zero błędów”. Mówię moim użytkownikom, że jest to funkcja nieudokumentowana lub prosi o nową funkcję, dlatego jest to ulepszenie. Jeśli żadna z tych odpowiedzi nie jest akceptowana, mówię im tylko, że nie zrozumieli swoich własnych wymagań. Dlatego nie ma błędów. Programiści są idealni.

Giulio
źródło
1

Oto kroki, aby utworzyć program bez błędów:

  1. Nigdy nie zaczynaj kodowania, chyba że masz NIEZBĘDNE SPECYFIKACJE dotyczące swojej funkcjonalności.
  2. NIE TESTUJ lub jeśli NIE TAM OPIERAJESZ TESTOWANIA w celu wykrycia wad oprogramowania.
  3. Zastosuj wszystkie INFORMACJE ZWROTNE od wad wykrytych podczas testowania, przeglądów i produkcji do procesu i programistów, którzy umieścili defekt na pierwszym miejscu. Wszystkie wadliwe elementy należy całkowicie wyrzucić, gdy tylko zostaną wykryte usterki. Zaktualizuj listy kontrolne i przekwalifikuj programistów, aby nie popełnili już takich błędów.

Testowanie może tylko udowodnić, że masz błędy, ale zwykle nie ma sensu dowodzić, że jest inaczej. Jeśli chodzi o opinie - jeśli masz maszynę do robienia monet, która wytwarza monety, a średnio co 10 monet ma wadę. Możesz wziąć tę monetę, spłaszczyć ją i włożyć do urządzenia. moneta, która wykazała, że ​​ślepej próby z recyklingu nie będzie tak dobra, ale być może do przyjęcia. każda 100s moneta będzie musiała być ponownie stemplowana 2 razy i tak dalej. Czy łatwiej byłoby naprawić maszynę?

Niestety ludzie nie są maszynami. Aby stworzyć dobrego, wolnego od wad programistę, musisz zainwestować dużo czasu, szkolenia i iteracji nad każdą popełnioną wadą. Programiści muszą zostać przeszkoleni w zakresie formalnych metod weryfikacji, które często są trudne do nauczenia się i zastosowania w praktyce. Przeciwdziała temu także ekonomia tworzenia oprogramowania - czy zainwestowałbyś 2 lata w szkolenie programisty, który może robić mniej wad, aby zobaczyć, jak przeskakuje do innego pracodawcy? Możesz kupić maszynę, która tworzy idealne monety, lub wynająć 10 dodatkowych małp kodowych, aby stworzyć zestaw testów przy tej samej cenie. Możesz postrzegać ten wyczerpujący proces jako swoją „maszynę”, swój atut - inwestowanie w kompleksowe szkolenie doskonałych programistów nie opłaca się.

Już niedługo nauczysz się tworzyć oprogramowanie o akceptowalnej jakości, ale prawdopodobnie nigdy nie będziesz tym, który jest wolny od wad z prostego powodu, że nie ma rynku dla programistów tworzących doskonały kod, ponieważ jest on powolny.

Aleksiej Polhanow
źródło
+1 za wzmiankę o jednoznacznych specyfikacjach. Wiem, że to dwuletni temat, ale muszę podkreślić, że twoja jedyna odpowiedź wskazuje, że błędem jest zakładanie, że błąd jest równoznaczny z niepowodzeniem programowania.
Brandon
0

Program defensywnie: http://en.wikipedia.org/wiki/Defensive_programming

Jeśli ktoś postępuje zgodnie z konwencjami programowania w obronie, zmiany będą łatwe do zidentyfikowania. Połącz to z rygorystycznymi raportami błędów podczas programowania i rzetelną dokumentacją, taką jak doxygen, i powinieneś być w stanie dokładnie wiedzieć, co robi cały twój kod, i naprawiać wszelkie pojawiające się błędy, bardzo skutecznie.

Jason McCarrell
źródło
0

Czy może to wynikać z niezrozumienia dobrej metodologii, a nie tylko ogólnej bezmyślności?

Mam na myśli to, że możliwe jest, że twój szef słyszał o „metodologii zerowej wady” (patrz sekcja nr 5) i nie zadał sobie trudu zrozumienia, co to znaczy?
Oczywiście, niewygodne dla kierownictwa jest odkładanie rozwoju nowych funkcji, na korzyść błędów, których nie powinieneś wprowadzać ...
I oczywiście zagraża to jego premii, więc oczywiście nie dostaniesz takiej, ponieważ „dobrzy programiści nie mieć błędy ”...

Dobrze jest robić błędy, o ile można je znaleźć i naprawić (oczywiście w granicach rozsądku).

Zachłanny
źródło
0

Jedną z podstawowych koncepcji testowania oprogramowania jest to, że NIGDY nie można być absolutnie pewnym, że program jest doskonały. Możesz go zweryfikować na zawsze, ale to nigdy nie dowodzi, że program jest kompletny, ponieważ szybko staje się niemożliwy do przetestowania nawet dla wszystkich kombinacji danych wejściowych / zmiennych.

Twój szef wydaje się być jednym z tych, którzy „nie rozumieją, co jest tak trudnego w programowaniu, ponieważ po prostu pisze”

SpacePrez
źródło
0

Jeśli założymy, że duże domy oprogramowania wiedzą, jak zdobyć najlepszych programistów (jak w programatorze zero błędów ), możemy wywnioskować, że oprogramowanie Microsoftu musi być bez błędów. Wiemy jednak, że to dalekie od prawdy.

Opracowują swoje oprogramowanie, a gdy osiągną pewien poziom błędów o niskim priorytecie, po prostu wypuszczają produkt i rozwiązują je później.

O ile nie opracujesz czegoś bardziej złożonego niż prosty kalkulator, nie da się uniknąć błędów razem. Do diabła nawet NASA ma nadmiarowość swoich pojazdów i błędów. Chociaż mają one bardzo rygorystyczne testy w celu uniknięcia katastrofalnych awarii. Niemniej jednak nawet oni mają błędy w swoim oprogramowaniu.

Błędy są nieuniknione, podobnie jak ludzka natura do popełnienia błędu.

Brak błędów jest jak 100% bezpieczny system. Jeśli system jest w 100% bezpieczny, zdecydowanie nie jest już przydatny (prawdopodobnie leży w tonach betonu i tonach betonu i nie jest w ogóle podłączony do zewnątrz. Nie jest przewodowy ani bezprzewodowy. Tak jak nie ma idealnie bezpiecznego systemu , nie ma złożonego systemu bez błędów.

Robert Koritnik
źródło
-1

Widzę tylko odpowiedzi na to, że jesteśmy ludźmi i skłonni do błędów, co jest bardzo prawdziwe ... ale widzę twoje pytanie z innego punktu widzenia.

Myślę, że możesz pisać programy wolne od błędów, ale zazwyczaj są to programy, które napisałeś już 10 lub 12 razy. Kiedy piszesz ten sam program od zera, już wiesz, jak to zrobić: znasz problem, znasz techniki, znasz biblioteki, język ... widzisz to w swoim umyśle. Wszystkie wzory są na wszystkich poziomach.

Zdarza mi się to z bardzo prostymi programami, ponieważ uczę programowania. Są dla mnie proste, ale trudne dla studentów. I nie mówię o rozwiązaniach problemów, które robiłem wiele, wiele razy na tablicy. Oczywiście, że je znam. Mam na myśli ~ 300-liniowe programy, które rozwiązują coś za pomocą pojęć, które znam naprawdę dobrze (pojęć, których uczę). Piszę te programy bez planowania, a one po prostu działają i czuję, że znam wszystkie szczegóły, w ogóle nie potrzebuję TDD. Dostaję kilka lub trzy błędy kompilacji (głównie literówki i inne podobne rzeczy) i to wszystko. Mogę to zrobić dla małych programów, a także wierzę, że niektórzy ludzie mogą to zrobić dla bardziej skomplikowanych programów. Myślę, że ludzie tacy jak Linus Torvalds lub Daniel J. Bernstein mają taką jasność umysłu, że są najbliżej bezbłędnego kodera. Jeśli tyrozumiem rzeczy głęboko. Myślę, że możesz to zrobić. Mogę to zrobić tylko dla prostych programów, tak jak powiedziałem.

Wierzę, że jeśli zawsze spróbujesz robić programy, które są znacznie powyżej twojego poziomu (spędziłem lata, robiąc to tylko), będziesz zdezorientowany i popełnisz błędy. Wielkie błędy, takie jak te, w których nagle zdajesz sobie sprawę, że twoje rozwiązanie nie może działać, kiedy w końcu zrozumiesz problem i musisz wprowadzić zmiany tak skomplikowane, że mogą powstrzymać cię od rozwiązania problemu lub uczynić kod okropnym. Uważam, że TDD dotyczy tych przypadków. Wiesz, że nie mylisz się z problemem, z którym się zmierzysz, dlatego też wszędzie stawiaj testy, aby upewnić się, że masz silną bazę. TDD nie rozwiązuje jednak widzenia na 10 000 stóp. Możesz chodzić w kółko z idealnie czystym kodem przez cały czas.

Jeśli jednak spróbujesz zrobić coś nowego, ale nieco powyżej poziomu, możesz uzyskać doskonały lub prawie idealny program. Myślę, że naprawdę trudno jest wiedzieć, jakie programy znajdują się na „granicy wiedzy”, ale teoretycznie jest to najlepszy sposób na naukę. Właściwie często przepisuję programy od zera. Niektórzy tak robią, ale potrzebujesz dużo czasu i cierpliwości, ponieważ za trzecim razem, gdy powtórzysz nietrywialny program, nie ekscytujesz się tak jak za pierwszym razem.

Moja rada jest następująca: nie myśl, że coś rozumiesz, dopóki nie możesz napisać programu bezbłędnego tylko do tego. A następnie spróbuj połączyć dwie z tych koncepcji, które znasz głęboko w ten sam program. Jestem prawie pewien, że uda ci się to zrobić za pierwszym razem. Jednym z najlepszych sposobów jest przepisanie nietrywialnego oprogramowania, co za pierwszym razem wymagało wiele wysiłku (teraz robię to z aplikacjami na Androida). Za każdym razem, gdy zaczynam od nowa, zmieniam coś lub dodaję coś, tylko po to, aby dodać trochę zabawy, i mogę ci powiedzieć, że jestem coraz lepszy i lepszy ... może nie jest wolny od błędów, ale naprawdę dumny.

Pau Fernández
źródło
-1

Błędy imho i nagłe tajemnicze artefakty algorytmu muszą pojawić się podczas procesu kodowania: inspirują i wymuszają ewolucję kodu.
jednak możliwe jest (zwykle po pewnych testach) sprawdzenie każdej zmiennej, która może być użyta przed deklaracją, aby obsłużyć każdy błąd, gdziekolwiek się pojawi - aby program nie powodował błędu ... aż do otrzymania prośby o funkcję, która została rozważona niemożliwe podczas omawiania architektury programu;)

www0z0k
źródło
1
Nie wiem - brzmi to jak mistyczne podejście do programowania, które jest wyraźnie nie-mistycznym polem działań. Nie programujesz skutecznie metodą prób i błędów lub za pomocą wróżki. Projektujesz rzeczy celowo. A błędy będą się pojawiać. Więc je naprawisz. Ale przede wszystkim celowo projektujesz swój kod, aby nie zawierał błędów.
Craig
-1

Może pomyśl więcej o naturze błędów, które otrzymujesz. Jeśli błędy są z reguły drobnymi niedopatrzeniami, pomocne byłoby skupienie się na lepszym testowaniu i poprawieniu kodu.

Jeśli błędy wynikają zwykle z nieoptymalnych decyzji programistycznych, być może konieczne będzie włożenie większego wysiłku w lepsze projektowanie. W tym przypadku myślę, że można być zbyt zależnym od testowania, aby podnieść jakość oprogramowania, ponieważ zastosowanie poprawki do wadliwego kodu może tylko skomplikować przyszłe utrzymanie. Z jednej strony dostajesz mniej błędów, gdy je znajdziesz i naprawiasz, z drugiej strony przygotowujesz grunt pod przyszłe błędy.

Jednym ze sposobów oceny, czy masz problem z niedopatrzeniem lub problemem z projektem, może być rozważenie, ile wysiłku wymaga naprawienie błędów. Jeśli poprawki są zwykle duże lub uważasz, że nie rozumiesz ich dobrze, wskazuje to na projekt kodu, który można poprawić.

Myślę, że sprowadza się to do pewnego rodzaju dobrego gustu w zakresie kodu, który można rozwijać poprzez ćwiczenie i przeglądanie oraz czytanie o ludziach z podobnymi problemami.

Ostatecznie nie ma sensu oczekiwać żadnych błędów, ale próba zmniejszenia liczby błędów nie jest szkodliwa, chyba że masz ją już na niskim poziomie, a wtedy staje się to kompromisem między twoim czasem a czasem tego, kto znajdzie błędy, których nie łapiesz.

John Bickers
źródło
-2

Jeśli mam na myśli: „zero błędów podczas pisania kodu” -> to niezły cel, ale całkiem niemożliwy.

Ale jeśli masz na myśli: „zero błędów w dostarczonym kodzie” -> to możliwe, a ja pracowałem w takich środowiskach.

Wszystko czego potrzebujesz to: niesamowicie wysoka jakość kodu i prawie 100% pokrycie testami (testy jednostkowe + testy akceptacyjne + testy integracyjne).

Moim zdaniem najlepsza książka do nauki to: GOOS . Ale oczywiście książka nie wystarczy. Musisz przejść do jakiejś grupy użytkowników i porozmawiać o tym. Kursy, konferencje itp. Jakość zero błędów nie jest łatwa.

Przede wszystkim potrzebujesz szefa, który naprawdę interesuje się wysoką jakością i jest gotów za nią zapłacić.

Uberto
źródło
-3

Rozwiązanie dla programistów:

  • Zatrzymaj programowanie.
  • Zbuduj komputer mechaniczny.
  • Wymieniaj go co 5 lat, aby zużycie mechaniczne nie wchodziło w grę.

Rozwiązanie użytkownika:

  • Przestań używać komputerów.
  • Rób wszystko ręcznie.
  • Zawsze sprawdź, czy druga osoba dokładnie sprawdza wyniki.
rwong
źródło
-3

Zgadzam się, że będąc programistą bez błędów, po prostu nie możesz programować / kodować. Napotykanie i rozwijanie błędów jest częścią życia każdego programisty. Żaden doświadczony programista nie może powiedzieć wprost, że nigdy nie napotkał błędu w kodzie.

dbramhall
źródło
-4

Sparuj z innym inżynierem. Napisz test negatywny. Niech każdy wpisany znak będzie niezbędny do zaliczenia testu zakończonego niepowodzeniem. Zmodyfikuj kod, aby uprościć go. Napisz kolejny test negatywny i tak dalej.

Carl Coryell-Martin
źródło