To pytanie ma już tutaj odpowiedzi :
Odpowiedź
Najbliższa aplikacja wolna od błędów to droższe to robi. To tak, jakby celować w 100% pokrycie kodu: spędzasz tyle samo czasu i pieniędzy, uzyskując od 0% do 95%, od 95% do 99% i od 99% do 99,9%.
Czy potrzebujesz dodatkowych 0,1% pokrycia kodu lub jakości? Prawdopodobnie tak, jeśli pracujesz nad oprogramowaniem, które steruje systemem chłodzenia reaktora jądrowego. Prawdopodobnie nie, jeśli „pracujesz nad aplikacją biznesową.
Ponadto tworzenie oprogramowania wysokiej jakości wymaga zupełnie inne podejście . Nie można po prostu poprosić zespołu programistów, którzy spędzili życie na pisaniu aplikacji biznesowych, o stworzenie aplikacji prawie pozbawionej błędów. Oprogramowanie wysokiej jakości wymaga różnych technik, takich jak dowód formalny coś, czego z pewnością nie chcesz używać w aplikacji biznesowej ze względu na niezwykle wysoki koszt, jaki wiąże.
Jak wyjaśniłem w jednym z moje artykuły :
-
Aplikacje biznesowe nie powinny oferować jakości wymaganej dla oprogramowania krytycznego dla życia, ponieważ jeśli te aplikacje biznesowe od czasu do czasu zawodzą, po prostu tak nie jest ” Nieważne. Widziałem błędy i przestoje w witrynach prawdopodobnie każdej dużej korporacji, z wyjątkiem Amazon. Ten przestój i te błędy są irytujące i mogą kosztować firmę kilka tysięcy dolarów miesięcznie, ale naprawienie tego byłoby znacznie droższe.
-
Koszt powinien być głównym celem, i powinien być studiowany pragmatycznie. Wyobraźmy sobie błąd, który dotyka 5000 klientów i jest tak ważny, że klienci odejdą na zawsze. Czy to ważne? Tak? Pomyśl więcej. A jeśli powiem, że każdy z tych klientów płaci 10 USD rocznie i że tak kosztuje prawie 100 000 $, aby naprawić błąd? Naprawianie błędów wygląda teraz o wiele mniej interesująco.
A teraz, aby odpowiedzieć konkretnie na pytania:
dlaczego błędy są zgłaszane nawet po przeprowadzeniu tylu testów? Czy to nasz problem z wymaganiami? Nasz klient nie jest zadowolony z niczego, co zapewniamy? czy robimy coś nieprawidłowego?
Wiele rzeczy może się nie udać. Czy przez testowanie masz na myśli rzeczywiste testy automatyczne? Jeśli nie, jest to ogromny problem sam w sobie. Czy testerzy rozumieją wymagania? Czy komunikujesz się z klientem regularnie – przynajmniej raz na iterację, najlepiej przedstawiciel klienta jest natychmiast osiągalny na miejscu dla każdego członka Twojego zespołu ? Czy twoje iteracje są wystarczająco krótkie? Czy programiści testują swój własny kod?
Podobnie jak w przypadku Piszą odpowiedni artykuł , do którego link znajduje się powyżej, sporządzają raport o błędzie i analizują dlaczego ten błąd pojawił się w pierwszej kolejności i dlaczego został pominięty przez każdego testera . To może dać ci pewne wyobrażenia o lukach w procesie twojego zespołu.
Ważna kwestia do rozważenia: czy twój klient płaci za poprawki błędów? Jeśli nie, może być zachęcony do rozważenia wielu rzeczy być błędem. Zmuszenie go do zapłacenia za czas spędzony na zgłaszaniu błędów znacznie zmniejszy liczbę zgłoszeń błędów.
Czy ktoś opracował jakąkolwiek aplikację, która była całkowicie bez błędów? Jaki jest proces? Dlaczego nie możemy wdrożyć aplikacji z drobnymi błędami? Czy mamy być perfekcjonistami?
Ja. Napisałem dla siebie aplikację w ostatni weekend i jak dotąd nie znalazłem żadnego błędu.
Błędy są zgłaszane tylko wtedy, gdy są zgłaszane. Więc teoretycznie posiadanie aplikacji wolnej od błędów jest całkowicie możliwe: jeśli nie jest używana przez nikogo, nie będzie nikogo, kto mógłby zgłaszać błędy.
Teraz, pisząc aplikację na dużą skalę, która idealnie pasuje do specyfikacji i udowodniono, że jest poprawna (patrz wyżej wspomniany dowód formalny) to inna historia. Jeśli jest to projekt krytyczny dla życia, powinien to być Twój cel (co nie oznacza, że aplikacja będzie bez błędów).
Czy obecny scenariusz jest prawidłowym procesem tworzenia i testowania? Jeśli nie, to jaki jest skuteczny sposób, w którym programiści, testerzy i klient osiągają maksymalne korzyści razem?
-
Aby się wzajemnie zrozumieć , powinni się komunikować. Nie dzieje się tak w większości firm, które widziałem. W większości firm kierownik projektu jest jedyną osobą, która rozmawia z klientem (czasem z przedstawicielem).Następnie dzieli się (czasami częściowo) swoim zrozumieniem wymagań z programistami, projektantami interakcji, architektami, administratorami baz danych i testerami.
Dlatego tak ważne jest, aby klient (lub jego przedstawiciel) być osiągalnym dla każdego w zespole (podejście Agile) lub posiadać formalne środki komunikacji, które upoważniają osobę do komunikowania się tylko z kilkoma innymi osobami w zespole i robić to w taki sposób, aby informacje mogły być udostępnione całemu zespołowi, zapewnienie, że wszyscy mają te same informacje.
-
Istnieje wiele procesów związanych z programowaniem i testowaniem. Bez dokładnej znajomości firmy i zespołu nie ma sposobu, aby określić, który z nich powinien zastosuj się w Twoim przypadku. Rozważ zatrudnienie konsultanta lub kierownika projektu, który jest wystarczająco kompetentny.
Komentarze
Odpowiedź
Nie wszystkie błędy są sobie równe, więc musisz oddzielić ziarno od plew.
Oczekiwania
Wiele błędów jest zgłaszanych po prostu z powodu niedostatku tego, co robi oprogramowanie i czego oczekuje użytkownik końcowy. Oczekiwanie to pochodzi z wielu dziedzin: używania innego oprogramowania, niewłaściwej dokumentacji, nadmiernie gorliwych sprzedawców, sposobu działania oprogramowania itp.
Pełzanie zakresu
Nie trzeba dodawać, że im więcej dostarczasz, tym większe jest prawdopodobieństwo wystąpienia błędów. Wiele błędów wynika po prostu z nowych funkcji. Dostarczasz X & Y, ale klient mówi, że na odwrocie powinien teraz również zrobić Z.
Zrozum problematyczną domenę
Wiele błędów pojawia się z tego prostego powodu, że problematyczna domena była słabo poznana. Każdy klient ma własne zasady biznesowe, żargon i sposoby działania. Wiele z tego nie zostanie nigdzie udokumentowane – będzie to po prostu w głowach ludzi. Mając największą wolę na świecie, nie możesz mieć nadziei na uchwycenie tego wszystkiego za jednym podejściem.
Więc … co z tym zrobić.
Automatyczne testy jednostkowe
Wiele błędów jest wprowadzanych jako nieoczekiwany efekt uboczny jakiejś zmiany kodu lub innego. masz zautomatyzowane testy jednostkowe, możesz uniknąć wielu z tych problemów i stworzyć lepszy kod od samego początku.
Testy są tak dobre, jak dostarczone dane – więc upewnij się, że w pełni rozumiesz dziedzinę problemu.
Pokrycie kodu
Idzie to w parze z automatycznym testowaniem jednostkowym. Powinieneś upewnij się, że przetestowano tyle kodu, ile jest to możliwe.
Zapoznaj się z lekcjami
Szaleństwo to ciągłe robienie tego samego i oczekiwanie różnych rezultatów
Czy rozumiesz przyczyny ostatniej porażki? Naprawdę? problem występujące, ale jakie było prawdziwe źródło? Złe dane? Błąd użytkownika? Uszkodzenie dysku? Awaria sieci?
Nic nie denerwuje klientów bardziej niż napotykanie tych samych problemów w kółko bez postępu w kierunku rozwiązania.
Odpowiedź
Defekty istniały od początku tworzenia oprogramowania. Trudno jest określić na podstawie pytania, w jakim stopniu i w jakim stopniu defekty wpływają na użyteczność lub funkcjonalność.
Istnieją programy wolne od błędów, ale prawie każdy nietrywialny system będzie miał defekty.
Będziesz musiał zdecydować o jakimś priorytecie i prawdopodobnie będziesz musiał przeprowadzić badania nad przyczynami defektów – gdzie zostały one wprowadzone. Zbyt wiele jest do omówienia takich rzeczy w prostym pytaniu Q & Post.
Całe książki zostały napisane o analizie przyczynowej i procesie naprawiania organizacji, która ma problemy z jakością.
Więc moja rekomendacja to: (w przypadkowej kolejności)
- Zaimplementuj system śledzenia defektów, jeśli jeszcze go nie znalazłeś
- Określ sposób sklasyfikowania wagi defektów
- Dowiedz się, dlaczego nie spełniasz oczekiwań klienta (czy to programiści, kontrola jakości, klient itp.)
- Dowiedz się o niektórych ćwiczeniach, takich jak „Pięć powodów”, i zrób podobne dochodzenie na niektóre przyczyny twoich wad.
Odpowiedź
Zależy od tego, jak nazywasz aplikację.
Jeśli masz na myśli program interaktywny, w którym musisz mieć pewność, że zachowanie w czasie rzeczywistym jest dokładnie takie a takie w danych okolicznościach, to w zasadzie niemożliwe jest udowodnienie, że nie ma żadnych błędów w tym. Przypuszczam, że byłoby to możliwe, gdybyś mógł rozwiązać problem z zatrzymaniem , ale nie możesz „t.
Jeśli jednak ograniczysz się do stwierdzenie „takie a takie dane wejściowe ostatecznie przyniosą taki a taki stan końcowy”, wtedy Twoje szanse na „dowód wolny od błędów” są większe, ponieważ możesz użyć niezmienników . To i tylko to pozwala na rozbicie dowodu poprawności na podproblemy, z których każdy może stosunkowo łatwo udowodnić, że działa poprawnie w wszystkich okolicznościach pozostałego programu (chociaż generalnie nie można być bardzo dokładnym co do tego, ile czasu & może to zająć).
Takie techniki są w zasadzie możliwe w każdym język programowania (choć niektóre ezoteryczne, takie jak Malbolge , próbują obalić to !), ale we wszystkich imperatywnych językach bardzo szybko robi się bałagan, ponieważ musisz skrupulatnie śledzić wiele z nich niejawny stan programu. W językach funkcjonalnych 1 dowody wydają się wyglądać znacznie ładniej ( czyste języki lub czysto funkcjonalny podzbiór języka). Mimo to, szczególnie w przypadku typów dynamicznych, będziesz musiał napisać wiele wymagań dotyczących dozwolonych danych wejściowych. Jest to oczywiście jedna z głównych zalet silnych systemów typu statycznego: wymagania są bezpośrednio w kodzie!
Cóż, idealnie, to znaczy. W praktyce programy O „Caml, a nawet Haskell zwykle zawierają funkcje niepotwierdzone , tj. funkcje, które ulegają awarii / zawieszają się / zgłaszają dla niektórych danych wejściowych, pomimo prawidłowego typu 2 . Ponieważ nawet jeśli języki te mają bardzo elastyczny system typów, czasami nie jest możliwe użycie go do pełnego ograniczenia czegoś.
Wpisz języki z zależnymi typami. ! Potrafią one „obliczać” typy dokładnie według potrzeb, więc wszystko, co zdefiniujesz, może mieć dokładnie taką sygnaturę, która potwierdza wszystko, czego potrzebujesz. I rzeczywiście, języki z typami zależnymi są głównie nauczane jako środowiska sprawdzające . Niestety, myślę, że żadnemu z nich tak naprawdę nie zależy na pisaniu oprogramowania produkcyjnego. W przypadku praktycznych zastosowań myślę, że najbliższym całkowicie odpornym na błędy jest pisanie w języku Haskell z tak dokładnymi funkcjami jak To sprawia, że jesteś ładna odporna na błędy – aczkolwiek, znowu, tylko w odniesieniu do opisu funkcjonalnego. Haskell Unikalny sposób obsługi We / Wy z monadami również daje bardzo przydatne dowody, ale generalnie nie mówi nic o tym, jak długo zajmie coś koniec. Całkiem możliwe, że coś może zająć wykładniczy czas w określonych okolicznościach – z punktu widzenia użytkownika, co prawdopodobnie byłoby tak poważnym błędem, jak gdyby program całkowicie się zawiesił.
1 Lub bardziej ogólnie, języki opisowe . Nie mam dużego doświadczenia z językami logicznymi, ale przypuszczam, że mogą być podobnie dobre w dowodach Pozdrawiam.
2 Jeśli nie jest to właściwy typ, kompilator nigdy nie pozwoli na to w tych językach; to już eliminuje wiele błędów. (A dzięki wnioskowaniu o typie Hindleya-Milnera sprawia, że programy są również bardziej zwięzłe!)
Komentarze