Temat: Jakość kodu

No właśnie, co uważacie o jakości kodu, który tworzycie. Ostatnio napisałem artykuł dostępny po adresem http://codefedonarts.com/2014/02/21/code-quality-reall... i chciałbym dowiedzieć się więcej na ten temat. Czy warto koncentrować siły na np. skorzystanie z TDD?

Temat: Jakość kodu

Trochę głupio się czuję kiedy to piszę (wydawało mi się, że to dość oczywiste), ale testowanie kodu a zapewnianie jakości kodu to dwie zupełnie róźne rzeczy.

Nie można jednym zapewniać drugiego.
Kod może być "piękny" i nie realizować zakładanej funkcjonalności. To samo może zajść w drugą stronę.

Temat: Jakość kodu

To ja może odwrócę pytanie: Czy słyszałeś o kodzie dobrej jakości, który nie jest testowalny? Dla mnie to pierwszy i jeden z najważniejszych kroków do zapewniania jakości. A może znasz inne bardziej skuteczne sposoby zapewniania jakości?

Temat: Jakość kodu

Jak napisał/powiedział Robert C Martin "The act of writing a unit test is more an act of design than verification" i w pełni się z tym zdaniem zgadzam.
TDD wpływa na jakość kodu (poprzez poprawę projektu oraz refaktoring, który jest jego nieodłączną częścią), lecz oczywiście nie jest warunkiem wystarczającym, aby jakość tego kodu była na wysokim poziomie. Na to wpływa jeszcze wiele rzeczy m.in. umiejętności programisty, jakość projektu. Poprawić go może również jeszcze kilka innych aktywności takich jak np. Code Review, Pair Programming.

Istotne jest również to co napisałeś w artykule, że "crucial factor is that a ‘good code must work’". Zakładam, że chodzi o to, że działanie ma być takie, jakiego się od funkcjonalności oczekuje, czyli poprawne, bo tak jak napisał @Jakub

Kod może być "piękny" i nie realizować zakładanej funkcjonalności

i ważne jest aby pamiętać o tym, że jakość kodu nie przekłada się na jakość oprogramowania, jeżeli sam rozwiązywany problem jest źle rozumiany przez tych, którzy to rozwiązanie mają dostarczyć.

Temat: Jakość kodu

Patryk O.:
To ja może odwrócę pytanie: Czy słyszałeś o kodzie dobrej jakości, który nie jest testowalny?

jak mierzysz jakość kodu?

Temat: Jakość kodu

Jarosław Ż.:

Patryk O.:
To ja może odwrócę pytanie: Czy słyszałeś o kodzie dobrej jakości, który nie jest testowalny?

jak mierzysz jakość kodu?

Rzucę kilka haseł, bo widzę Twoją zaczepkę a nie chcę zdradzać warsztatu.

wielowymiarowa funkcja jakości

KPI

analiza statyczna kodu

analiza dynamiczna kodu

code review

unit tests

end-to-end tests

behavioral tests

SOLID

GRASP

DRY

KISS

lessons learned

code readibility (self-documenting, javadoc)

service monitor

mtbf

jenkins

nexus

maven

Ten post został edytowany przez Autora dnia 26.02.14 o godzinie 00:19

Temat: Jakość kodu

Mateusz K.:

Jarosław Ż.:

Patryk O.:
To ja może odwrócę pytanie: Czy słyszałeś o kodzie dobrej jakości, który nie jest testowalny?

jak mierzysz jakość kodu?

Rzucę kilka haseł, bo widzę Twoją zaczepkę a nie chcę zdradzać warsztatu.

wielowymiarowa funkcja jakości

KPI

analiza statyczna kodu

analiza dynamiczna kodu

code review

unit tests

end-to-end tests

behavioral tests

SOLID

GRASP

DRY

KISS

lessons learned

code readibility (self-documenting, javadoc)

service monitor

mtbf

jenkins

nexus

maven

liczba haseł imponująca :), zadałem to pytanie nie jako zaczepkę a bardzo poważnie, bo:
- jakość czegokolwiek ocenia klient (nabywca tego czegoś, adresat) a nie ten kto to zrobił,
- nie ma obiektywnych mierników jakości bo to by znaczyło, że można ocenić jakość czegokolwiek mimo tego, że nikt tego nie potrzebuje

Dla mnie jakość kodu (produktu jakim jest program) to np.:
- koszt rozwoju
- koszt utrzymania

bo już "łatwość korzystania z oprogramowania" to raczej jakość GUI...
Takie rzeczy np. KISS czy SOLID to raczej cechy tego kodu jako całości a nie jakość... owszem te cechy mogą wpływać na jakość ale nie muszą... można zrobić rewelacyjny, zgodny z SOLID itp. program ale kompletnie nikomu do niczego nie przydatny.

Inny przykład: czy tekst ślicznie sformatowany, bez literówek, ładnie podzielony na jasne co do treści rozdziały i podrozdziały, dobrze zilustrowany ale kompletnie nikomu do niczego nie przydatny co co tu jest, i czy w ogóle coś, "wysokiej jakości"?

Temat: Jakość kodu

Mateusz K.:

jak mierzysz jakość kodu?

Rzucę kilka haseł, bo widzę Twoją zaczepkę a nie chcę zdradzać warsztatu.
[...]

Z tym, że nie wszystkie rzeczy, które wymieniłeś służą do mierzenia tej jakości. Wiele z nich może wpłynąć na tą jakość, ale nie mogą służyć do jej miary.

Jarosław Ż.:
Dla mnie jakość kodu (produktu jakim jest program) to np.:
- koszt rozwoju
- koszt utrzymania

Chyba z tym wszyscy się zgodzą.
Jakość kodu to nie są małe metody, kod zgodny z SOLID, pełen wzorców itp. Obecność ich nie świadczy o jakości, niemniej jednak wydaje mi się, że w odwrotną stronę taka zależność zachodzi, przynajmniej jeżeli mówimy o oprogramowaniu napisanym obiektowo.
Po prostu, wykorzystywanie dobrych praktyk pomaga nam utrzymać jakość na jak najwyższym poziomie.

Inny przykład: czy tekst ślicznie sformatowany, bez literówek, ładnie podzielony na jasne co do treści rozdziały i podrozdziały, dobrze zilustrowany ale kompletnie nikomu do niczego nie przydatny co co tu jest, i czy w ogóle coś, "wysokiej jakości"?

Wykonanie jest zapewne wysokiej jakości, ale całość, jako produkt z jakością pewnie niewiele wspólnego ma.
Dlatego tak istotne jest, żeby pamiętać, że kod jest tylko drogą do celu - stworzenia funkcjonalnej aplikacji, która robi to, co robić powinna.
Kawałek kodu jest tylko kawałkiem kodu i choć można mówić o jego "pięknie" to zapewne nie o jakości, bo do tego jest nam potrzebne spojrzenie na całość (lub przynajmniej większą część).

Temat: Jakość kodu

Dla mnie jakość kodu (produktu jakim jest program) to np.:
- koszt rozwoju
- koszt utrzymania

Chyba z tym wszyscy się zgodzą.
Jakość kodu to nie są małe metody, kod zgodny z SOLID, pełen wzorców itp. Obecność ich nie świadczy o jakości, niemniej jednak wydaje mi się, że w odwrotną stronę taka zależność zachodzi, przynajmniej jeżeli mówimy o oprogramowaniu napisanym obiektowo.
Po prostu, wykorzystywanie dobrych praktyk pomaga nam utrzymać jakość na jak najwyższym poziomie.

ja mam cały czas wątpliwości co do łączenia "wysokiej jakości" umiejętności kogoś, a jakością produktu jaki ten ktoś tworzy...

Inny przykład: czy tekst ślicznie sformatowany, bez literówek, ładnie podzielony na jasne co do treści rozdziały i podrozdziały, dobrze zilustrowany ale kompletnie nikomu do niczego nie przydatny co co tu jest, i czy w ogóle coś, "wysokiej jakości"?

Wykonanie jest zapewne wysokiej jakości, ale całość, jako produkt z jakością pewnie niewiele wspólnego ma.
Dlatego tak istotne jest, żeby pamiętać, że kod jest tylko drogą do celu - stworzenia funkcjonalnej aplikacji, która robi to, co robić powinna.
Kawałek kodu jest tylko kawałkiem kodu i choć można mówić o jego "pięknie" to zapewne nie o jakości, bo do tego jest nam potrzebne spojrzenie na całość (lub przynajmniej większą część).

jakość kodu jest wdzięcznym tematem bo często jest ona podnoszona w rozmowach, problem polega na tym, że "kupujący" ma tylko jedną możliwość oceny kodu: jak program spełnia jego wymagania.... praktycznie, żaden kupujący, zwykły śmiertelnik, nie będzie w stanie użyć żadnego z narzędzi (i zrozumieć) które wymienił Mateusz...

ale kolejną kwestią jaka się tu natychmiast pojawi jest "jakość wymagań"... i tu osobiście stosuje jedna miarę: zgodność tego co uznano za przydatne z opisem wymagań przed rozpoczęciem projektu.

Temat: Jakość kodu

Jarosław Ż.:
ja mam cały czas wątpliwości co do łączenia "wysokiej jakości" umiejętności kogoś, a jakością produktu jaki ten ktoś tworzy...

Moim zdaniem nie jest to zależność w dwie strony tzn. nie jest prawdziwe:

dobry programista -> tworzy -> dobry projekt

natomiast jest prawdziwe

dobry projekt -> jest tworzony przez -> dobrych programistów

gdzie:
- "dobry" oznacza pewną akceptowalną jakość
- możemy założyć, że każdy z "dobrych programistów" jest nie lepszy niż "dobry programista" (ale to już taka luźna uwaga)

jakość kodu jest wdzięcznym tematem bo często jest ona podnoszona w rozmowach, problem polega na tym, że "kupujący" ma tylko jedną możliwość oceny kodu: jak program spełnia jego wymagania.... praktycznie, żaden kupujący, zwykły śmiertelnik, nie będzie w stanie użyć żadnego z narzędzi (i zrozumieć) które wymienił Mateusz...

I bardzo dobrze, nie taka rola klienta i nie na tym przecież znać się powinien. Dla niego miernikiem jakości jest to czy projekt realizuje ustalone założenia w zadowalającym stopniu oraz to czy oprogramowanie można rozwijać, jak szybko naprawia się błędy, jaka jest wydajność aplikacji.
Z tym, że powyższe są dość subiektywne, więc programiści posiłkują się analizami kodu, dobrymi praktykami oraz technikami, ponieważ to zwiększa (nie jest gwarantem!) szanse na to, że projekt będzie mieścił się w normach jakości klienta.

ale kolejną kwestią jaka się tu natychmiast pojawi jest "jakość wymagań"... i tu osobiście stosuje jedna miarę: zgodność tego co uznano za przydatne z opisem wymagań przed rozpoczęciem projektu.

Jakość wymagań przekłada się bezpośrednio na jakość projektu, w przypadku kodu (w stosunkowo małych projektach) taka zależność niekoniecznie musi zachodzić.
Niestety weryfikowanie jakości wymagań też nie jest łatwym zadaniem :)Ten post został edytowany przez Autora dnia 26.02.14 o godzinie 08:57

Temat: Jakość kodu

Patryk O.:
To ja może odwrócę pytanie: Czy słyszałeś o kodzie dobrej jakości, który nie jest testowalny?

Testowalność jest efektem stworzenia dobrej architektury / dobrej organizacji kodu (umiejętne tworzenie hierachi klas i interfejsów).

Dobry kod jest testowalny, ale to że kod jest testowalny (już nawet pomijając to, że testować można bez sensu czyli tak, jak to się aktualnie najczęściej robi) nie oznacza, że ktoś dobrze zaprojektował system.

Dla mnie to pierwszy i jeden z najważniejszych kroków do zapewniania jakości.

Testowalność nie jest przyczyną, a efektem jakości.
"Jakość" jest dużo szerszym pojęciem od "testowalność".

Jeśli ktoś tworzy architekturę "testowalną" to stworzy architekturę ... testowalną (niekoniecznie dobrej jakości) która potencjalnie nie "służy" funkcjonalności biznesowej.

A może znasz inne bardziej skuteczne sposoby zapewniania jakości?

Sposób jest zawsze ten sam: zbierz zespół kompetentnych ludzi i udostępnij im potrzebne narzędzia / zasoby

Temat: Jakość kodu

Jakub W.:
Testowalność jest efektem stworzenia dobrej architektury / dobrej organizacji kodu (umiejętne tworzenie hierachi klas i interfejsów).

Testowalność może być również efektem przeprowadzonej refaktoryzacji (TDD) i w takim wypadku to testy wpływają na dobrą jakość kodu.
Zdaję sobie sprawę, że dobrze jest mieć projekt kodu, przemyśleć to itp., ale mimo tego nie umniejszałbym wagi testów. Pisanie dużej aplikacji bez testów nie jest moim zdaniem oznaką tego, jak świetni programiści pracują nad kodem, a raczej tego, że są oni niedoświadczeni, jeszcze wierzą, że to ilość linijek kodu jakie uda im się wyprodukować jest miernikiem ich jakości i każda aktywność, która odciąga ich od klawiatury jest uznawana za herezję.

Dobry kod jest testowalny, ale to że kod jest testowalny nie oznacza, że ktoś dobrze zaprojektował system.

Jeżeli testy są pisane przez ludzi, którzy się na tym znają to z pewnością testowalność kodu przekłada się w pewnym stopniu na jego jakość. Ale tak, nie oznacza to, że ktoś dobrze zaprojektował system, bo przecież testowalność może wyniknąć jako następstwo refaktoryzacji, co każe nam przypuszczać, że projekt nie był tak doskonały, jak mogliśmy zakładać.

Testowalność nie jest przyczyną, a efektem jakości.

TDD jest zaprzeczeniem tego co napisałeś - testy piszesz przede wszystkim po to, aby zadbać o jakość kodu.
Oczywiście nie twierdzę, że to co napisałeś nigdy nie jest prawdą, a jedynie, że nie jest nią zawsze.

Jeśli ktoś tworzy architekturę "testowalną" to stworzy architekturę ... testowalną (niekoniecznie dobrej jakości) która potencjalnie nie "służy" funkcjonalności biznesowej.

Tutaj wchodzimy już na kwestię czy kod dobrej jakości = oprogramowanie dobrej jakości i nie ma to już absolutnie nic wspólnego z testowalnością. Jeżeli aplikacja nie realizuje wymagań to jakość oprogramowania (pomimo piękna jakie bije z kodu) jest bardzo mała.

Sposób jest zawsze ten sam: zbierz zespół kompetentnych ludzi i udostępnij im potrzebne narzędzia / zasoby

Brzmi jak Agile :)

Powyższa wypowiedź nie jest stwierdzeniem, że nie można mówić o żadnej jakości, jeżeli nie ma testów. Oczywiście, że można i może się zdarzyć, że aplikacja stworzona bez żadnych dobrych praktyk jest dla klienta bardziej wartościowa niż taka, gdzie przeprowadzono stosowną analizę, zrobiono projekt, jest pokrycie w testach, dbano o code review itp. Pytanie tylko jakie jest prawdopodobieństwo takiego zdarzenia?

Temat: Jakość kodu

Sposób jest zawsze ten sam: zbierz zespół kompetentnych ludzi i udostępnij im potrzebne narzędzia / zasoby

Brzmi jak Agile :)

trafiony :))

Powyższa wypowiedź nie jest stwierdzeniem, że nie można mówić o żadnej jakości, jeżeli nie ma testów.

generalnie jakoś (efektów) pracy polega na tym, że przed jej wykonanie jesteśmy w stanie zadeklarować co powstanie, ta deklaracja powinna być "testem": jak stwierdzimy (obie strony), że wykonaliśmy swoją pracę. Osobną kwestią jest "jakość' bebechów (przypominam, że nasza praca jest dla klianta "czarną skrzynką"): np. benchmarking kosztów rozwoju naszego produktu ...

Temat: Jakość kodu

W pełnie się zgadzam, jeżeli nie wiemy co jest naszym celem i jakie są miary jakości, to maleją nasze szanse na to, że po jakiejkolwiek weryfikacji nadal zadowolimy klienta.

Co do jakości tego, co siedzi w środku, to moim zdaniem przekłada się na jakość produktu, jeżeli miarą jej jest m.in. przyszły rozwój oraz pod warunkiem, że zrealizowano to, co trzeba było zrobić.

Temat: Jakość kodu

Sebastian M.:

Jakub W.:
Testowalność jest efektem stworzenia dobrej architektury / dobrej organizacji kodu (umiejętne tworzenie hierachi klas i interfejsów).

Testowalność może być również efektem przeprowadzonej refaktoryzacji

Pomieszanie z pomyleniem. Zawsze chodzi o "dobrą architekturę" i umiejętność jej tworzenia a to, czy ktoś potrafi ją sobie stworzyć "od razu" czy też "ciągle ją poprawia" (refatoryzacja) to zupełnie inna sprawa.

(TDD) i w takim wypadku to testy wpływają na dobrą jakość kodu.

Co to jest kod (architektura) dobrej jakości ?

Testowalność nie jest przyczyną, a efektem jakości.

TDD jest zaprzeczeniem tego co napisałeś -

może TDD wcale nie jest takie "mądre"...

testy piszesz przede wszystkim po to, aby zadbać o jakość kodu.

To jest absurd. Fakt realizacji pewnej funkcjonalności (przechodzący test) nie ma nic wspólnego z jakością rozwiązania.
BTW: do czego w takim razie służy refaktoryzacja ?

Oczywiście nie twierdzę, że to co napisałeś nigdy nie jest prawdą, a jedynie, że nie jest nią zawsze.

Ok. Co to jest "dobra jakość kodu" ?

Sposób jest zawsze ten sam: zbierz zespół kompetentnych ludzi i udostępnij im potrzebne narzędzia / zasoby

Brzmi jak Agile :)

:-)
Agile to chyba taki sposób rozumowania ...

Temat: Jakość kodu

Jakub W.:

Sebastian M.:
Testowalność może być również efektem przeprowadzonej refaktoryzacji

Pomieszanie z pomyleniem. Zawsze chodzi o "dobrą architekturę" i umiejętność jej tworzenia a to, czy ktoś potrafi ją sobie stworzyć "od razu" czy też "ciągle ją poprawia" (refatoryzacja) to zupełnie inna sprawa.

Oczywiście, że chodzi o dobrą architekturę, z tym, że moja wypowiedź wcale z tym się nie kłóci. Jedyne co napisałem, to że stosowanie TDD (którego integralną częścią jest refaktoryzacja) sprawia, że kod jest coraz bardziej testowalny, a to wpływa pozytywnie na architekturę.
A z racji swoich założeń (Test First) związek zachodzi właśnie w tą stronę: testy -> poprawa architektury

Testowalność nie jest przyczyną, a efektem jakości.

TDD jest zaprzeczeniem tego co napisałeś -

może TDD wcale nie jest takie "mądre"...

testy piszesz przede wszystkim po to, aby zadbać o jakość kodu.

To jest absurd. Fakt realizacji pewnej funkcjonalności (przechodzący test) nie ma nic wspólnego z jakością rozwiązania.
BTW: do czego w takim razie służy refaktoryzacja ?

To co napisałem to: "TDD jest zaprzeczeniem tego co napisałeś - testy piszesz przede wszystkim po to, aby zadbać o jakość kodu." i tylko jako całość zdanie ma sens. Integralną częścią TDD jest refaktoryzajca i poprzez ten proces poprawiamy kod, testy natomiast pozwalają nam wykryć problematyczne elementy kodu.
Jakbym przeczytał swoje zdanie podzielone w sposób zaproponowany przez Ciebie to sam bym się z tą wypowiedzią pewnie nie zgodził.

Co to jest kod (architektura) dobrej jakości ?
[...]
Ok. Co to jest "dobra jakość kodu" ?

więc:

Sebastian M.:

Jarosław Ż.:
Dla mnie jakość kodu (produktu jakim jest program) to np.:
- koszt rozwoju
- koszt utrzymania

Chyba z tym wszyscy się zgodzą.
Jakość kodu to nie są małe metody, kod zgodny z SOLID, pełen wzorców itp.
Obecność ich nie świadczy o jakości, niemniej jednak wydaje mi się,
że w odwrotną stronę taka zależność zachodzi, przynajmniej jeżeli mówimy o
oprogramowaniu napisanym obiektowo.
Po prostu, wykorzystywanie dobrych praktyk pomaga nam utrzymać jakość na jak najwyższym poziomie.Ten post został edytowany przez Autora dnia 27.02.14 o godzinie 14:07

Temat: Jakość kodu

Sebastian M.:
W pełnie się zgadzam, jeżeli nie wiemy co jest naszym celem i jakie są miary jakości, to maleją nasze szanse na to, że po jakiejkolwiek weryfikacji nadal zadowolimy klienta.

Co do jakości tego, co siedzi w środku, to moim zdaniem przekłada się na jakość produktu, jeżeli miarą jej jest m.in. przyszły rozwój oraz pod warunkiem, że zrealizowano to, co trzeba było zrobić.

architektura wewnętrzna jest np. konsekwencją żądania niskich kosztów utrzymania ale jakością jest brak błedów, niski koszt utrzymania to cecha, stosowanie np. dobrych praktyk i wzorców to sposób uzyskania niskich kosztów utrzymania (ale wyższych wytworzenia;)) a nie wysokiej jakosci... ;)

Temat: Jakość kodu

1. nadal nie wiemy co to jest "jakość kodu", bo sama zgodnośc z jakimiś wzorcami to mało..
2. "wysoka jakość" wynikowe kodu można osiągną za pierwszym razem ale za po setnej refaktoryzacji... i tu zgadzam się, ze decyzuja ludzie i ich kompetencje

Temat: Jakość kodu

Jarosław Ż.:
bo już "łatwość korzystania z oprogramowania" to raczej jakość GUI...
Takie rzeczy np. KISS czy SOLID to raczej cechy tego kodu jako całości a nie jakość... owszem te cechy mogą wpływać na jakość ale nie muszą... można zrobić rewelacyjny, zgodny z SOLID itp. program ale kompletnie nikomu do niczego nie przydatny.

Inny przykład: czy tekst ślicznie sformatowany, bez literówek, ładnie podzielony na jasne co do treści rozdziały i podrozdziały, dobrze zilustrowany ale kompletnie nikomu do niczego nie przydatny co co tu jest, i czy w ogóle coś, "wysokiej jakości"?

Kwestia przydatności to kwestia wymagań, które system ma realizować. Można je zrealizować kodem wysokiej jakości albo niskiej. Efektem wysokiej lub niskiej jakości kodu jest wysoki albo niski koszt utrzymania i rozwoju - między innymi, są tez inne cechy.
Jak dla mnie kolejny raz zaglądasz do kuchni i próbujesz tłumaczyć kucharzom, że przepisy i normy BPH i HAACP są nie potrzebne, bo danie ma być "smaczne" i "tanie". Jak chcesz zrozumieć jak działa kuchnia - wpadnij do mnie i Ci pokażę. Jak chcesz rozmawiać o oczekiwaniach klienta restauracji to przestań mi zaglądać na zaplecze.

Temat: Jakość kodu

Mateusz K.:

Jarosław Ż.:
bo już "łatwość korzystania z oprogramowania" to raczej jakość GUI...
Takie rzeczy np. KISS czy SOLID to raczej cechy tego kodu jako całości a nie jakość... owszem te cechy mogą wpływać na jakość ale nie muszą... można zrobić rewelacyjny, zgodny z SOLID itp. program ale kompletnie nikomu do niczego nie przydatny.

Inny przykład: czy tekst ślicznie sformatowany, bez literówek, ładnie podzielony na jasne co do treści rozdziały i podrozdziały, dobrze zilustrowany ale kompletnie nikomu do niczego nie przydatny co co tu jest, i czy w ogóle coś, "wysokiej jakości"?

Kwestia przydatności to kwestia wymagań, które system ma realizować. Można je zrealizować kodem wysokiej jakości albo niskiej. Efektem wysokiej lub niskiej jakości kodu jest wysoki albo niski koszt utrzymania i rozwoju - między innymi, są tez inne cechy.
Jak dla mnie kolejny raz zaglądasz do kuchni i próbujesz tłumaczyć kucharzom, że przepisy i normy BPH i HAACP są nie potrzebne, bo danie ma być "smaczne" i "tanie". Jak chcesz zrozumieć jak działa kuchnia - wpadnij do mnie i Ci pokażę. Jak chcesz rozmawiać o oczekiwaniach klienta restauracji to przestań mi zaglądać na zaplecze.

Masz rację, ale problem tkwi w tym, że Ty znasz siebie, ale ogólnie jest "ryzyko złej jakości" i w relacjach "inwestor - wykonawca" pojawia się na rozwiniętych rynkach "projektant" (rynek budowlany, konstrukcyjny, itp.). Norma HAACP jest deklaracją, że firma stosuje pewne określone wzorce postępowania, ja jednak gdy uznam, że jest ryzyko, wejdę jednak na kuchnie i zrobię Ci audyt zgodności Twojej pracy (mimo, ze obiecujesz tę zgodność) z tą normą, i mogę mieć taki kaprys (i tak się dzieje na rynku spożywczym, farmaceutycznym, budowlanym i IT także, czasem ja taka role pełnię).

Tak więc prawda leży po środku.