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

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.

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.

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.

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)

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.

Niezdolność do myślenia o wszystkim.

Będąc niekompletnym

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.

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.

Errare humanum est

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

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

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.

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.

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

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.

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

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

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.