OSnews.PL

Coverity sporządziła raport dot. Zestawienia jakości kodu otwartego i zamkniętego.

Firma Coverity przeprowadziła szczegółowe analizy większości dużych i wiele małych platform open source, oraz aplikacji. Raport przedstawia wynik dogłębnej analizy ok. 300 milionów linii kodu m.in. takich platform jak Linux 2.6, PHP 5.3 i PostgreSQL 9.1. Uznane zostały one za wzorce projektów open source z najlepszym wynikiem gęstości awaryjności kodu mając wyniki odpowiednio: 0,62, 0,20 i 0,21

Najistotniejsze wnioski z raportu to:

  • Poziom jakości kodu otwarto-źródłowego jest na równi z kodem zamkniętym, w szczególności gdy projekty są podobnej wielkości. Dla przykładu jądro Linuksa mające ok 7 mln. linii ma gęstość awaryjności kodu 0,62 (liczba błędów na 1000 linii), co jest wynikiem podobnym do jego zamkniętych odpowiedników.
  • Podmioty deklarujące duży nacisk na jakość oprogramowania traktują testowanie oprogramowania jako część procesu przepływu pracy przy tworzeniu oprogramowania.
  • Poprzez czerpanie korzyści z wysokiej jakości kodu nadal obserwuje się jej poprawę w czasie.

Granica pomiędzy otwartym a zamkniętym oprogramowaniem będą się dalej zacierać również poprzez to że pozycja open source jest ugruntowywana w nowoczesnym łańcuch dostaw oprogramowania. Pełen raport można uzyskać poprzez wysłanie wypełnionego formularza z a href=”http://softwareintegrity.coverity.com/coverity-scan-2011-open-source-integrity-report-registration.html”>tej strony.



PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo
29 odpowiedzi na „Coverity sporządziła raport dot. Zestawienia jakości kodu otwartego i zamkniętego.”
  1. Awatar o_O
    o_O

    Na czyje zamówienie ta firemka robiła ów raport?
    Bo ich wyniki znacznie odbiegają od innych tego typu badań.
    Wygląda to na jedną wielką farsę i próbę zakłamania rzeczywistości.

    Odpowiedz
    1. Awatar o_O
      o_O

      http://www.linux.pl/?id=news&show=4271
      "Po analizie kodów źródłowych 180 popularnych programów Open Source, takich jak Perl, Samba czy PHP, ujawniono statystyki – średnio na 1000 linii kodu przypadał 1 błąd."
      "Pozytywną informacją jest to, że średnia luk w jądrze Linuksa z linii 2.6 wynosi 0,127 błędu na 1000 linii kodu."
      Taka nagła zmiana w wynikach "badań"? Toż to większa farsa niż słupki sondażowe PO.

      Odpowiedz
      1. Awatar kristoferes
        kristoferes

        To rzeczywiście zastanawiające. Może firma zmieniła sposób liczenia tych błędów, bo dziwne że w ciągu 3 lat wynik pogorszył się tak drastycznie :/

        Odpowiedz
        1. Awatar aaa
          aaa

          A może kristoferes by porządnie przetłumaczył wyniki, a nie wysysał je z palca? http://www.h-online.com/open/news/item/Report-Ope…

          Średnia dla Open Source to 0.45/1000, Linux ma 0.62 (nie 62!), programy o zamkniętym kodzie – 0.64.

          Odpowiedz
          1. Awatar kristoferes
            kristoferes

            Miałem tego pecha że tym razem nie skorzystałem z h-online, ale też nie "z palca". Będę miał nauczkę, żeby nie korzystać z tamtego źródła :-/.

          2. Awatar morsik
            morsik

            fixed.

      2. Awatar kristoferes
        kristoferes

        Znalazłem na ich stronie taką tabelkę http://scan.coverity.com/all-projects.html ; w kolumnie: Defects / KLOC dla linuksa rzeczywiście jest wartość 0,127.

        Odpowiedz
  2. Awatar 123
    123

    62/1000 to liczba przerażająca. W 7 milionach linii byłoby niemal pół miliona błędów. Nie sądzę, żeby taki produkt mógł w ogóle działać.
    Poza tym cóż to za "zestawienie jakości kodu otwartego i zamkniętego", jeśli podawane informacje dotyczą wyłącznie kodu otwartego? Gdzie wiarygodne wyniki "odpowiednika Linuksa" czyli Windowsa? Gdzie wyniki C# (vs PHP), gdzie SQL Servera (vs PostgreSQL).
    Bzdet nie raport, jak zwykle tego typu publikacje.

    Odpowiedz
    1. Awatar 123
      123

      I jeszcze to: "Coverity nie chciał natomiast ujawnić wyników testowania produktów o zamkniętym kodzie. Firma na zlecenie swoich klientów sprawdziła 400 takich produktów. Nasi klienci nie byliby zadowoleni, gdybyśmy ujawnili liczbę błędów w ich kodzie – stwierdzili przedstawiciele Coverity. "
      Za to z pewnością są zadowoleni z siania FUDu.

      Odpowiedz
  3. Awatar @pieczara666
    @pieczara666

    Co to znaczy jakość kodu, jak to ocenić, gdzie są jakieś wytyczne?
    Czasami coś napiszę, program działa jak w zamierzeniu, nie sypie się ale wiecznie nurtuje mnie pojęcie jakości kodu, a nie potrafię tego ocenić. Biorąc pod uwagę różne paradygmaty programowania, a nie tylko obiektowy (można się zetknąć z opiniami że to jedyny słuszny)

    Odpowiedz
    1. Awatar Konon
      Konon

      🙂 http://www.osnews.com/story/19266/WTFs_m

      Odpowiedz
  4. Awatar esio
    esio

    Super.
    Do czego jest to porównanie?
    Jakie zamknięte projekty zostały wzięte do porównania? To coś to ściema…

    Odpowiedz
    1. Awatar cutugno
      cutugno

      http://serwer22962.lh.pl/new-hampshire-za-open-source/#ID…

      Odpowiedz
  5. Awatar Paweł
    Paweł

    Sorry, że się czepiam, ale translate.google.com nie wystarcza.
    Co oznacza: "Granica pomiędzy otwartym a zamkniętym oprogramowaniem będą się dalej zacierać również poprzez to że pozycja open source jest ugruntowywana w nowoczesnym łańcuch dostaw oprogramowania."?
    Stary jestem już i nie bardzo rozumiem, jeśli ktoś łamie wszelkie zasady języka polskiego.

    Odpowiedz
  6. Awatar M..
    M..

    "…traktują testowanie oprogramowania jako część procesu przepływu pracy przy tworzeniu oprogramowania…"
    "Nie no k… rewelacja" jakby powiedział Misiek Przeklinak. Jak coś takiego czytam to i mi nasuwają się podobne myśli :-D.
    Po pierwsze wniosek jaki można z tego badania wysnuć jest taki, że używając zamkniętego kodu musimy zdać się na łaskę i niełaskę wyroczni jaką jest tego typu badanie. A ja bardzo nie lubię gdy muszę polegać na tego typu badaniach. Bo czym innym jest wiara a czym innym pewność. I jest bardzo źle gdy ktoś musi się uciekać do wiary w powodzenie przedsięwzięcia technicznego.

    Proponowałbym mały quizik "Jak testujemy nasz kod?":
    1. Jak szef/klient się nie czepia to – jest dobrze.
    2. Jak np. gra po 7. godzinach "katowania" się nie wiesza – jest dobrze.
    3. Już "po wszystkim" jak coś spłodzę to najpierw w ruch idzie profiler by sprawdzić co ile pożera zasobów. Potem sprawdzam wycieki pamięci. Nastepnie odpalam debugger i wstawiając wartości "od czapy" w miejsca zmiennych sprawdzam co się stanie? Blokuję wybrany proces by sprawdzić co będzie dalej?
    4. Zdajecie się na swoje doświadczenie poparte pewną ilością "dania ciała" – i jest dobrze.
    5. Zwalacie problem na kogoś innego – i jest dobrze.
    6. Mimo testów, debuggowania, sprawdzania wyjątków dajecie na mszę w intencji gdyż to wy będziecie lecieli samolotem, do którego pisaliście oprogramowanie – i jest dobrze.
    7. "Walić to…" – i jest dobrze.

    mile widziane inne pomysły 🙂 .

    Odpowiedz
  7. Awatar ssk
    ssk

    zastanawia mnie jak można badać zamknięty kod.

    Odpowiedz
    1. Awatar cutugno
      cutugno

      To, że ja czy ty nie mamy dostępu do źródeł, nie znaczy, że badający nie mieli.

      Odpowiedz
      1. Awatar ali
        ali

        Buahahaha już widzę jak poważna firma daje swój kod do "badania". Zresztą zastanawiające jest skoro badali np. kod otwartego Red Hata jaki system z zamkniętym kodem był przeciwstawny? Windows? Już to widzę. Ściema na maksa.

        Odpowiedz
        1. Awatar mikolajs
          mikolajs

          Jak ktoś nie pokazuje swojego kodu to widocznie wstydzi się, bo wie że jest marnej jakości 😛

          Odpowiedz
          1. Awatar xia
            xia

            Pytanie jak odnaleziona ilość bugów przekłada się na jakość w rzeczywistości np. Gnome: 430,809, 0.508; KDE 4,712,273, 0.019. Nie dość, że jest dziwnie duża różnica w liczbie linii kodu, to dodatkowo KDE powinno być bardziej stabilne o ponad 20 razy.

          2. Awatar herr
            herr

            Sprawdź dokładnie jakie elementy z poszczególnych środowisk zbadano.

        2. Awatar cutugno
          cutugno

          "Buahahaha już widzę jak poważna firma daje swój kod do "badania"."

          Gdybyś zamiast już widzieć, rzeczywiście zajrzał do raportu i dowiedział się czegoś o tej firmie, wiedziałbyś, że takie niepoważne firmy jak choćby Juniper czy Samsung nie tylko dają kod do badania, ale jeszcze za to płacą.

          "skoro badali np. kod otwartego Red Hata jaki system z zamkniętym kodem był przeciwstawny"

          I to jest sensowny zarzut. W ogóle nie wiadomo co po stronie komercyjnej badali, w jaki sposób kod był selekcjonowany zarówno przez ich klientów (oni sprzedają usługę analizy kodu – może klienci dają ten kod, z którym mają problemy?) jak i przez nich samych, dlatego nie da się tego raportu traktować jako argumentu za czy przeciw OS.

          Odpowiedz
  8. Awatar jarek
    jarek

    Heh, jak pojawia sie badanie z ktorego wynika, ze jakosc OS jest lepsza niz kodu zamknietego to piania z zachwytu nie ma konca. Jak nie daj boze pojawi sie cos innego to obraza majestatu.
    A swoja droga takie mechaniczne porownania to o kant zadka mozna potluc, dla porownania, z tej tabeli:
    http://scan.coverity.com/all-projects.html

    Wynika, ze:

    haiku: 0.40
    kde: 0.019
    linux: 0.127
    reactos: 0.28

    To by znaczylo, ze ractos jest niewiele mniej stabilny niz linux, a i hajku daje rade.
    A wszystko to jest i tak nic w porownaniu do superstabilnego KDE.
    I to by bylo na tyle jesli chodzi o sens takich statystyk.

    Odpowiedz
    1. Awatar mikolajs
      mikolajs

      Używasz ostatniego KDE?
      Poza tym, pojęcie błędu w kodzie jest dość szerokie, a dla użytkownika najbardziej widoczne są błędy krytyczne inne może widzieć jako zmniejszenie funkcjonalności.

      Odpowiedz
      1. Awatar mykodem33
        mykodem33

        pojęcie błędu w kodzie jest dość szerokie
        ———————————————————-

        i tutaj jest sens tego wszystkiego, czyli kolejna produkcja szumu informacyjnego nikomu niepotrzebnego i niczego nie wykazująca. Ot pisać byle pisać i byle zaistnieć. Czy ma to sens czy nie – nieważne.
        Kolejne badania z cyklu "Trzeba-wykazać-pewną-tezę-więc-dobierzmy-odpowiednie-wskaźniki-by wyszło-na-nasze".
        Chętnie bym obejrzał takie zestawienie konkretnych produktów, np, vBulletin vs phpBB by "Przemo" czy PostgreSQL 9.1 vs Oracle 11i i poczytał potem komentarze użytkowników obydwu produktów ;>

        Odpowiedz
        1. Awatar mikolajs
          mikolajs

          Jak się zastosuję tę samą definicję to jednak można coś ocenić. A badania prowadzić może każdy, kwestia tylko ich wiarygodności.
          Pewnie słuszność masz w tym, że najsłabszy punkt w tych badaniach to fakt niedostępności większej ilości kodu zamkniętego. Jednak ludzie, którzy na co dzień korzystają z podobnych narzędzi i badają kod zamknięty w różnych projektach mogą na podstawie tych danych porównywać jakość ich kodu do przebadanego kodu Open Source. Więc nie jest to zupełnie pozbawione sensu.

          Odpowiedz
    2. Awatar cutugno
      cutugno

      "To by znaczylo, ze ractos jest niewiele mniej stabilny niz linux,"

      E tam, po prostu by znaczyło, że nie doczytałeś co sprawdzali.

      Odpowiedz
    3. Awatar 123
      123

      To by znaczyło, że wnioskujesz na podstawie domysłów, a nie wyników.
      Nikt nie twierdzi że porównywano stabilność aplikacji.

      Odpowiedz
  9. Awatar iss
    iss

    Jak już znaleźli te wszystkie błędy, to chyba łatwo będzie je wszystkie poprawić, prawda?
    Dobrze, że ta firma Coverity potrafi zrobić to, co nie udaje się setkom programistów, którzy pracują nad tym zbadanym kodem.

    Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *


media społecznościowe

ostatnie artykuły

Popularne tagi

android apple bezpieczeństwo biznes google hardware internet iphone kaspersky media microsoft mobile open-source press-release programowanie software UNIX windows Wydania Wydarzenia

Kategorie