-
41. Data: 2012-03-17 20:46:29
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Przemek O <p...@o...eu>
W dniu 2012-03-17 19:22, t.o. pisze:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
> wiadomości
> news:f2db5697-6646-4eff-a45c-ac6004221d77@hv2g2000vb
b.googlegroups.com...
> On Mar 16, 4:20 pm, zażółcony <r...@c...pl> wrote:
>> W dniu 2012-03-15 16:09, Wojciech Jaczewski pisze:
>>
>> > > Andrzej Jarzabek wrote:
>> >
>> > [...]
>>
>> > Jeśli dopuścimy, że główny ciężar odpowiedzialności
>> > ponoszą specjaliści niskiego szczebla, to będziemy mieć
>> > wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
>> > na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
>> > z innych rejonów świata.
>>
>> Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
>> zawodowa, to buć może nie będziemy.
>
> Certyfikacja zawodowa?
Heh, nowy? AJ ma hopla na punkcie certyfikacji zawodowej :)
pozdrawiam,
Przemek O.
-
42. Data: 2012-03-18 14:10:25
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Andrzej Jarzabek <a...@g...com>
On 17/03/2012 20:46, Przemek O wrote:
> W dniu 2012-03-17 19:22, t.o. pisze:
>> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
>> wiadomości
>>>
>>> > Jeśli dopuścimy, że główny ciężar odpowiedzialności
>>> > ponoszą specjaliści niskiego szczebla, to będziemy mieć
>>> > wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
>>> > na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
>>> > z innych rejonów świata.
>>>
>>> Gdyby jednocześnie z tym dopuszczeniem weszła w życie certyfiacja
>>> zawodowa, to buć może nie będziemy.
>>
>> Certyfikacja zawodowa?
>
> Heh, nowy? AJ ma hopla na punkcie certyfikacji zawodowej :)
Wypraszam sobie, cała ta odnoga jest przecież w kontekście certyfikacji
zawodowej, zresztą nie poruszonej wcale przeze mnie, tylko przez MM,
msg-id: <jj23m2$c16$1@inews.gazeta.pl>:
"Dlatego proby wprowadzania certyfikatow dla programistow, albo jakis
standardow uwazam za smieszne. Co z tego ze mozna bylo zrobic lepsze
jesli menagment nie pozwolil?"
Z tego wzięła się przecież cała rozmowa o tym, czy i na ile
odpowiedzialny jest programista, a na ile kierownictwo.
Ostatecznie, nie wchodząc w to, czy ja akurat uważam certyfikację
sensowną, czy nie, to jeśli założymy, że (bez certyfikacji) "będziemy
mieć tyle wybuchów ile fal wchodzenia na rynek niedoświadczonych ludzi
lub fal imigrantów", to byłby to kontrargument na "certyfikacja
programistów jest śmieszna" - nie jest śmieszna, bo ogranicza ilość
wybuchów (wypadków samochodowych itd.) W przypadku certyfikacji jeśli
menedżmen nie pozwoli zrobić zgodnie z zasadami sztuki, to nie znajdzie
certyfikowanych programistów, którzy zrobią tak, jak pozwoli.
Osobna sprawa czy np. w przypadku powiedzmy Toyoty błąd się wziął stąd,
że menedżment nie pozwolił - biorąc pod uwagę jakie pieniądze są w grze
w tym biznesie i jak bolesne dla "bottom line" firmy są takie newsy jak
ten, to raczej wątpliwe.
-
43. Data: 2012-03-18 17:58:15
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Wojciech Jaczewski <w...@o...pl>
zażółcony wrote:
> Scenariusze testowe, ryzyka - powinni wymyślać ludzie
> bliżsi biznesu i rzeczywistości :) niż programiści,
> którzy np. jadą procedury wg. specyfikacji i tyle.
> Jeśli dopuścimy, że główny ciężar odpowiedzialności
> ponoszą specjaliści niskiego szczebla, to będziemy mieć
> wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
> na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
> z innych rejonów świata.
Odpowiedzialność prawna powinna być po prostu w danej firmie jednoznacznie
określona - powinien być człowiek odpowiedzialny za produkt jako całość i w
szczególnych przypadkach sąd mógłby uznać, że tym razem winy nie ponosi
główny inżynier (albo i dyrektor - jeśli chce się podpisywać jako prawnie
odpowiedzialny za produkt), lecz inny pracownik.
Inną sprawą jest odpowiedzialność - można by ją określić "moralna" - i tu
odpowiedzialny jest każdy, kto ma świadomość co robi. I - niestety - jest
społeczna akceptacja dla udziału w tworzeniu wadliwych, czy nawet
niebezpiecznych produktów - przez usprawiedliwianie "bo taką ma pracę"...
-
44. Data: 2012-03-18 18:07:59
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Edek Pienkowski <e...@g...com>
Dnia Sat, 17 Mar 2012 16:12:00 +0100, Wojciech Jaczewski napisal:
> Edek Pienkowski wrote:
>
>> jak większość programistów stosuje KISS,
>> gubiąc połowę szczegółów najczęściej i potem nie chce działać. No, ale
>> jest proste.
>
> Wg mnie, szczegóły to gubią właśnie ci, którzy stosują rozwiązania
> skomplikowane. Nawymyślają sobie jakiś przerost formy nad treścią (czy
> to przez nadużywanie technik obiektowych, czy przez nadużywanie
> szablonów),
> przez co na szczegóły zabraknie już czasu.
Udziwnianie bez sensu jest bez sensu. Ale code style to kwestia nie
pojedynczego programisty, a projektu; a każdy projekt ma swoje
preferencje. Znam takie, gdzie są prawie same template'y (fakt,
kompiluje się ze 2 godziny) tak jak w bibliotece standardowej, tylko
że gorsze od większości boosta.
>
>> KISS to bełkot. Niestety masa programistów postępuje mniej więcej tak,
>> że wątki są skomplikowane, boost jest skomplikowany, w ogóle po co
>> skomplikowane rozwiązania, nie musżę się uczyć i powiem,
>> że KISS! Alleluja i do przodu.
>
> Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych -
> wyłącznie tam, gdzie nie ma prostych.
Ok, skreślmy C++, w C wszystko da się napisać. Dla osoby, która
nie używa template'ów, bo nie lubi, kod może wyglądać na skomplikowany
podczas gdy tak naprawdę jest dużo prostszy, bo programowanie generyczne
po to właśnie powstało, żeby ułatwiać niektóre rzeczy, to jeden tylko
przykład. Kwestia skomplikowania czy też nie zależy mocno od dostępnych
- tak to się chyba nazywa - struktur poznawczych. Dla mnie Perl
na przykład wygląda na mega skomplikowany, a podejrzewam, że wcale nie
jest, tylko ja go akurat słabiutko znam.
> Wymienione wyżej wątki: jeśli ktoś ich używa tam, gdzie spokojnie
> poradziłby sobie program jednowątkowy, to szuka sobie (a często i nie
> sobie, tylko pozostałym współpracownikom) kłopotów. Nie chodzi o to,
> żeby tych rozwiązań się nie uczyć, tylko aby jedynym powodem ich
> używania nie było to, że akurat poświęciłem ileś czasu na ich naukę - i
> koniecznie tę wiedzę muszę natychmiast wykorzystać.
Jeżeli ktoś, kto się dopiero co nauczył wątków decyduje o tym,
jakich bibliotek użyć, to jest to problem organizacyjny, a nie ma
nic wspólnego z kiss czy yagni. W zorganizowanym środowisku
wpływ ma kilka osób, w tym bardziej doświadczone od takiego
studenta 3 roku.
Edek
-
45. Data: 2012-03-18 18:25:06
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Edek Pienkowski <e...@g...com>
Dnia Sun, 18 Mar 2012 18:58:15 +0100, Wojciech Jaczewski napisal:
> zażółcony wrote:
>
>> Scenariusze testowe, ryzyka - powinni wymyślać ludzie
>> bliżsi biznesu i rzeczywistości :) niż programiści,
>> którzy np. jadą procedury wg. specyfikacji i tyle.
>> Jeśli dopuścimy, że główny ciężar odpowiedzialności
>> ponoszą specjaliści niskiego szczebla, to będziemy mieć
>> wybuch za wybuchem, tyle wybuchów, ile fal wchodzenia
>> na rynek młodych, niedoświadczonych ludzi lub fal imigrantów
>> z innych rejonów świata.
>
> Odpowiedzialność prawna powinna być po prostu w danej firmie jednoznacznie
> określona - powinien być człowiek odpowiedzialny za produkt jako całość i w
> szczególnych przypadkach sąd mógłby uznać, że tym razem winy nie ponosi
> główny inżynier (albo i dyrektor - jeśli chce się podpisywać jako prawnie
> odpowiedzialny za produkt), lecz inny pracownik.
Jak widać jeszcze u nas nie ma prawników specjalizujących się w
sprawach odpowiedzialności cywilnej. Uwierz mi, sktuki finansowe nałożone
na firmę, jeżeli są w odpowiedniej wysokości, mogą dać do myślenia
komuś, kto faktycznie na produkt ma wpływ. A wpływ ma jedynie ktoś,
kto decyduje. Jedną z podstawowych zasad odpowiedzialności za szkody
jest taka, że odpowiada nie osoba bezpośrednio wyrządzająca szkodę
(wypadło mu wiaderko z ręki na rusztowaniu i zabiło) tylko ktoś,
kto decydował o braku zabezpieczeń (siatka ochraniająca chodnik).
Być może na budowie jest jedna osoba odpowiedzialna, nie wiem, ale
nie słyszałem o czymś takim w informatyce i nie bardzo to widzę.
Edek
-
46. Data: 2012-03-18 18:46:15
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: A.L. <l...@a...com>
On Sun, 18 Mar 2012 18:07:59 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:
>Dnia Sat, 17 Mar 2012 16:12:00 +0100, Wojciech Jaczewski napisal:
>
>> Edek Pienkowski wrote:
>>
>>> jak większość programistów stosuje KISS,
>>> gubiąc połowę szczegółów najczęściej i potem nie chce działać. No, ale
>>> jest proste.
>>
>> Wg mnie, szczegóły to gubią właśnie ci, którzy stosują rozwiązania
>> skomplikowane. Nawymyślają sobie jakiś przerost formy nad treścią (czy
>> to przez nadużywanie technik obiektowych, czy przez nadużywanie
>> szablonów),
>> przez co na szczegóły zabraknie już czasu.
>
>Udziwnianie bez sensu jest bez sensu. Ale code style to kwestia nie
>pojedynczego programisty, a projektu; a każdy projekt ma swoje
>preferencje. Znam takie, gdzie są prawie same template'y (fakt,
>kompiluje się ze 2 godziny) tak jak w bibliotece standardowej, tylko
>że gorsze od większości boosta.
>
>>
>>> KISS to bełkot. Niestety masa programistów postępuje mniej więcej tak,
>>> że wątki są skomplikowane, boost jest skomplikowany, w ogóle po co
>>> skomplikowane rozwiązania, nie musżę się uczyć i powiem,
>>> że KISS! Alleluja i do przodu.
>>
>> Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych -
>> wyłącznie tam, gdzie nie ma prostych.
>
>Ok, skreślmy C++, w C wszystko da się napisać. Dla osoby, która
>nie używa template'ów, bo nie lubi, kod może wyglądać na skomplikowany
>podczas gdy tak naprawdę jest dużo prostszy, bo programowanie generyczne
>po to właśnie powstało, żeby ułatwiać niektóre rzeczy...
Zwlaszcza pisanie programow ktorych poprawnosc jest niemozliwa do
zwryfikowania. "Templates" to skomplikowana forma makrogeneratora
ktora przeksztalca program w 'cos" co dopiero jest kompilowane. W co -
pzreksztalca? Nie wiadomo, i trzeba meic 100 procentowe zaufanie do
calej maszynerii ze a) przeksztalca zgodnie z intencja programisty, b)
przksztalca bez bledow.
Dlatego tez wprowadze sie "safe subsets" dla jezykow programowania i
scisle reguly co mozna a czego nie mozna robic i jakich konstrukcji
nie mozna uzywac.
Dla C++ jest taki standard MISRA-C++,
http://www.misra-cpp.com/
http://www.moasoftware.co.kr/ldrapdf/LDRA_MISRA_C++_
2008_Standard_Compliance_v2.3.pdf
A.L.
-
47. Data: 2012-03-18 20:24:48
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Roman W <b...@g...pl>
On Sunday, March 18, 2012 6:46:15 PM UTC, A. L. wrote:
> Zwlaszcza pisanie programow ktorych poprawnosc jest niemozliwa do
> zwryfikowania. "Templates" to skomplikowana forma makrogeneratora
> ktora przeksztalca program w 'cos" co dopiero jest kompilowane. W co -
> pzreksztalca? Nie wiadomo, i trzeba meic 100 procentowe zaufanie do
> calej maszynerii ze a) przeksztalca zgodnie z intencja programisty, b)
> przksztalca bez bledow.
>
> Dlatego tez wprowadze sie "safe subsets" dla jezykow programowania i
> scisle reguly co mozna a czego nie mozna robic i jakich konstrukcji
> nie mozna uzywac.
>
> Dla C++ jest taki standard MISRA-C++,
>
> http://www.misra-cpp.com/
>
> http://www.moasoftware.co.kr/ldrapdf/LDRA_MISRA_C++_
2008_Standard_Compliance_v2.3.pdf
... ktory nie zabrania uzywania szablonow.
RW
-
48. Data: 2012-03-18 20:41:07
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Edek Pienkowski <e...@g...com>
Dnia Sat, 17 Mar 2012 09:17:22 -0700, Roman W napisal:
> On Saturday, March 17, 2012 3:12:00 PM UTC, Wojciech Jaczewski wrote:
>
>> Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych - wyłącznie
>> tam, gdzie nie ma prostych.
>> Wymienione wyżej wątki: jeśli ktoś ich używa tam, gdzie spokojnie poradziłby
>> sobie program jednowątkowy, to szuka sobie (a często i nie sobie, tylko
>> pozostałym współpracownikom) kłopotów. Nie chodzi o to, żeby tych rozwiązań
>> się nie uczyć, tylko aby jedynym powodem ich używania nie było to, że akurat
>> poświęciłem ileś czasu na ich naukę - i koniecznie tę wiedzę muszę
>> natychmiast wykorzystać.
>
> O to to. Pracuje nad biblioteka C++ ktorej oryginalni autorzy (ktorzy
> juz odeszli z firmy) nawsadzali szablony gdzie tylko sie dalo. Kod
> budowal sie niemilosiernie dlugo, debugowanie go trwalo wiecznosci bo
> debugger musial sie przebic przez stosy roznych wersji szablonow, a kod
> wcale nie byl znaczaco szybszy od wersji ktora go zastapilismy -
> uzywajacej zwyklego polimorfizmu na funkcjach wirtualnych.
Jeżeli źle zrozumiałem, to przepraszam, ale przyszły komfort życia wielu
kredytobiorców mógł zależeć od ewentualnych błędów, tak?
Edek
-
49. Data: 2012-03-19 07:38:39
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Paweł Kierski <n...@p...net>
W dniu 2012-03-17 12:16, Edek Pienkowski pisze:
[...]
> Ja jedynie argumentuję, że proste nie zawsze jest lepsze, odwrotny
> argument to już Ty stworzyłeś - nie chciałem nikogo urazić. Mnie
> po prostu wpienia to, jak większość programistów stosuje KISS,
> gubiąc połowę szczegółów najczęściej i potem nie chce działać.
> No, ale jest proste.
>
>> > Jak dla mnie to bełkot... Tak samo jak twierdzenie, iż "KISS jest
>> > właśnie dla ludzi głupich".
> KISS to bełkot. Niestety masa programistów postępuje mniej więcej tak,
> że wątki są skomplikowane, boost jest skomplikowany, w ogóle
> po co skomplikowane rozwiązania, nie musżę się uczyć i powiem,
> że KISS! Alleluja i do przodu.
To nie jest KISS. To jest nieuctwo i ewentualnie olewanie istotnych
wymagań, bo ich nie rozumiem. Naprawdę KISS oznacza mniej więcej to,
co w powiedzeniu przypisywanemu Einsteinowi: "Wszystko powinno być tak
proste, jak to tylko możliwe, ale nie prostsze.". To znaczy - piszę tak
prosto, jak się da, żeby spełnić wszystkie wymagania. Mogę ewentualnie
ponegcjować wymagania, żeby coś uprościć konstrukcyjnie, ale nie mogę
łamać wymagań, ani sadzić ewidentnych baboli "bo tak jest prościej".
Prostota pomaga utrzymać jakość, bo jest mniej miejsc, w których można
popełnić błąd. Ale prostota nie jest gwarancją bezbłędności i jest tylko
jednym ze środków, a nie celem. Gdy staje się celem, to efekty są takie,
jak napisałeś.
--
Paweł Kierski
n...@p...net
-
50. Data: 2012-03-19 08:55:32
Temat: Re: Blad w oprogramowaniu Toyoty przyczyna wypadkow
Od: Roman W <b...@g...pl>
On Sunday, March 18, 2012 8:41:07 PM UTC, Edek Pienkowski wrote:
> Dnia Sat, 17 Mar 2012 09:17:22 -0700, Roman W napisal:
>
> > On Saturday, March 17, 2012 3:12:00 PM UTC, Wojciech Jaczewski wrote:
> >
> >> Prostych rozwiązań należy używać tam, gdzie są. Skomplikowanych - wyłącznie
> >> tam, gdzie nie ma prostych.
> >> Wymienione wyżej wątki: jeśli ktoś ich używa tam, gdzie spokojnie poradziłby
> >> sobie program jednowątkowy, to szuka sobie (a często i nie sobie, tylko
> >> pozostałym współpracownikom) kłopotów. Nie chodzi o to, żeby tych rozwiązań
> >> się nie uczyć, tylko aby jedynym powodem ich używania nie było to, że akurat
> >> poświęciłem ileś czasu na ich naukę - i koniecznie tę wiedzę muszę
> >> natychmiast wykorzystać.
> >
> > O to to. Pracuje nad biblioteka C++ ktorej oryginalni autorzy (ktorzy
> > juz odeszli z firmy) nawsadzali szablony gdzie tylko sie dalo. Kod
> > budowal sie niemilosiernie dlugo, debugowanie go trwalo wiecznosci bo
> > debugger musial sie przebic przez stosy roznych wersji szablonow, a kod
> > wcale nie byl znaczaco szybszy od wersji ktora go zastapilismy -
> > uzywajacej zwyklego polimorfizmu na funkcjach wirtualnych.
>
> Jeżeli źle zrozumiałem, to przepraszam, ale przyszły komfort życia wielu
> kredytobiorców mógł zależeć od ewentualnych błędów, tak?
Raczej nie. Po drodze jest sporo testow i procedur weryfikacyjnych. Jesli pijesz do
CDO i innych, to nie bledy programistow byly przyczyna kryzysu.
RW