🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: pl.comp.objects
86 messages
86 total messages Page 1 of 2 Started by mgl Thu, 02 Mar 2006 00:26
Page 1 of 2 • 86 total messages
Pomiar metryk kodu w procesie kontroli jakości
#13925
Author: mgl
Date: Thu, 02 Mar 2006 00:26
17 lines
1454 bytes
Witam,

czy ktoś z szanownych tutaj zgromadzonych spotkał się z praktycznym 
wprowadzeniem pomiaru metryk kodu do procesu QA?

Nie mam na myśli np. walidacji standardów kodowania, bo takie narzędzia 
istnieją i to nie tylko jako pomoc dla programistów, ale są też włączane 
  do systemów QA, ale o metryki (liczbowe) kodu i ich systematyczny pomiar.

Byłbym wdzięczny za wskazanie interesujących materiałów lub nawet 
narzędzi, o ile takie są, które uznają pomiar metryk kodu za metodę 
kontroli i usprawnienia procesu wytwarzania oprogramowania. Materiały o 
samych metrykach są mi znane.

pozdrawiam,
-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakości
#13924
Author: mgl
Date: Thu, 02 Mar 2006 00:30
13 lines
1288 bytes
mgl wrote:

> Witam,
> 
> czy ktoś z szanownych tutaj zgromadzonych spotkał się z praktycznym 
> wprowadzeniem pomiaru metryk kodu do procesu QA?

I żeby uciąć potencjalnego flejma razem z pępowiną - nie chodzi mi o 
ocenę takiego rozwiązania, ale o same przykłady konkretnych, wdrożonych 
(albo możliwych do wdrożenia) rozwiązań, których nie znam.

-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakości
#13926
Author: mgl
Date: Thu, 02 Mar 2006 00:59
13 lines
1298 bytes
mgl wrote:

> Witam,
> 
> czy ktoś z szanownych tutaj zgromadzonych spotkał się z praktycznym 
> wprowadzeniem pomiaru metryk kodu do procesu QA?

I żeby uciąć potencjalnego flejma razem z pępowiną - nie chodzi mi o 
ocenę takiego rozwiązania, ale o same przykłady konkretnych, wdrożonych 
(albo możliwych do wdrożenia) rozwiązań, których po prostu nie znam.

-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakości
#13932
Author: Piotr Dembiński
Date: Fri, 03 Mar 2006 22:31
9 lines
1359 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

[...]

> klient mial zyczenie, bysmy uzywali narzedzia takiego jak lint
> (www.gimpel.com) i co wiecej oddawali kod, na ktorym lint nie
> zglasza nawet remark'ow. 

Niezły klient.
Re: Pomiar metryk kodu w procesie kontroli jakości
#13971
Author: Piotr Dembiński
Date: Tue, 07 Mar 2006 20:00
13 lines
1662 bytes
mgl <ask@for.email.com> writes:

[...]

> Zasłyszane: w pewnej dużej znanej firmie z CMM 5 regularnie
> prowadzone są przeglądy kodu, polegające na skrupulatnym czytaniu
> kodu przez trzy osoby linijka po linijce w ustalonym tempie 
> i zatwierdzaniu każdego wiersza z osobna. Oczywiście tak dokładny
> przegląd kodu ma duży sens, jednak raz zatwierdzony kod jest
> zamrażany i "odmrożenie go" do zmian jest procedurą nieprzewidzianą
> w procesie ;).

A kto im ten proces zatwierdził?
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13936
Author: Piotr Dembiński
Date: Tue, 07 Mar 2006 20:02
9 lines
1485 bytes
mgl <ask@for.email.com> writes:

[...]

>  niektórzy pozostają przy dokumentacji, ale dokumentowanie to raczej
> domena CMM2, nie 5 ;).

Na CMM 5 organizacja jest tak samoświadoma, że posiada własną
inteligencję, która nakazuje jej zaprzestać działania :>
Re: Pomiar metryk kodu w procesie kontroli jakości
#13972
Author: mgl
Date: Tue, 07 Mar 2006 21:00
8 lines
1370 bytes
Piotr Dembiński wrote:

> A kto im ten proces zatwierdził?
http://www.google.pl/search?q=cmmi+certification

pozdrawiam,
-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakości
#13984
Author: Miros/law L. Baran
Date: Tue, 07 Mar 2006 21:17
17 lines
1700 bytes
PT Aleksander Galicki pisze:

> Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze odpowiednio 
> sofisticated language. Np C++. No bo nie kazdy jezyk daje tak wypasione 
> enterprise-ready mozliwosci jak "out-of-bounds array access" albo "buffer 
> overflows".

Może Cię to zaskoczy, ale w pewnych produktach na pewnym poziomie
trudno jest zastąpić C/C++ haskellem.

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] 

                    DMSACC112S ' A (191) ' DEVICE ERROR
Re: Pomiar metryk kodu w procesie kontroli jakości
#13973
Author: Piotr Dembiński
Date: Tue, 07 Mar 2006 21:44
22 lines
2054 bytes
mgl <ask@for.email.com> writes:

> Piotr Dembiński wrote:
>
>> A kto im ten proces zatwierdził?
> http://www.google.pl/search?q=cmmi+certification

Oj, już wiem, dlaczego tak jest i dlaczego to jest dobre.  Po prostu
zamiast modyfikować istniejący artefakt z błędami, tworzy się nowy.

Przyjmijmy, że w artefakcie istnieje nie zauważony w wielu
szczegółowych inspekcjach błąd.  Oznacza to, że najprawdopodobniej
coś jest nie w porządku z całym artefaktem, a nie tylko z tymi 
kilkoma linijkami, w których znajduje się błąd.

Jeśli natomiast jest rozważane użycie artefaktu w nowym
przedsięwzięciu, ale nie spełnia on założeń, to też tworzy się nowy,
bazując na doświadczeniu zdobytym podczas tworzenia poprzedniego
artefaktu.  Tak to widzę.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakości
#14173
Author: Aleksander Galicki
Date: Tue, 07 Mar 2006 21:50
26 lines
2095 bytes
>PT Aleksander Galicki pisze:
>
>> Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze odpowiednio 
>> sofisticated language. Np C++. No bo nie kazdy jezyk daje tak wypasione 

> enterprise-ready mozliwosci jak "out-of-bounds array access" albo "buffer 

>> overflows".
>
>Może Cię to zaskoczy, ale w pewnych produktach na pewnym poziomie
>trudno jest zastąpić C/C++ haskellem.
>

Pan najwyrazniej mnie pomylil z jakims innym grupowiczem. U mnie w firmie jest 
JEE i .NET, a wczesniej Smalltalk, a nie Haskell. Nie mam tez problemu z 
zamiana C++ na cos innego, bo nie grzebie w legacy systems. No i nasi klienci 
zwykle maja "architecture guidelines", ktore dokladnie mowia jakich jezykow 
mozemy uzywac w nowych projektach. C++ nie mozemy.  
A poza tym o co chodzi z "w pewnych produktach na pewnym poziomie"? 


A.
-- 
============= P o l N E W S ==============
     archiwum i przeszukiwanie newsów
        http://www.polnews.pl
Re: Pomiar metryk kodu w procesie kontroli jako¶ci
#13985
Author: AL.
Date: Tue, 07 Mar 2006 21:54
17 lines
1634 bytes
On Tue, 7 Mar 2006 21:17:29 +0000 (UTC), "Miros/law L. Baran"
<baran@hell.pl> wrote:

>PT Aleksander Galicki pisze:
>
>> Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze odpowiednio 
>> sofisticated language. Np C++. No bo nie kazdy jezyk daje tak wypasione 
>> enterprise-ready mozliwosci jak "out-of-bounds array access" albo "buffer 
>> overflows".
>
>Mo¿e Ciê to zaskoczy, ale w pewnych produktach na pewnym poziomie
>trudno jest zast±piæ C/C++ haskellem.
>

Mnie zas zaskakuje ze ktos jeszcze do czegos uzywa C++.

A.L.
Re: Pomiar metryk kodu w procesie kontroli jako¶ci
#14174
Author: AL.
Date: Tue, 07 Mar 2006 22:05
27 lines
2101 bytes
On Tue, 07 Mar 2006 22:50:58 +0100, "Aleksander Galicki" <no@no.com>
wrote:

>>PT Aleksander Galicki pisze:
>>
>>> Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze odpowiednio 
>>> sofisticated language. Np C++. No bo nie kazdy jezyk daje tak wypasione 
>
>> enterprise-ready mozliwosci jak "out-of-bounds array access" albo "buffer 
>
>>> overflows".
>>
>>Mo¿e Ciê to zaskoczy, ale w pewnych produktach na pewnym poziomie
>>trudno jest zast±piæ C/C++ haskellem.
>>
>
>Pan najwyrazniej mnie pomylil z jakims innym grupowiczem. U mnie w firmie jest 
>JEE i .NET, a wczesniej Smalltalk, a nie Haskell. Nie mam tez problemu z 
>zamiana C++ na cos innego, bo nie grzebie w legacy systems. No i nasi klienci 
>zwykle maja "architecture guidelines", ktore dokladnie mowia jakich jezykow 
>mozemy uzywac w nowych projektach. C++ nie mozemy.  
>A poza tym o co chodzi z "w pewnych produktach na pewnym poziomie"? 

Chodzi o poziom sofistykacji projektow wykonywanych przez Pana Barana.
I o poziom jego pogardy dla "akademikow".

A.L.
Re: Pomiar metryk kodu w procesie kontroli jakości
#13986
Author: Miros/law L. Baran
Date: Tue, 07 Mar 2006 22:13
24 lines
2034 bytes
AL pisze:
> On Tue, 7 Mar 2006 21:17:29 +0000 (UTC), "Miros/law L. Baran"
> <baran@hell.pl> wrote:

> > > Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze
> > > odpowiednio sofisticated language. Np C++. No bo nie kazdy jezyk
> > > daje tak wypasione enterprise-ready mozliwosci jak "out-of-bounds
> > > array access" albo "buffer overflows".

> > Może Cię to zaskoczy, ale w pewnych produktach na pewnym poziomie
> > trudno jest zastąpić C/C++ haskellem.

> Mnie zas zaskakuje ze ktos jeszcze do czegos uzywa C++.

Cóż poradzić. Aż mi się wstyd zrobiło, że w tak nieprofesjonalnych
okolicach bywam.

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] 

                 Ninety percent of everything is bullshit.
Re: Pomiar metryk kodu w procesie kontroli jakości
#14175
Author: Miros/law L. Baran
Date: Tue, 07 Mar 2006 22:20
33 lines
2379 bytes
AL pisze:
> > Pan najwyrazniej mnie pomylil z jakims innym grupowiczem. U mnie w
> > firmie jest JEE i .NET, a wczesniej Smalltalk, a nie Haskell. Nie
> > mam tez problemu z zamiana C++ na cos innego, bo nie grzebie w
> > legacy systems.

Embedded to też legacy? ;-)

> > No i nasi klienci zwykle maja "architecture guidelines", ktore
> > dokladnie mowia jakich jezykow mozemy uzywac w nowych projektach.
> > C++ nie mozemy.  A poza tym o co chodzi z "w pewnych produktach na
> > pewnym poziomie"? 

...at, są takie różne miejsca, gdzie wciąż wykorzystuje się C/C++,
choćby do napisania sterowników.

> Chodzi o poziom sofistykacji projektow wykonywanych przez Pana Barana.

Ja, dzięki Najwyższemu, żadnym poważnym programowaniem się nie zajmuję,
programistą nie jestem i nie będę, dzięki czemu światu oszczędzony jest
fatalnej jakości kod, jaki niewątpliwie byłbym generował.

> I o poziom jego pogardy dla "akademikow".

...i mój poziom pogardy jest raczej selektywny.

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, http://hell.pl/baran/tek/, alchemy pany! ] [ The Answer ] 

                         To add insult to injury.
Re: Pomiar metryk kodu w procesie kontroli jako¶ci
#14176
Author: AL.
Date: Tue, 07 Mar 2006 22:44
13 lines
1712 bytes
On Tue, 7 Mar 2006 22:20:32 +0000 (UTC), "Miros/law L. Baran"
<baran@hell.pl> wrote:
 
>
>> Chodzi o poziom sofistykacji projektow wykonywanych przez Pana Barana.
>
>Ja, dziêki Najwy¿szemu, ¿adnym powa¿nym programowaniem siê nie zajmujê,
>programist± nie jestem i nie bêdê, dziêki czemu ¶wiatu oszczêdzony jest
>fatalnej jako¶ci kod, jaki niew±tpliwie by³bym generowa³.

Czy ja pisalem gdzies o programowaniu?...

A.L.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13966
Author: Piotr Dembiński
Date: Wed, 08 Mar 2006 22:33
10 lines
1632 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

[...]

> programisci nie znali nawet wymagan; designu i choc namiastek
> dokumentacji nie bylo, a tylko co jakis czas przychodzil szef 
> i mowil "zrob taki dialog z dwoma czekboksami i zeby wyswietlal
> drzewko z opcjami i niech sie to uruchamia jak nacisne Ctrl+J". 

Taki szef to skarb, nie człowiek.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13941
Author: Piotr Dembiński
Date: Wed, 08 Mar 2006 22:44
21 lines
2153 bytes
mgl <ask@for.email.com> writes:

[...]

> kto pracował w "dojrzałym procesie", a CMM 5 to stan bliski
> przekwitnięcia z punktu widzenia szarego developera, ten wielu
> rzeczy może się domyślać.

Widzisz, normy jakości ISO też można wprowadzać 'odgórnie', na mocy
zarządzenia, tyle że to nie jest tak, jak to powinno być robione.
Prawdziwa siła systemu ujawnia się dopiero wtedy, gdy wszyscy
pracownicy wierzą w jego skuteczność i go zinternalizują.

Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
uczono mnie raczej, że w polskich warunkach firmy wytwarzające
oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
Polaków, świat zewnętrzny) po prostu nie sprawdzać.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13942
Author: Muchomor
Date: Wed, 08 Mar 2006 23:22
25 lines
2804 bytes
""Piotr Dembiński"" wrote
> mgl <ask@for.email.com> writes:
>
> Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
> uczono mnie raczej, że w polskich warunkach firmy wytwarzające
> oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
> ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
> Polaków, świat zewnętrzny) po prostu nie sprawdzać.

Pozwol, ze zapytam - kto Cie uczyl? Ktos kto przeczytal 473894238 ksiazek i 
niewiele zrozumial, czy ktos kto zeby zjadl na produkcji oprogramowania na 
wszystkich poziomach? Tez mialem kiedys na studiach inzynierie 
oprogramowania. Zajecia prowadzil pan, ktoremu w zyciu nie wyszlo. Teraz 
zajecia prowadzi moj kolega z roku. Zostal na doktorat bo sie do niczego nie 
nadawal. A ja sie na interview dziwie, ze z roku na roku coraz mniej kumaci 
ludzie przychodza.
O mentalnosci Polakow i podejsciu do pracy nie bede sie wypowiadal bo sie 
nie chce zagotowac zanim pojde spac. Natomiast wiem jedno - kolejne poziomy 
do 5 wlacznie i dalej jako CMMI mozna spokonie, bez obaw zdobywac. Potrzeba 
tylko odpowiednich ludzi do realizacji tych celow. Banalne, ale jak 
prawdziwe...

pzdr
Muchomor 
Re: Pomiar metryk kodu w procesie kontroli jakości
#13974
Author: Sektor van Skijlen
Date: Thu, 09 Mar 2006 16:43
60 lines
4669 bytes
Dnia Tue, 07 Mar 2006 00:19:35 +0100, mgl skrobie:
> Muchomor wrote:
> > Uzywamy InForce (http://www.klocwork.com/products/inforce.asp).

> Korzystacie z tego z poziomu IDE?
> Czy podłączyliście może do automatycznego buildowania?

Jejku, co to za różnica.

> Heh, taka cena "dojrzałości procesu" ;). Zasłyszane: w pewnej dużej 
> znanej firmie z CMM 5 regularnie prowadzone są przeglądy kodu, 
> polegające na skrupulatnym czytaniu kodu przez trzy osoby linijka po 
> linijce w ustalonym tempie i zatwierdzaniu każdego wiersza z osobna. 
> Oczywiście tak dokładny przegląd kodu ma duży sens, jednak raz 
> zatwierdzony kod jest zamrażany i "odmrożenie go" do zmian jest 
> procedurą nieprzewidzianą w procesie ;). Dochodzi więc do sytuacji, gdy 
> ktoś pracuje z kawałkiem kodu, który ma już kilka lat i o którym nie ma 
> żadnej wiedzy, i nagle okazuje się, że dokumentacja danego interfejsu 
> jest zbyt mało wyczerpująca - nie wiadomo do końca, jak dane metody 
> rzeczywiście działają, a do kodu zbliżyć się nie można. Taki lajf, gdy 
> procedur pełno - skomplikowany proces na pewno nie ułatwia pracy ;)

Zgadza się.

W praktyce zaś, im bardziej dokładny proces, tym częściej się go obchodzi.
Taka zasada panuje zawsze i kto twierdzi, że udało mu się doprowadzić do
stuprocentowego wypełniania procesu, to jest po prostu naiwny.

A tak się składa, że mam kilkuletnią praktykę z firmą z CMM 5. I rzeczy, o
których kolega pisze są jedną wielką fikcją. Po pierwsze, przeglądy kodu są
prowadzone nie "regularnie", tylko po zakończeniu opracowywania (i najczęściej
też wstępnym przetestowaniu) określonej zmiany w kodzie. Po drugie, kodu nie
przegląda się linijka po linijce, tylko "funkcjonalnie"; czyta się, co kod
robi, opisuje się słownie intencję autora, określa się logicznie operacje,
jakie ma wykonać tak opisany kod.

A już twierdzenie, że kod jest zamrożony to jest dosłownie szurnięte. Kod
zamrożony? Jeżeli kod jest zamrożony, to znaczy, że nadaje się wyłacznie do
kosza. Niby jak do kodu potem mają być dodawane nowe ficzery? Zresztą, co tam
ficzery; w jaki sposób poprawia się błędy znalezione przez SST? Co więcej, jeśli
ktoś przypadkiem na inspekcji zauważy błąd, którego do tej pory nikt nie
wykrył, i to błąd, który nie został wprowadzony wraz z ostatnią poprawką -
poprawia się go również! Dotyczy to również niejasnych komentarzy, literówek w
komentarzach itp.

Inspekcja służy do zatwierdzenia zmian, ale wykrywanie błędów na inspekcji to
fikcja. Statystyki wykryć błędów przez inspekcje są mizerniutkie. I słusznie,
bo inspekcja ma się skupić na kwestii CZYTELNOŚCI kodu i jasności jego
intencji. Właśnie po to, żeby było łatwo później go modyfikować i wprowadzać
poprawki, w tym również poprawki błędów. Ma zabezpieczać również przed
przedostawaniem się do kodu głupich pomysłów. Nic więcej. Gdybyśmy po takiej
inspekcji "zamrażali" kod, to taka inspekcja byłaby w ogóle pozbawiona
jakiegokolwiek sensu.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13967
Author: Sektor van Skijlen
Date: Thu, 09 Mar 2006 16:51
24 lines
2412 bytes
Dnia Tue, 07 Mar 2006 21:59:40 +0100, mgl skrobie:
> Muchomor wrote:
> > 4 osoby, no chyba, ze chodzi Ci o 3 + autor.
> [..]
> > a to juz nieprawda.

> Mówisz o Motoroli Kraków? Bo ja nie, aczkolwiek kilka wesołych historii 
> od ludzi, którzy akurat tam wykuwają pieczołowicie PKB też znam ;).

Ja też znam i co?

Zresztą, nie sądzę, żeby się to różniło od wielu innych firm. Nie słyszałem
jeszcze, żeby ktokolwiek powiedział, że mu proces "nie przeszkadza", albo że
"skutecznie minimalizuje defekty przy minimalnym narzucie formalnym".
Zazwyczaj narzutu formalnego jest w xuj, z tym tylko, że daje się odpowiednio
sprytnie to zminimalizować, jeśli ma się odrobinę "inwencji" (po prostu nie
używając niektórych ficzerów procesu; bynajmniej nie przez obchodzenie
procesu).

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakości
#13975
Author: mgl
Date: Thu, 09 Mar 2006 17:09
53 lines
3939 bytes
Sektor van Skijlen wrote:
>>Korzystacie z tego z poziomu IDE?
>>Czy podłączyliście może do automatycznego buildowania?
> 
> Jejku, co to za różnica.

Tak, jak ślepemu bez różnicy, czy słońce za oknem.
Ale wypada podziękować: "jejku, dziękuję za niezwykle wartościowy 
komentarz" (nie, nie mam na imię Lucjan)

> A tak się składa, że mam kilkuletnią praktykę z firmą z CMM 5. I rzeczy, o
> których kolega pisze są jedną wielką fikcją. Po pierwsze, przeglądy kodu są
> prowadzone nie "regularnie", tylko po zakończeniu opracowywania (i najczęściej
> też wstępnym przetestowaniu) określonej zmiany w kodzie. Po drugie, kodu nie
> przegląda się linijka po linijce, tylko "funkcjonalnie"; czyta się, co kod
> robi, opisuje się słownie intencję autora, określa się logicznie operacje,
> jakie ma wykonać tak opisany kod.

A ja mam psa i dwa koty. Jeśli rzeczywiście masz jakieś doświadczenie w 
temacie i spojrzenie szersze niż developer to powinienneś wiedzieć, że 
CMM(I) nie określa metod przeglądu kodu, ale przede wszystkim cechy i 
cele, jakie powinien realizować przyjęty proces. Te kilka lat to raczej 
chyba przy klawiaturze i kodowaniu kolejnych CR, a nie w QA, co?

> A już twierdzenie, że kod jest zamrożony to jest dosłownie szurnięte. Kod
> zamrożony? Jeżeli kod jest zamrożony, to znaczy, że nadaje się wyłacznie do
> kosza. Niby jak do kodu potem mają być dodawane nowe ficzery? Zresztą, co tam
> ficzery; w jaki sposób poprawia się błędy znalezione przez SST?

Chyba ktoś nie zakumał treści... :) No ale taka karma widać.
Obrazowo: jak wkładasz do zamrażarki mięso, to już nigdy z niego pożytku 
nie masz?

Powiedz mi jeszcze, w czym Ty piszesz, że nie możesz łatwo ficzerów 
dodawać do, mówiąc piłkarsko, "stałych fragmentów kodu"?

> Inspekcja służy do zatwierdzenia zmian, ale wykrywanie błędów na inspekcji to
> fikcja. Statystyki wykryć błędów przez inspekcje są mizerniutkie. I słusznie,
> bo inspekcja ma się skupić na kwestii CZYTELNOŚCI kodu i jasności jego
> intencji. Właśnie po to, żeby było łatwo później go modyfikować i wprowadzać
> poprawki, w tym również poprawki błędów. Ma zabezpieczać również przed
> przedostawaniem się do kodu głupich pomysłów. Nic więcej. Gdybyśmy po takiej
> inspekcji "zamrażali" kod, to taka inspekcja byłaby w ogóle pozbawiona
> jakiegokolwiek sensu.

Ale WY (to ten słynny Układ?) nie jesteście źródłem tej historyjki. Na, 
jak rozumiem, Motorolce i TETRZE świat się nie kończy :).

ogólnie: lol, komuś się tu wylewa ego... :)

równie wesołej lektury,
-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13956
Author: Sektor van Skijlen
Date: Thu, 09 Mar 2006 17:13
65 lines
4914 bytes
Dnia Wed, 08 Mar 2006 23:44:16 +0100, Piotr Dembiński skrobie:
> mgl <ask@for.email.com> writes:

> [...]

> > kto pracował w "dojrzałym procesie", a CMM 5 to stan bliski
> > przekwitnięcia z punktu widzenia szarego developera, ten wielu
> > rzeczy może się domyślać.

> Widzisz, normy jakości ISO też można wprowadzać 'odgórnie', na mocy
> zarządzenia, tyle że to nie jest tak, jak to powinno być robione.
> Prawdziwa siła systemu ujawnia się dopiero wtedy, gdy wszyscy
> pracownicy wierzą w jego skuteczność i go zinternalizują.

Może kolega mi najpierw wyjaśni co oznacza to trudne słowo?

Normy jakości TRZEBA wprowadzać - z głową, oczywiście, choć konstatacja to
zgoła banalna; w końcu zwykle w całym procesie prowadzenia biznesu raczej nie
powinno się robić nic bez głowy. Wiara pracowników nic do tego nie ma, chyba
że przewidujemy utworzenie firmy, w której wszyscy pracownicy składają się z
fanatycznych wyznawców jakiejś "czołobitnej" religii (tzn. takiej, w której
rozważanie wszelkich jej aspektów jest zabronione pod karą).

Pracownik nie ma "wierzyć w skuteczność"; pracownik ma się dostosować do
zaleceń, albo poszukać sobie innego zajęcia. Jeśli jakiś mądrala twierdzi
inaczej, to znaczy, że też powinien sobie poszukać innego zajęcia, najlepiej
rencista.

> Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
> uczono mnie raczej, że w polskich warunkach firmy wytwarzające
> oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
> ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
> Polaków, świat zewnętrzny) po prostu nie sprawdzać.

Ja p... co za żałosne bzdury! Pochwal się może, na jakiej uczelni to
słyszałeś, będzie wiadomo, które uczelnie należy omijać szerokim łukiem.

CMM level 2 to jest to, co powinna posiadać KAŻDA BEZ WYJĄTKU firma, jeśli w
ogóle ma zamiar utrzymać się na rynku bez dotacji i nie zostać po pół roku
zrównana z ziemią i posypana solą. CMM 2 to jest to, od czego firmy powinny
STARTOWAĆ. CMM 1 to jest poziom typu "ja ze szwagrem". Jeśli ktoś tego nie
rozumie i tłumaczy studentom takie bzdury, powinien wylecieć jak najszybciej
na zbity pysk.

CMM 5 w stosunku do 4 wprowadza tzw. proces ulepszania procesu. Posiadanie
takiego procesu jest dla firmy czymś idealnym, bo pozwala dostosować proces do
specyfiki prowadzonych projektów, a tym samym dostosować go tak, aby lepiej
spełniał postawione przed nim wymagania (minimum defektów przy minimalnych
kosztach).

Jeśli takie coś ma się nie sprawdzać w naszych realiach, to mogę jedynie
powiedzieć, że owszem, jeśli takich idiotów wpuszczają na katedrę, to
zatrudniająca ich instytucja na pewno nie będzie mogła wprowadzić żadnych
kontroli jakości. Ja ze swojej strony, pracując w oddziale amerykańskiej
firmy, zauważyłem że to częściej Amerykanie mają większe problemy z
dotrzymaniem jakości, niż Polacy (z prostej przyczyny: Polacy muszą wyłazić ze
skóry, żeby pokazać, jak potrafią być dobrzy, a Amerykanie, czujący nad
Polakami wyższość, muszą pokazać, jak potrafią być nonszalanccy).


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13957
Author: mgl
Date: Thu, 09 Mar 2006 17:29
58 lines
4236 bytes
Sektor van Skijlen wrote:
> Pracownik nie ma "wierzyć w skuteczność"; pracownik ma się dostosować do
> zaleceń, albo poszukać sobie innego zajęcia. Jeśli jakiś mądrala twierdzi
> inaczej, to znaczy, że też powinien sobie poszukać innego zajęcia, najlepiej
> rencista.

Hehe, zdolności kierowniczych to nie masz... ;)

> CMM level 2 to jest to, co powinna posiadać KAŻDA BEZ WYJĄTKU firma, jeśli w
> ogóle ma zamiar utrzymać się na rynku bez dotacji i nie zostać po pół roku
> zrównana z ziemią i posypana solą. CMM 2 to jest to, od czego firmy powinny
> STARTOWAĆ. CMM 1 to jest poziom typu "ja ze szwagrem". Jeśli ktoś tego nie
> rozumie i tłumaczy studentom takie bzdury, powinien wylecieć jak najszybciej
> na zbity pysk.

Zapomniałeś tylko zwrócić uwagę na tę, że czysty RUP plasuje się w 
okolicach CMM 2-, a w wielu firmach, nie tylko polskich, dyscyplina 
przyjętego procesu jest od RUPowskiej, delikatnie mówiąc, odległa.

"Wskakiwanie" w takich firmach na CMM 5 niechybnie skończyłoby się 
wrzodami u większości załogi.

> CMM 5 w stosunku do 4 wprowadza tzw. proces ulepszania procesu. Posiadanie
> takiego procesu jest dla firmy czymś idealnym, bo pozwala dostosować proces do
> specyfiki prowadzonych projektów, a tym samym dostosować go tak, aby lepiej
> spełniał postawione przed nim wymagania (minimum defektów przy minimalnych
> kosztach).

"Czymś idealnym" to wiesz... jest okrag, matematyczny :).
Czy faktycznie pomiar procesu, mówiąc brzydko, przyczynia się do jego 
poprawy - to zależy przede wszystkim od ludzi za to odpowiedzialnych. 
Teoria jest wprawdzie szczytna i miejscami jestem jej fanem, ale wiele 
firm nie potrzebuje po prostu choćby niezwykle szczegółowej dokumentacji 
procesu - projekty trwają zbyt krótko albo są zbyt różne, żeby na 
podstawie zgromadzonych danych można było wyciągać jakieś daleko idące, 
a przede wszystkim biznesowo opłacalne wnioski.

A jak już jesteśmy przy biznesie - zachowanie dyscypliny CMM od poziomu 
4 robi się dosyć drogą zachcianką.

> Jeśli takie coś ma się nie sprawdzać w naszych realiach, to mogę jedynie
> powiedzieć, że owszem, jeśli takich idiotów wpuszczają na katedrę, to
> zatrudniająca ich instytucja na pewno nie będzie mogła wprowadzić żadnych
> kontroli jakości.

Ostre słowa, chyba nieuzasadnione.

> Ja ze swojej strony, pracując w oddziale amerykańskiej
> firmy, zauważyłem że to częściej Amerykanie mają większe problemy z
> dotrzymaniem jakości, niż Polacy (z prostej przyczyny: Polacy muszą wyłazić ze
> skóry, żeby pokazać, jak potrafią być dobrzy, a Amerykanie, czujący nad
> Polakami wyższość, muszą pokazać, jak potrafią być nonszalanccy).

Mit Hameryki ciągle żywy ;).

pozdrawiam,
-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13968
Author: mgl
Date: Thu, 09 Mar 2006 17:43
30 lines
2577 bytes
Sektor van Skijlen wrote:
>>Mówisz o Motoroli Kraków? Bo ja nie, aczkolwiek kilka wesołych historii 
>>od ludzi, którzy akurat tam wykuwają pieczołowicie PKB też znam ;).
> 
> 
> Ja też znam i co?

No nie wiem. Sam coś wymyśl.

> Zresztą, nie sądzę, żeby się to różniło od wielu innych firm. Nie słyszałem
> jeszcze, żeby ktokolwiek powiedział, że mu proces "nie przeszkadza", albo że
> "skutecznie minimalizuje defekty przy minimalnym narzucie formalnym".

Chyba masz mało świadomych współpracowników. W wielu firmach, które mają 
problem z niedbałością wynikającą z procesu, propozycje zmian i ulepszeń 
wychodzą właśnie od szeregowych pracowników, bo to oni w tym bagnie 
pracują. No ale Ty byś ich, jak zrozumiałem z innego postu, z miejsca z 
pracy zwolnił. Dlaczego?? :)

> Zazwyczaj narzutu formalnego jest w xuj, z tym tylko, że daje się odpowiednio
> sprytnie to zminimalizować, jeśli ma się odrobinę "inwencji" (po prostu nie
> używając niektórych ficzerów procesu; bynajmniej nie przez obchodzenie
> procesu).

Przyznaję się, że nie zrozumiałem. Niepełna realizacja procesu równa się 
realizacji jakiegoś innego procesu. To się nazywa kombinatorstwo, a nie 
"inwencja", nie? ;)

-- 
mgl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13948
Author: Piotr Dembiński
Date: Thu, 09 Mar 2006 18:15
44 lines
3473 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

> ""Piotr Dembiński"" wrote
>> mgl <ask@for.email.com> writes:
>>
>> Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
>> uczono mnie raczej, że w polskich warunkach firmy wytwarzające
>> oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
>> ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
>> Polaków, świat zewnętrzny) po prostu nie sprawdzać.
>
> Pozwol, ze zapytam - kto Cie uczyl? 

Prof. Nawrocki.  I wiem, że jeśli chodzi o poglądy, to ma on
w tzw. środowisku przeciwników.

> Ktos kto przeczytal 473894238 ksiazek i niewiele zrozumial, czy ktos
> kto zeby zjadl na produkcji oprogramowania na wszystkich poziomach?
> Tez mialem kiedys na studiach inzynierie oprogramowania. Zajecia
> prowadzil pan, ktoremu w zyciu nie wyszlo. Teraz zajecia prowadzi
> moj kolega z roku. Zostal na doktorat bo sie do niczego nie
> nadawal. A ja sie na interview dziwie, ze z roku na roku coraz mniej
> kumaci ludzie przychodza.

O jakości kształcenia możemy ewentualnie porozmawiać 
na pl.soc.edukacja.  Tutaj chciałbym jedynie przypomnieć, 
że studiowanie nie polega jedynie na wkuwaniu tego, co wykładowca
powie podczas zajęć, ale zwykle wymaga również własnej inicjatywy
w zdobywaniu wiedzy i umiejętności.

> O mentalnosci Polakow i podejsciu do pracy nie bede sie wypowiadal
> bo sie nie chce zagotowac zanim pojde spac. Natomiast wiem jedno -
> kolejne poziomy do 5 wlacznie i dalej jako CMMI mozna spokonie, bez
> obaw zdobywac. Potrzeba tylko odpowiednich ludzi do realizacji tych
> celow. Banalne, ale jak prawdziwe...

Sam potwierdziłeś to, co napisałem: brak odpowiednich ludzi, czyli 
po mojemu kłopoty z mentalnością przeciętnego pracownika.  Od siebie
tylko dodam, że wolałbym, aby każda polska firma softłerowa była
certyfikowana na poziomie powtarzalnym, zamiast żeby było jedynie
kilkanaście na poziomie piątym, a reszta na wstępnym.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13963
Author: Piotr Dembiński
Date: Thu, 09 Mar 2006 18:52
51 lines
3504 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

> Dnia Wed, 08 Mar 2006 23:44:16 +0100, Piotr Dembiński skrobie:
>> mgl <ask@for.email.com> writes:
>
>> [...]
>
>> > kto pracował w "dojrzałym procesie", a CMM 5 to stan bliski
>> > przekwitnięcia z punktu widzenia szarego developera, ten wielu
>> > rzeczy może się domyślać.
>
>> Widzisz, normy jakości ISO też można wprowadzać 'odgórnie', na mocy
>> zarządzenia, tyle że to nie jest tak, jak to powinno być robione.
>> Prawdziwa siła systemu ujawnia się dopiero wtedy, gdy wszyscy
>> pracownicy wierzą w jego skuteczność i go zinternalizują.
>
> Może kolega mi najpierw wyjaśni co oznacza to trudne słowo?

Z dziką rozkoszą.  To jest określenie z psychologii społecznej, które
oznacza, że jednostka przymuje pewien nawyk, zachowanie lub postawę
jako własną, nierozerwalnie związaną ze sobą.

[...]

>> Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
>> uczono mnie raczej, że w polskich warunkach firmy wytwarzające
>> oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
>> ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
>> Polaków, świat zewnętrzny) po prostu nie sprawdzać.
>
> Ja p... co za żałosne bzdury! Pochwal się może, na jakiej uczelni 
> to słyszałeś, będzie wiadomo, które uczelnie należy omijać szerokim
> łukiem.

Moja jakoś nie jest omijana.  Chociaż najpopularniejsza też nie jest.
Poza tym ja już skończyłem studiowanie, a to, co piszę to moje własne
poglądy, które mogą być zbieżne z tym, czego się dowiedziałem i co
usłyszałem podczas studiów.

> CMM level 2 to jest to, co powinna posiadać KAŻDA BEZ WYJĄTKU firma,
> jeśli w ogóle ma zamiar utrzymać się na rynku bez dotacji i nie
> zostać po pół roku zrównana z ziemią i posypana solą. CMM 2 to jest
> to, od czego firmy powinny STARTOWAĆ. CMM 1 to jest poziom typu "ja
> ze szwagrem". 

Mniej więcej to samo -- tyle że w mniej ostrym stylu -- napisałem 
w odpowiedzi na post Muchomora.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13958
Author: Piotr Dembiński
Date: Thu, 09 Mar 2006 18:55
17 lines
1978 bytes
mgl <ask@for.email.com> writes:

[...]

> Zapomniałeś tylko zwrócić uwagę na tę, że czysty RUP plasuje się w
> okolicach CMM 2-, a w wielu firmach, nie tylko polskich, dyscyplina
> przyjętego procesu jest od RUPowskiej, delikatnie mówiąc, odległa.
>
> "Wskakiwanie" w takich firmach na CMM 5 niechybnie skończyłoby się
> wrzodami u większości załogi.

Poza tym u nas chyba nie ma popytu na oprogramowanie opracowywane 
w przedsiębiorstwach certyfikowanych na CMM 5.  Takie przedsiębiorstwa
musiałyby pracować dla podmiotów zagranicznych.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13965
Author: Piotr Dembiński
Date: Thu, 09 Mar 2006 19:07
9 lines
1636 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

[...]

> Swoja droga to jest mozliwe tylko w Polsce by firma bez praktycznej
> organizacji produkcji (w teorii maja ISO)

Jeśli mają ISO 9000-3, to nie tylko w teorii, ale też w praktyce.  
Inaczej nikt by ich nie certyfikował.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13949
Author: Muchomor
Date: Thu, 09 Mar 2006 19:15
64 lines
4322 bytes
""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message 
news:87hd67a3hh.fsf@hector.domek...
> "Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:
>
>> ""Piotr Dembiński"" wrote
>>> mgl <ask@for.email.com> writes:
>>>
>>> Co do CMM, to IMO nie można 'wskakiwać' na poziom 5.  Na studiach
>>> uczono mnie raczej, że w polskich warunkach firmy wytwarzające
>>> oprogramowanie powinny dążyć do osiągnięcia poziomu drugiego,
>>> ew. trzeciego, bo wyższe mogą się w naszych realiach (mentalność
>>> Polaków, świat zewnętrzny) po prostu nie sprawdzać.
>>
>> Pozwol, ze zapytam - kto Cie uczyl?
>
> Prof. Nawrocki.  I wiem, że jeśli chodzi o poglądy, to ma on
> w tzw. środowisku przeciwników.

nie mialem przyjemnosci. BTW poza pracami K. Czarneckiego nie spotkalem 
niczego co by bylo dzielem naszego rodaka i bylo interesujace w SE.

>
>> Ktos kto przeczytal 473894238 ksiazek i niewiele zrozumial, czy ktos
>> kto zeby zjadl na produkcji oprogramowania na wszystkich poziomach?
>> Tez mialem kiedys na studiach inzynierie oprogramowania. Zajecia
>> prowadzil pan, ktoremu w zyciu nie wyszlo. Teraz zajecia prowadzi
>> moj kolega z roku. Zostal na doktorat bo sie do niczego nie
>> nadawal. A ja sie na interview dziwie, ze z roku na roku coraz mniej
>> kumaci ludzie przychodza.
>
> O jakości kształcenia możemy ewentualnie porozmawiać
> na pl.soc.edukacja.

ten temat mnie zupelnie nie interesuje, ale jak masz jakies ciekawe 
spostrzezenia to podziel sie. I tak jestesmy juz gleboko off-topic.

> Tutaj chciałbym jedynie przypomnieć,
> że studiowanie nie polega jedynie na wkuwaniu tego, co wykładowca
> powie podczas zajęć, ale zwykle wymaga również własnej inicjatywy
> w zdobywaniu wiedzy i umiejętności.

Zycie i praca pokazalo mi, ze na studiach mnie oklamywali.

>> O mentalnosci Polakow i podejsciu do pracy nie bede sie wypowiadal
>> bo sie nie chce zagotowac zanim pojde spac. Natomiast wiem jedno -
>> kolejne poziomy do 5 wlacznie i dalej jako CMMI mozna spokonie, bez
>> obaw zdobywac. Potrzeba tylko odpowiednich ludzi do realizacji tych
>> celow. Banalne, ale jak prawdziwe...
>
> Sam potwierdziłeś to, co napisałem: brak odpowiednich ludzi, czyli
> po mojemu kłopoty z mentalnością przeciętnego pracownika.

Znow masz problem ze zrozumieniem. Nie brak ludzi, tylko problem z ich 
znalezieniem bo oni sa. Dowody sa w Krakowie.

> Od siebie
> tylko dodam, że wolałbym, aby każda polska firma softłerowa była
> certyfikowana na poziomie powtarzalnym, zamiast żeby było jedynie
> kilkanaście na poziomie piątym, a reszta na wstępnym.
Amen!

pzdr
Muchomor 
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13987
Author: Sektor van Skijlen
Date: Thu, 09 Mar 2006 21:44
30 lines
2490 bytes
Dnia Tue, 07 Mar 2006 15:54:20 -0600, AL. skrobie:
> On Tue, 7 Mar 2006 21:17:29 +0000 (UTC), "Miros/law L. Baran"
> <baran@hell.pl> wrote:

> >PT Aleksander Galicki pisze:
> >
> >> Zeby korzystac z tak sofisticated tool, to trzeba miec jeszcze odpowiednio 
> >> sofisticated language. Np C++. No bo nie kazdy jezyk daje tak wypasione 
> >> enterprise-ready mozliwosci jak "out-of-bounds array access" albo "buffer 
> >> overflows".
> >
> >Mo?e Ci? to zaskoczy, ale w pewnych produktach na pewnym poziomie
> >trudno jest zast?pi? C/C++ haskellem.
> >

> Mnie zas zaskakuje ze ktos jeszcze do czegos uzywa C++.

A mnie zaskakuje, że ktoś do czegokolwiek używa Javy. I co pan na to?

Znając pana poglądy, domniemam, że pewnie plotę niestworzone dyrdymały.

(nb. jak mi ktoś spróbuje wmówić, że w Javie nie istnieją przekroczenia granic
tablicy, to go strzelę w łeb)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13950
Author: Piotr Dembiński
Date: Thu, 09 Mar 2006 22:32
20 lines
2130 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

[...]

>>> Pozwol, ze zapytam - kto Cie uczyl?
>>
>> Prof. Nawrocki.  I wiem, że jeśli chodzi o poglądy, to ma 
>> on w tzw. środowisku przeciwników.
>
> nie mialem przyjemnosci. BTW poza pracami K. Czarneckiego 
> nie spotkalem niczego co by bylo dzielem naszego rodaka 
> i bylo interesujace w SE.

Bo i.o. nie jest taką aż znowu interesującą dziedziną, żeby dokonywać
w niej przełomowych odkryć, szczególnie na uczelni nie znajdującej się
w mieście stołecznym, na obrzeżach współczesnej cywilizacji.  
Ale badania naukowe są na PP prowadzone.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13951
Author: Piotr Dembiński
Date: Sat, 11 Mar 2006 18:02
23 lines
2326 bytes
pdemb@gazeta.pl (Piotr Dembiński) writes:

> "Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:
>
> [...]
>
>>>> Pozwol, ze zapytam - kto Cie uczyl?
>>>
>>> Prof. Nawrocki.  I wiem, że jeśli chodzi o poglądy, to ma 
>>> on w tzw. środowisku przeciwników.
>>
>> nie mialem przyjemnosci. BTW poza pracami K. Czarneckiego 
>> nie spotkalem niczego co by bylo dzielem naszego rodaka 
>> i bylo interesujace w SE.
>
> Bo i.o. nie jest taką aż znowu interesującą dziedziną, żeby
> dokonywać w niej przełomowych odkryć, szczególnie na uczelni 
> nie znajdującej się w mieście stołecznym, na obrzeżach 
> współczesnej cywilizacji.  Ale badania naukowe są na PP 
> prowadzone.

I jeszcze jedno: na pewno nie słyszał Pan o Software Development
Studio?  Profesor napisał o tym chyba kilka artykułów.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13952
Author: Muchomor
Date: Sat, 11 Mar 2006 19:55
11 lines
2139 bytes
""Piotr Dembiński""  wrote
> I jeszcze jedno: na pewno nie słyszał Pan o Software Development
> Studio?  Profesor napisał o tym chyba kilka artykułów.

Chyba nie wyjde na ignoranta jesli sie przyznam, ze nie ? Szczerze mowiac to 
nazwa jest taka hmmm niezachecajaca....
Nie zycze sobie by zwracac sie do mnie per Pan :)

pzdr
Muchomor 
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13955
Author: Piotr Dembiński
Date: Sat, 11 Mar 2006 20:47
13 lines
1988 bytes
"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

> ""Piotr Dembiński""  wrote
>> I jeszcze jedno: na pewno nie słyszał Pan o Software Development
>> Studio?  Profesor napisał o tym chyba kilka artykułów.
>
> Chyba nie wyjde na ignoranta jesli sie przyznam, ze nie ? 

Tam się testuje na studentach wszystkie nowinki w i.o.

> Szczerze mowiac to nazwa jest taka hmmm niezachecajaca....  

Po polsku SRO.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13959
Author: Sektor van Skijlen
Date: Fri, 17 Mar 2006 17:41
89 lines
5725 bytes
Dnia Thu, 09 Mar 2006 18:29:02 +0100, mgl skrobie:
> Sektor van Skijlen wrote:
> > Pracownik nie ma "wierzyć w skuteczność"; pracownik ma się dostosować do
> > zaleceń, albo poszukać sobie innego zajęcia. Jeśli jakiś mądrala twierdzi
> > inaczej, to znaczy, że też powinien sobie poszukać innego zajęcia, najlepiej
> > rencista.

> Hehe, zdolności kierowniczych to nie masz... ;)

Wymaganie dyscypliny to twoim zdaniem brak zdolności kierowniczych? Ciekawa
teoria. Tym bardziej, że moje doświadczenia temu przeczą.

> > CMM level 2 to jest to, co powinna posiadać KAŻDA BEZ WYJĄTKU firma, jeśli w
> > ogóle ma zamiar utrzymać się na rynku bez dotacji i nie zostać po pół roku
> > zrównana z ziemią i posypana solą. CMM 2 to jest to, od czego firmy powinny
> > STARTOWAĆ. CMM 1 to jest poziom typu "ja ze szwagrem". Jeśli ktoś tego nie
> > rozumie i tłumaczy studentom takie bzdury, powinien wylecieć jak najszybciej
> > na zbity pysk.

> Zapomniałeś tylko zwrócić uwagę na tę, że czysty RUP plasuje się w 
> okolicach CMM 2-, a w wielu firmach, nie tylko polskich, dyscyplina 
> przyjętego procesu jest od RUPowskiej, delikatnie mówiąc, odległa.

Cóż, przez grzeczność, nie zaprzeczę. Sam pracowałem w takowej, niestety. I
tak dobrze, że ktoś w ogóle zaczął myśleć o wprowadzeniu jakiegoś
uporządkowania w tym tworzeniu oprogramowania, tylko że zaraz, jak pomysł padł
i miał być wdrożony, to jego "sygnatariusze" zwolnili się z pracy.

> "Wskakiwanie" w takich firmach na CMM 5 niechybnie skończyłoby się 
> wrzodami u większości załogi.

Toż nikt nie wyskakuje z CMM 5 w firmie, któa nie osiągnęła CMM 4.

> > CMM 5 w stosunku do 4 wprowadza tzw. proces ulepszania procesu. Posiadanie
> > takiego procesu jest dla firmy czymś idealnym, bo pozwala dostosować proces do
> > specyfiki prowadzonych projektów, a tym samym dostosować go tak, aby lepiej
> > spełniał postawione przed nim wymagania (minimum defektów przy minimalnych
> > kosztach).

> "Czymś idealnym" to wiesz... jest okrag, matematyczny :).

Chyba nie zrozumiałeś.

> Czy faktycznie pomiar procesu, mówiąc brzydko, przyczynia się do jego 
> poprawy - to zależy przede wszystkim od ludzi za to odpowiedzialnych. 

Od kiedy to pomiar procesu ma się przyczynić do jego poprawy? Pomiar procesu
ma stanowić podstawę do badań nt. jego ulepszania.

> Teoria jest wprawdzie szczytna i miejscami jestem jej fanem, ale wiele 
> firm nie potrzebuje po prostu choćby niezwykle szczegółowej dokumentacji 
> procesu

Ależ ulepszanie procesu nie polega bynajmniej na szczegółowym jego
dokumentowaniu.

> - projekty trwają zbyt krótko albo są zbyt różne, żeby na 
> podstawie zgromadzonych danych można było wyciągać jakieś daleko idące, 
> a przede wszystkim biznesowo opłacalne wnioski.

Czy stwierdzenie, że np. poprzez używanie Worda do dokumentowania testkejsów
mieliśmy znaczne opóźnienia w procesie testowania jednostkowego, jest twoim
zdaniem daną nie wystarczającą do wyciągania biznesowo opłacalnych wniosków?
Czy stwierdzenie, że znacznie bardziej gładko idzie pisanie kodu równolegle z
dokumentacją, w większości zautomatyzowaną, niż poprzez tworzenie
dokumentacji, zamykanie jej i kodowanie podług tej dokumentacji, jest mało
miarodajne?

> A jak już jesteśmy przy biznesie - zachowanie dyscypliny CMM od poziomu 
> 4 robi się dosyć drogą zachcianką.

To nie ma znaczenia, czy ona jest droga. Istotne jest, czy jest opłacalna.

> > Jeśli takie coś ma się nie sprawdzać w naszych realiach, to mogę jedynie
> > powiedzieć, że owszem, jeśli takich idiotów wpuszczają na katedrę, to
> > zatrudniająca ich instytucja na pewno nie będzie mogła wprowadzić żadnych
> > kontroli jakości.

> Ostre słowa, chyba nieuzasadnione.

Wybacz, ale odnosiły się do co najmniej nieuzasadnionej krytyki wprowadzania
kontroli jakości.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13969
Author: Sektor van Skijlen
Date: Fri, 17 Mar 2006 18:04
41 lines
3471 bytes
Dnia Thu, 09 Mar 2006 18:43:04 +0100, mgl skrobie:
> > Zresztą, nie sądzę, żeby się to różniło od wielu innych firm. Nie słyszałem
> > jeszcze, żeby ktokolwiek powiedział, że mu proces "nie przeszkadza", albo że
> > "skutecznie minimalizuje defekty przy minimalnym narzucie formalnym".

> Chyba masz mało świadomych współpracowników. W wielu firmach, które mają 
> problem z niedbałością wynikającą z procesu, propozycje zmian i ulepszeń 
> wychodzą właśnie od szeregowych pracowników, bo to oni w tym bagnie 
> pracują. No ale Ty byś ich, jak zrozumiałem z innego postu, z miejsca z 
> pracy zwolnił. Dlaczego?? :)

Nic takiego nie napisałem. Wręcz przeciwnie.

Podpowiem ci, czego nie zrozumiałeś: najwyraźniej merda ci się inwencja z
brakiem dyscypliny.

> > Zazwyczaj narzutu formalnego jest w xuj, z tym tylko, że daje się odpowiednio
> > sprytnie to zminimalizować, jeśli ma się odrobinę "inwencji" (po prostu nie
> > używając niektórych ficzerów procesu; bynajmniej nie przez obchodzenie
> > procesu).

> Przyznaję się, że nie zrozumiałem. Niepełna realizacja procesu równa się 
> realizacji jakiegoś innego procesu. To się nazywa kombinatorstwo, a nie 
> "inwencja", nie? ;)

Są po prostu sprawy, których proces nie opisuje, a wszyscy przyjmują
domyślnie, że tak ma być.

Przykładowo, zmiany w źródłach mają być rejestrowane w odpowiednich rekordach.
Ale to wcale nie znaczy, że czas aktywności rekordu musi się ściśle pokrywać z
czasem poświęconym na te zmiany.

To nie jest żadna "niepełna" realizacja procesu. Proces określa dość ścisłe
ramy, w jakich mają się zawrzeć reguły pracy, ale daje też odpowiednio dużo
luzu. Bez takiego luzu każda firma poszłaby z torbami.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakości
#13976
Author: Sektor van Skijlen
Date: Fri, 17 Mar 2006 18:17
88 lines
5035 bytes
Dnia Thu, 09 Mar 2006 18:09:16 +0100, mgl skrobie:
> Sektor van Skijlen wrote:
> >>Korzystacie z tego z poziomu IDE?
> >>Czy podłączyliście może do automatycznego buildowania?
> > 
> > Jejku, co to za różnica.

> Tak, jak ślepemu bez różnicy, czy słońce za oknem.
> Ale wypada podziękować: "jejku, dziękuję za niezwykle wartościowy 
> komentarz" (nie, nie mam na imię Lucjan)

Jasne, też bardzo istotna sprawa, jakich metod się używa w jednej ściśle
określonej czynności.

Wymieńmy może jeszcze takie szczegóły, jak to, czy testy na danym poziomie
robione są ręcznie, czy automatycznie, a najlepiej jeszcze jakiego koloru są
kosze na śmieci.

> A ja mam psa i dwa koty.

Pozwól, że nie uwierzę. Jeśli rzeczywiście masz jakieś doświadczenie, to nie
mógłbyś mieć jednocześnie psa i dwóch kotów.

> Jeśli rzeczywiście masz jakieś doświadczenie w 
> temacie i spojrzenie szersze niż developer to powinienneś wiedzieć, że 
> CMM(I) nie określa metod przeglądu kodu, ale przede wszystkim cechy i 
> cele, jakie powinien realizować przyjęty proces.

Amerykę odkryłeś, ubierając to jednocześnie w menedżerski bełkot.

To oczywiste, ale najwyraźniej nie zauważyłeś, w swej mądrości, że nie o tym
była mowa.

> Te kilka lat to raczej 
> chyba przy klawiaturze i kodowaniu kolejnych CR, a nie w QA, co?

Oczywiście. Do QA to się idzie na wypoczynek.

> > A już twierdzenie, że kod jest zamrożony to jest dosłownie szurnięte. Kod
> > zamrożony? Jeżeli kod jest zamrożony, to znaczy, że nadaje się wyłacznie do
> > kosza. Niby jak do kodu potem mają być dodawane nowe ficzery? Zresztą, co tam
> > ficzery; w jaki sposób poprawia się błędy znalezione przez SST?

> Chyba ktoś nie zakumał treści... :) No ale taka karma widać.

Taaa... nie będę pokazywał palcem, kto.

> Obrazowo: jak wkładasz do zamrażarki mięso, to już nigdy z niego pożytku 
> nie masz?

To przedstaw mi jeszcze obrazowo, jak sprawdzić, co jest namalowane na środku
talerza, który jest trzeci od dna stosu, a na stosie jest 20 talerzy. Nie
naruszając bieżącej struktury stosu.

> Powiedz mi jeszcze, w czym Ty piszesz, że nie możesz łatwo ficzerów 
> dodawać do, mówiąc piłkarsko, "stałych fragmentów kodu"?

W tym, co wszyscy :)

> > Inspekcja służy do zatwierdzenia zmian, ale wykrywanie błędów na inspekcji to
> > fikcja. Statystyki wykryć błędów przez inspekcje są mizerniutkie. I słusznie,
> > bo inspekcja ma się skupić na kwestii CZYTELNOŚCI kodu i jasności jego
> > intencji. Właśnie po to, żeby było łatwo później go modyfikować i wprowadzać
> > poprawki, w tym również poprawki błędów. Ma zabezpieczać również przed
> > przedostawaniem się do kodu głupich pomysłów. Nic więcej. Gdybyśmy po takiej
> > inspekcji "zamrażali" kod, to taka inspekcja byłaby w ogóle pozbawiona
> > jakiegokolwiek sensu.

> Ale WY (to ten słynny Układ?)

Jak byś tam był.

> nie jesteście źródłem tej historyjki. Na, 
> jak rozumiem, Motorolce i TETRZE świat się nie kończy :).

Owszem, nie kończy się, to raz. Dwa, musiałeś mnie chyba z kimś pomylić (albo
twój wywiad gospodarczy ma mało aktualne informacje).

> ogólnie: lol, komuś się tu wylewa ego... :)

Jak byś tam był :). W dokładniej, to nawet jesteś :)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13960
Author: Piotr Dembiński
Date: Sat, 18 Mar 2006 13:36
8 lines
1581 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> Od kiedy to pomiar procesu ma się przyczynić do jego poprawy? Pomiar
> procesu ma stanowić podstawę do badań nt. jego ulepszania.

Sam sobie zaprzeczasz.
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13970
Author: Piotr Dembiński
Date: Sat, 18 Mar 2006 13:38
10 lines
1664 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> Są po prostu sprawy, których proces nie opisuje, a wszyscy przyjmują
> domyślnie, że tak ma być.

Istnieją organizacje, w których żadna ze 'spraw' nie jest
skodyfikowana, ale to są najczęściej komórki różnych agencji
wywiadowczych albo gangi :>
Re: Pomiar metryk kodu w procesie kontroli jakości
#13977
Author: Piotr Dembiński
Date: Sat, 18 Mar 2006 13:41
12 lines
1701 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

> Jasne, też bardzo istotna sprawa, jakich metod się używa w jednej
> ściśle określonej czynności.
>
> Wymieńmy może jeszcze takie szczegóły, jak to, czy testy na danym
> poziomie robione są ręcznie, czy automatycznie, a najlepiej jeszcze
> jakiego koloru są kosze na śmieci.

Normy budowlane często określają jeszcze drobniejsze szczegóły.
Re: Pomiar metryk kodu w procesie kontroli jakości
#13979
Author: Piotr Dembiński
Date: Sat, 18 Mar 2006 13:44
10 lines
1642 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

[...]

> Oczywiście. Do QA to się idzie na wypoczynek.

Acha, czyli -- przez analogię -- prezydent demokratycznego kraju,
który zatwierdza uchwalone przez parlament ustawy jest w porównaniu 
z urzędnikami oraz parlamentarzystami takim letnikiem?
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13961
Author: Muchomor
Date: Sat, 18 Mar 2006 21:07
19 lines
2183 bytes
""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message 
news:87k6arg9ia.fsf@hector.domek...
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> 
> writes:
>
> [...]
>
>> Od kiedy to pomiar procesu ma się przyczynić do jego poprawy? Pomiar
>> procesu ma stanowić podstawę do badań nt. jego ulepszania.
>
> Sam sobie zaprzeczasz.

Niekoniecznie. Poprawia sie cos o jest niepoprawne (bledne w sposob 
niekoniecznie oczywisty). Ulepsza sie cos co jest dobre, ale nie optymalne. 
Aczkolwiek nie jestem pewien czy o to Sektorowi chodzilo :)

pzdr
Muchomor
Re: Pomiar metryk kodu w procesie kontroli jakosci
#13962
Author: Sektor van Skijlen
Date: Sat, 18 Mar 2006 21:14
19 lines
2260 bytes
Dnia Sat, 18 Mar 2006 14:36:29 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> [...]

> > Od kiedy to pomiar procesu ma się przyczynić do jego poprawy? Pomiar
> > procesu ma stanowić podstawę do badań nt. jego ulepszania.

> Sam sobie zaprzeczasz.

Nieprawda. Sam bywałem świadkiem, jak nt. określonego procesu zbiera się całą
kupę danych, w tym takie, które naprawdę mogłoby służyć do ulepszania procesu,
niestety dane są ładne, pięknie, po czym karawan jedzie dalej.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakości
#13978
Author: Sektor van Skijlen
Date: Sat, 18 Mar 2006 21:16
20 lines
2154 bytes
Dnia Sat, 18 Mar 2006 14:44:06 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> [...]

> > Oczywiście. Do QA to się idzie na wypoczynek.

> Acha, czyli -- przez analogię -- prezydent demokratycznego kraju,
> który zatwierdza uchwalone przez parlament ustawy jest w porównaniu 
> z urzędnikami oraz parlamentarzystami takim letnikiem?

Analogia zaiste godna mistrza ciętej riposty.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakości
#13980
Author: Piotr Dembiński
Date: Sat, 18 Mar 2006 22:02
18 lines
1901 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

> Dnia Sat, 18 Mar 2006 14:44:06 +0100, Piotr Dembiński skrobie:
>> Sektor van Skijlen
>> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
>
>> [...]
>
>> > Oczywiście. Do QA to się idzie na wypoczynek.
>
>> Acha, czyli -- przez analogię -- prezydent demokratycznego kraju,
>> który zatwierdza uchwalone przez parlament ustawy jest w porównaniu
>> z urzędnikami oraz parlamentarzystami takim letnikiem?
>
> Analogia zaiste godna mistrza ciętej riposty.

QA to też ciężka praca.
Re: Pomiar metryk kodu w procesie kontroli jakości
#13981
Author: Sektor van Skijlen
Date: Sat, 18 Mar 2006 23:20
38 lines
3052 bytes
Dnia Sat, 18 Mar 2006 23:02:08 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> > Dnia Sat, 18 Mar 2006 14:44:06 +0100, Piotr Dembiński skrobie:
> >> Sektor van Skijlen
> >> <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:
> >
> >> [...]
> >
> >> > Oczywiście. Do QA to się idzie na wypoczynek.
> >
> >> Acha, czyli -- przez analogię -- prezydent demokratycznego kraju,
> >> który zatwierdza uchwalone przez parlament ustawy jest w porównaniu
> >> z urzędnikami oraz parlamentarzystami takim letnikiem?
> >
> > Analogia zaiste godna mistrza ciętej riposty.

> QA to też ciężka praca.

Wiesz, kopanie łopatą dołu przez 3/4 dnia i zasypywanie go przez resztę dnia
to też ciężka praca.

Tu nie chodzi o to, jak ciężka jest to praca, tylko jaki firma z tej pracy ma
zysk. A to zależy od tego, czy QA zajmuje się interpretacją właściwych danych
we właściwy sposób i czy rzeczywiście skutecznie reaguje na sprawy, które
próbują wymykać się spod kontroli.

Oczywiście, że to jest powszechnie krążący u nas żart, że do QA się idzie na
wypoczynek i oczywiście, że nie ma to nic wspólnego z prawdą. Z tym tylko że
te żarty są najżywsze w zespole testów regresyjnych. A temu to już trudno się
dziwić.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jakości
#13982
Author: Piotr Dembiński
Date: Sun, 19 Mar 2006 17:28
29 lines
2561 bytes
Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

>> QA to też ciężka praca.
>
> Wiesz, kopanie łopatą dołu przez 3/4 dnia i zasypywanie go przez
> resztę dnia to też ciężka praca.
>
> Tu nie chodzi o to, jak ciężka jest to praca, tylko jaki firma z tej
> pracy ma zysk. A to zależy od tego, czy QA zajmuje się interpretacją
> właściwych danych we właściwy sposób i czy rzeczywiście skutecznie
> reaguje na sprawy, które próbują wymykać się spod kontroli.

No właśnie to chyba jest ta praca: dobrać właściwe metody, miary i tym
podobne.  Potrzeba wiedzy, podejścia analitycznego, syntetycznego oraz
-- nie bójmy się tego słowa -- kreatywności.

> Oczywiście, że to jest powszechnie krążący u nas żart, że do QA się
> idzie na wypoczynek i oczywiście, że nie ma to nic wspólnego 
> z prawdą. Z tym tylko że te żarty są najżywsze w zespole testów
> regresyjnych. A temu to już trudno się dziwić.

Nie wiem, nie znam się, nie pracowałem nigdy w dziale QA żadnej 
firmy informatycznej.  Piszę tylko to, co wywnioskowałem ze studiów 
i z tego, co przeczytałem.

-- 
http://www.piotr.dembiński.prv.pl
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13988
Author: Piotr Kobzda
Date: Fri, 07 Apr 2006 22:46
18 lines
1882 bytes
Sektor van Skijlen wrote:

> (nb. jak mi ktoś spróbuje wmówić, że w Javie nie istnieją przekroczenia granic
> tablicy, to go strzelę w łeb)

Oczywiście, że istnieją. Piszącym w Javie zdarza się także błędy 
popełniać. Dlatego też właśnie w Javie jest tak:

All array accesses are checked at run time; an attempt to use an index 
that is less than zero or greater than or equal to the length of the 
array causes an ArrayIndexOutOfBoundsException to be thrown.

[JLS 10.4]

Czyżby groźby Twe oznaczać miały, że jest inaczej?


piotr
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13989
Author: Sektor van Skijlen
Date: Sat, 08 Apr 2006 00:31
24 lines
2332 bytes
Dnia Sat, 08 Apr 2006 00:46:56 +0200, Piotr Kobzda skrobie:
> Sektor van Skijlen wrote:

> > (nb. jak mi ktoś spróbuje wmówić, że w Javie nie istnieją przekroczenia granic
> > tablicy, to go strzelę w łeb)

> Oczywiście, że istnieją. Piszącym w Javie zdarza się także błędy 
> popełniać. Dlatego też właśnie w Javie jest tak:

> All array accesses are checked at run time; an attempt to use an index 
> that is less than zero or greater than or equal to the length of the 
> array causes an ArrayIndexOutOfBoundsException to be thrown.

> [JLS 10.4]

> Czyżby groźby Twe oznaczać miały, że jest inaczej?

Nie, że jest właśnie tak ;)

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13990
Author: Piotr Kobzda
Date: Sat, 08 Apr 2006 01:24
14 lines
1760 bytes
Sektor van Skijlen wrote:

>>>(nb. jak mi ktoś spróbuje wmówić, że w Javie nie istnieją przekroczenia granic
>>>tablicy, to go strzelę w łeb)
[...]
>>Czyżby groźby Twe oznaczać miały, że jest inaczej?
> 
> Nie, że jest właśnie tak ;)

Czyli, że co, zbędny to ficzer Twoim zdaniem, czy też tak nieistotny, że 
argumentem za używaniem Javy po prostu być nie może?


piotr
Re: Pomiar metryk kodu w procesie kontroli jako?ci
#13991
Author: Sektor van Skijlen
Date: Sat, 08 Apr 2006 13:18
33 lines
2921 bytes
Dnia Sat, 08 Apr 2006 03:24:37 +0200, Piotr Kobzda skrobie:
> Sektor van Skijlen wrote:

> >>>(nb. jak mi ktoś spróbuje wmówić, że w Javie nie istnieją przekroczenia granic
> >>>tablicy, to go strzelę w łeb)
> [...]
> >>Czyżby groźby Twe oznaczać miały, że jest inaczej?
> > 
> > Nie, że jest właśnie tak ;)

> Czyli, że co, zbędny to ficzer Twoim zdaniem, czy też tak nieistotny, że 
> argumentem za używaniem Javy po prostu być nie może?

Ludzie, coście się czepili!?

W stosunku do niesprawdzanego odwołania, ma swoje zady i walety. Ten list,
którego się czepiliście, stanowił jedynie małą prowokację.

Stosowanie sprawdzenia przed każdym odwołaniem ma swoje zalety, polegające na
tym, że zyskujemy tzw. bezpieczeństwo, czyli gwarancję, że aplikacja nie
namiesza w danych użytkownika, tylko się wykrzaczy. Nie zyskujemy jednak, o
czym wszyscy nagminnie zapominają, niezawodności oprogramowania.

Z tą tylko różnicą, że ja raczej jestem zwolennikiem stosowania tak dokładnej
diagnostyki tylko w tzw. "wersji debug". Do zapewnienia, że w kodzie nie
wystąpi wyjechanie poza tablicę, powinny służyć testy jednostkowe i
komponentowe.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Page 1 of 2 • 86 total messages
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads