Co uważasz za główną przyczynę wad oprogramowania (i jak je zminimalizować) [zamknięte]

14

Defekt definiuję jako:

„coś w projekcie aplikacji lub kodzie, które uniemożliwia jej działanie zgodnie z wymaganiami”.

Szukam pomysłów na temat przyczyn wad, np. Czynnika ludzkiego, braku testowania, braku prototypowania i możliwych pomysłów na ich złagodzenie.

Chris Buckett
źródło
5
Zastąpiłbym „wymagania” „potrzebami użytkownika” lub „oczekiwanym zachowaniem”, ponieważ nawet wymagania mogą być błędne.
mouviciel
Czy wymagania są nieprawidłowe? (i kod jest

Odpowiedzi:

13

Główną przyczyną wad oprogramowania jest interpretacja.

Interpretacja funkcji przez klienta różni się od interpretacji projektanta.

Interpretacja projektanta różni się od interpretacji programisty.

Większość metod opracowała sposoby przeciwdziałania temu efektowi. Ale w końcu jesteśmy tylko ludźmi i nie jesteśmy bezbłędni. Poza tym często występuje presja czasu i większość magii metodycznej jest często pomijana pod presją.

Testy mogą wykryć problemy tylko wcześnie. Ale nawet testerzy są ludźmi i testowanie w 100% jest niemożliwe. Jeśli chcesz uwolnić, zanim skończy się wszechświat.

Toon Krijthe
źródło
Gdybym tylko mógł uruchomić ten cholerny moduł czytający w myślach, wszystko byłoby dobrze.
HLGEM,
@Gamecat: i jeszcze gorzej, gdy pracujesz z ludźmi z całego świata. Nie tylko istnieje bariera językowa (często zdarza się, że przynajmniej jeden z uczestników nie jest biegły w języku angielskim), ale występują również różnice kulturowe.
Matthieu M.,
2
Przegapiłeś jedną - „interpretacja programisty różni się od interpretacji kompilatora” ...;)
Alex Feinman,
@Alex: Wiem, co kompilator zrobi z kodem, który piszę. Ta wiedza nie była łatwa do zdobycia, ale zrobiłem to. Teraz mamy moją interpretację kodu, którego nie napisałem, w przeciwieństwie do danych kompilatora i środowiska wykonawczego.
David Thornley,
@David, chyba że napisałeś i utrzymałeś kompilator, twoja wiedza na temat tego, co robią wnętrzności, jest abstrakcją tego, co się właściwie dzieje - i prawdopodobnie tak jest najlepiej, ponieważ pozwala wydać przestrzeń mózgową na rzeczywistą aplikację.
Alex Feinman
8

Uważam, że główną przyczyną wad oprogramowania są programiści.

Nie mówiąc, że po prostu być śmieszne, ale dlatego, że jeden z największych problemów, jakie obserwuje się w mojej pracy jest ubogie wymagania zbieranie, w połączeniu ze złym zrozumieniu dziedziny problemowej, powodując poważnych wad i problemów z użytecznością w projekcie.

Częściowo wynika to z braku woli uczenia się / rozumienia terminologii użytkownika końcowego, co powoduje nieporozumienia.

Częściowo wynika to ze zbyt wczesnego mówienia o technologii dla ludzi, którzy nie mają pojęcia, o czym mówisz i dlaczego to ma znaczenie.

Najlepszym przykładem tego było usłyszenie, jak jeden z programistów próbuje dowiedzieć się, jak długo pytania / odpowiedzi będą w postaci znaków ... Wiedziałem, że próbuje dowiedzieć się, jakiego pola wielkości należy użyć w bazie danych, ale dział, który o to prosił, nie miał najmniejszego pojęcia, dlaczego to się liczyło - ani że liczyły się spacje. Dla nas wydaje się to oczywiste, ale dla nich było to prawdziwe objawienie.

AnonJr
źródło
8

Podstawową przyczyną wad jest złe zarządzanie ;)

Poważnie, programista, który działa w dobrym stanie, nie jest proszony o przepracowanie, obniżenie jakości, posiadanie odpowiednich narzędzi, cichych warunków pracy i tak dalej, będzie produkował mniej błędów niż ktoś pracujący pod silną presją.

Również kierownictwo zatrudniające złych programistów pomaga również zwiększyć liczbę błędów.

Złe zarządzanie .

(zrzeczenie się odpowiedzialności: mam zatrudniać i zarządzać programistami)


źródło
nie sądzę, że to jest główny problem, większość programistów pracuje w cichych warunkach. Zgadzam się z AnonJr i Gamecat - niemożność pełnego zrozumienia problematycznej dziedziny, tylko szybkie iteracje i testy mogą pomóc.
radekg
1
Dlaczego większość programistów pracuje w cichych warunkach? W kilku firmach, które odwiedziłem w ciągu ostatniego roku, żadna nie była cicha.
Dobre zarządzanie może zaprowadzić cię daleko, złe zarządzanie nie zabierze cię gdziekolwiek!
Chris,
+1 w odniesieniu do cichych warunków pracy. Każda firma, w której kiedykolwiek pracowałem, była farmą kabin w Dilbertesque, w której stale słyszysz ludzi oddalonych o 4 stopy od ciebie, obcinających paznokcie, chrupających jedzenie i odbierających telefony.
Bobby Tables
5

Nie widzę żadnej głównej przyczyny - ale jedną z przyczyn, o której nie wspomniano, jest niezamierzone połączenie z innym kodem . Pisanie kodu, który ma niewidoczne skutki uboczne, przełamuje warstwy abstrakcji, przyjmuje założenia dotyczące danych (zmienne nie, stałe nie są i żadne dane wejściowe od użytkownika nie są bezpieczne), wkurza się z rzeczami, których nie musi się martwić sama w sobie i tak dalej.

Większość praktyk rozwojowych, które badam, sprowadza się do redukcji N, ponieważ złożoność programu jest przynajmniej O(N^2)i prawdopodobnie O(k^N). Definiowanie Npozostaje dla czytelnika ćwiczeniem, ale myślę o takich sprawach, jak złożoność cykliczna. Hermetyzacja logiki i danych powoduje zmniejszenie N poprzez podzielenie problemu na części.

Alex Feinman
źródło
4

Niezdolność do myślenia o wszystkim.

JeffO
źródło
4

Będąc niekompletnym

Wonko przy zdrowych zmysłach
źródło
4

Braki komunikacyjne. W zbiorze wymagań. Zgodnie z harmonogramem W dokumencie projektowym. W specyfikacji funkcjonalnej. W kodzie (przerwa między tym, czego chce programista, a tym, co mówi kompilatorowi).

Etykieta społeczna. Nazywanie kogoś niezdolnym jest społecznie niedopuszczalne.

aufather
źródło
3

Pędzi do rzeczy bez ich pełnego zrozumienia. Rozpoczęcie pisania kodu bez pełnego zrozumienia wymagań funkcjonalnych lub architektury technicznej.

Programowanie powinno być prawie automatyczne, wystarczy zapisać to, co jest oczywiste i zostało już wypracowane w umyśle. W praktyce widzę wiele poprawek w kodzie, aby spróbować zrozumieć dokładnie, co powinien zrobić kod. Byłem tego winny wiele razy.

Joeri Sebrechts
źródło
Cztery miesiące po nowej pracy wciąż jestem tylko małym procentem do „pełnego zrozumienia” czegokolwiek. Nie zamierzam się spieszyć; to co mówisz jest prawdą. Jednak tak długo jest bezproduktywne.
DarenW
Dopiero rok lub dwa zajęło mi osiągnięcie pełnej prędkości w systemie, nad którym pracuję (system 2 milionów linii). Nawet wtedy istnieją duże segmenty, których po prostu nie znam.
Joeri Sebrechts
2

Harmonogram Ciśnienie jest z pewnością silnym źródłem.

Pośpieszni programiści nie poświęcają czasu na pełne określenie wymagań lub pełne zrozumienie zamiarów stojących za wymaganiami, ani pełne zbadanie alternatywnych rozwiązań w celu znalezienia najlepszego rozwiązania lub pełnego przemyślenia wszystkich skrajnych przypadków i interakcji wprowadzanych przez nich zmian, lub opracować pełny zestaw przypadków testowych lub w pełni wykonać cały test jednostkowy lub wykonać pełny test integracji, w pełni rozważyć zależności platformy lub w pełni przetestować instalator lub w pełni udokumentować to, co zrobili, aby następny programista mógł zrozumieć …

AShelly
źródło
2

Kolejną rzeczą, o której należy wspomnieć, jest brak testu z zewnątrz. Gdy programista pisze testy i je uruchamia, testuje tylko swoją interpretację, a nie rzeczywiste wymagania. Chociaż testy jednostkowe napisane przez programistów są przydatne do wychwycenia niektórych błędów, większość błędów przejdzie te testy, ale nie będzie to, czego użytkownik chce lub potrzebuje. Żadne oprogramowanie, które nie zostało przetestowane przez osobę inną niż programista, nie jest testowane (nie mam na myśli jedynie przeprowadzania testów programisty).

HLGEM
źródło
2

To dlatego, że inżynieria oprogramowania jest z natury złożona. Esej „No Silver Bullet” omawia to.

Jak na ironię, wiele innych odpowiedzi tutaj dotyczy tematów, które są „przypadkowo skomplikowane”, w języku tego eseju, podczas gdy w rzeczywistości większość tego, co robią programiści, jest „zasadniczo złożona”, więc po prostu jest to takie tworzenie oprogramowanie jest trudne, oprogramowanie będzie zawierać błędy, a naszym zadaniem jest poradzenie sobie z tym.

Peter Eisentraut
źródło
1

Niezrozumienie oprogramowania jako sieci automatów stanowych, zasad leżących u podstaw ich działania (stanów, ich określania i przejść) oraz interakcji maszyn automatycznych.

Huperniketes
źródło
1

Pisanie kodu, który nie powiedzie się cicho, w porównaniu do kodu zgłaszającego wszystkie błędy.

bjornl
źródło
1

Brak sprawdzania rzeczy, które „nie mogą się wydarzyć” lub są mało prawdopodobne, jest duży. Czasami ideał jest wrogiem dobra. Jeśli nie jest wart dobrze przemyślanej hierarchii wyjątków, pewne szybkie i brudne obchodzenie się zawsze jest lepsze niż nic. Jestem ogromnyfan szybko zawiedzionych, asercji i pozostawiania asercji, które mają znikomy wpływ na wydajność w kompilacjach wersji. Nawet w szybkich i brudnych jednorazowych skryptach, w których kontroluję wszystkie dane wejściowe, włączam obsługę szybkich / brudnych błędów, zwykle tylko z funkcją równoważną do potwierdzenia, ale pozostaje włączona przez cały czas. Moja ogólna zasada jest taka, że ​​jeśli to się nie zdarzy lub uważasz, że tak się nie stanie, nie musi z wdziękiem zawodzić z przyjaznym dla użytkownika komunikatem o błędzie, ale przynajmniej powinno zawieść szybko z komunikatem o błędzie, który daje programistowi kilka wskazówek na temat tego, co poszło nie tak.

Edycja: Jedną powiązaną przydatną taktyką jest użycie aserts jako głównego narzędzia do debugowania i pozostawienie ich tam po zakończeniu sesji debugowania. Od tego momentu twoja baza kodów będzie miała wbudowane kontrole poczytalności, które bardzo utrudniają powtórzenie się powiązanych błędów. Jest to szczególnie przydatne w przypadku kodu, który jest trudny do wypowiedzenia.

dsimcha
źródło
1

Główną przyczyną wad oprogramowania jest pisanie kodu.

Napisz mniej kodu, a będziesz mieć mniej błędów ;-)

nlawalker
źródło
0

Na jednym poziomie zarządzanie. Ale to nie tylko PHB. To zarządzanie samym kodem, które może, ale nie musi, być odzwierciedleniem zarządzania przedsiębiorstwem.

Uczestnicy całego „cyklu życia” muszą być w pełni zainwestowani w jakość i stworzenie produktu, który po prostu nie umrze . Samo oprogramowanie obiecuje, że nigdy się nie złamie, biorąc pod uwagę odpowiednią niezawodność abstrakcji. Pozostaje tylko pytanie, czy konstruktorzy oprogramowania są zainteresowani tym doskonałym działaniem.

Paul Nathan
źródło