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

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?

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.

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.

„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!

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.

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 .

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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).

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”

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.

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.

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;)

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.

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ć.

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.

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.

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.