🚀 go-pugleaf

Witam

A.L. wrote:

> Ja sie nei wypowiadalem na ich temat. Ja napisalem ze je olewam. Ten
> link powyzej, na przykald, uzywa slow QA ale nic nie ma wspollnego z
> QA, albowiem QA nei zajmuje sie, cytuje, "software metrics". QA
> zajmuje sie zgodnoscia systemu ze specufikacja UZYTKOWA i sposobel w
> jaki owe wymagania UZYTKOWE sa spelnione. czyli patrzy na system okiem
> uzytkownika.

Tak. A to ciekawe. Rozumiem, że Pan pisze tylko zamknięty kod. A co jesli
Pan ma oddać bibliotekę (wraz z jej kodem)?

Jak Pan określi jakość samego kodu? Przyjdzie Pan i powie: "E Mietek, ten
kod jest faftastyczny!". Zaczyna Pan od opisania projektu i wskazania czemu
jest dobry (może nawet lepszy niż inny). Potem wskazuje Pan na realizację.
Dodatkowo wcześniej lub w trakcie wypunktowuje Pan kontekst merytoryczny i
na etapie opisu projektu zaczyna widać czy to jest spełnione czy nie.
Ocena samego kodu jest potrzebna tam gdzie ważny jest aspekt wydajności.
Już nie wspomnę o kwestiach testowania. Itd. itd.

> Firma stosuje "stragehie hype" (jezeli to mowa o powyzszym linku),
> albowiem jak napisalem, QA sie tym nie zajmuje.

A Pan to się na optymalizacji zna, czy tylko picuje? Jak się Pan zna to wie
Pan, że funkcjonały jakości można określać jak się chce. A QA to
sprawdzenie zgodniości specyfikacji z wykonaniem. Czyli minimalizacja błędu
pomiędzy specyfikacją, a tym co Pan robi/zrobił. 
Rozumiem, że taki ideał jak Pan nie popełnia błędów, więc Pana takie
kontrole nie dotyczą. Ale reszta ludzkości popełnia błędy i QA jest
potrzebne.
 
> Pan tez ma te przyware. Ale ejzeli Pan uwaza ze owych grupach ktore
> odwiedzam nei mam racji, zapraszam do polemiki. jak dotad wypowiada
> sie Pan wylacznei na temat C++

Jak widać nie tylko o C++ dyskutujemy i jak widać nie tylko w tym się
niezgadzamy.
 
> Zapewne wiedzialem jeszcze mniej niz pan. Ale: a) nie uwazalem ze
> wiem, b) sluchalem innych

Oczywiście, ale dziś jak Pan nie uważa, że coś Pan wie, to Pana do żadnej
pracy nie przyjmą. To jest numer jeden. Numer dwa często marketing tak
ludziom w głowach miesza, że produkty firmy XYZ są super, a są denne, że
jak Pan nie powie jasno i wyraźnie, że są denne i dlaczego to ogół będzie
uważał, że są super, bo kazdy przecież tego używa.

A co do słuchania innych, to bardzo chętnie słucham innych, kiedy są skorzy
do konstruktywnego odpowiadania na pytania i jeszcze lepiej kiedy do zadań
podchodzą z naturalnym entuzjazmem.

> Nie rozumiem co Pan ma na mysli. Zaden tool nie bedzie mi ocenial kodu
> (niby jak?... Po ilosci linii?...)

A Pan myśli że tylko ilość linii jest oceniana? Jest cała masa ocen, które
np. wskazują na błędy projektowe, albo implementacyjne. Są też takie oceny,
które nie pokazują jawnie błędów, ale można powiedzieć, że tym rejonie
popełniono błąd, albo czasami wykonanie jest dziwne i to warto jakoś
skomentować. Jeśli nie ma komentarza, to znaczy że też jest popełniony błąd
w sztuce.

> i nie bedze go testowal. A poza 
> tym, wie Pan... Unit tests to nie sa jedyne etsty.

A Pan to myśli, że unit testy to koniec? To początek i to zazwyczaj
najłatwiejszy do pokonania.

> Jak dwa moduly sa 
> unit tested, to nie ma zadnej gwarancji ze razem bada dobrze
> pracowaly. 

Zgadza się.

> Do tego sa inni ludzie zwani "testerami" ktorzy robia takie 
> testy wlasnie. W zaleznosci od miejsca ejst to osobna organizacja,
> albo sa wmontowani z development team. W kazdym razie ich jedynym
> zadaniem jest robienie testow funkcjonalnych, integracyjnych,
> regresyjnych itede. Nei maja ci ludzie nic wspolnego z QA, bo QA to
> zupelnie osobna organizacja, i jak pisalem, kodu na oczy nie widzi.
> Powtarzam na wszelki wypadek jeszcze raz.

To zależy. QA jest z boku albo powyżej. Jeszcze raz powtórzę, proszę odnieść
QA, testy i inne do pisania bibliotek, a nie tylko do zamkniętego programu,
który jak działa to jest dobrze.

> Niby ze jakim?... Ja Panu pisze o tym co sie w firmei dzieje na dzis.

W jakiej firmie? A może są inne firmy? A może ktoś mówiąc o jakości mówi o
drzewie jakości, czyli o zbiorze jakości ustalanych na każdym etapie
wdrażania produktu. Jest taka prosta metoda TQM i tam o jakości mówi się na
każdym etapie, na każdym etapie się ją sprawdza i na każdym etapie koryguje
się pracę, aby sprostać wymaganiom jakości. Nie tylko na końcu, kiedy
produkt oddaje się klientowi.

> Dzialo sie tak samo w firmach w ktorych pracowalem poprzenio. Jezeli
> ma Pan jakies recepty na odswiezenie skostnialego przemyslu
> amerykanskiego, prosze rozwinac skrzydla

Są Amerykanie, którzy wskazują, żeby zmieniać podejście do pracy, pracownika
i do produkcji. Są to ludzie o wiele lepiej zaznajomieni z realiami
amerykańskimi niż ja, więc jeśli ich się nie słucha, to tym bardziem moje
spojrzenie jest bezwartościowe. 

A poza tym można się też uczyć na negatywnym przykładzie. Jak się ludziom
mówi, żeby uważali przy frezarce, pile, czy innym ustrojstwie, to każdy
mówi: "co się może wydarzyć?", ale jak pojawi się facet, który ma
poobcinane to czy owo, bo "mu się zdarzyło", to wtedy ludzie są
ostrożniejsi. Więc może lepiej kiedy ktoś popełni na własny koszt błąd, aby
inni mogli "za darmo" go nie popełnić i jeszcze mieć "case study"?
 
> Nie mam zadnych oporow zby przyznac racje komus kto ma racje.

Kto ma rację, czy kto twierdzi to samo co Pan?

> tylko sie okaze ze ma pan racje w jakiejs materii, niezwlocznie owa
> racje Panu przyznam.

Powątpiewam w to. Pan woli, że tak to ujmę sprawę przemilczeć, niż komuś
przyznać rację. Woli Pan wsadzać oponentów do KF zamiast zmierzyć się z
racjami innych.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/