On Oct 10, 10:28 am, " " <f...@g...SKASUJ-TO.pl> wrote:
> Andrzej Jarzabek <a...@g...com> napisał(a):
>
> > Nie zrozumia=B3e=B6. Poprzedni programista to ty, a nadbudowywa=E6 mia=B3by
> > kto=B6 inny.
>
> robota tego programisty zalezy od tego programisty, co do

Czytasz to Wojtku Jaczewski? I rest my case.

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On Oct 10, 10:28=A0am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > Andrzej Jarzabek <a...@g...com> napisa=B3(a):
> >
> > > Nie zrozumia=3DB3e=3DB6. Poprzedni programista to ty, a nadbudowywa=3DE=
> 6 mia=3DB3by
> > > kto=3DB6 inny.
> >
> > robota tego programisty zalezy od tego programisty, co do
>
> Czytasz to Wojtku Jaczewski? I rest my case.

głupaczysz jak zwykle,





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Oct 10, 11:40 am, " " <f...@g...SKASUJ-TO.pl> wrote:
> Andrzej Jarzabek <a...@g...com> napisał(a):
>
> > On Oct 10, 10:28=A0am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > > Andrzej Jarzabek <a...@g...com> napisa=B3(a):
>
> > > > Nie zrozumia=3DB3e=3DB6. Poprzedni programista to ty, a nadbudowywa=3DE=
> > 6 mia=3DB3by
> > > > kto=3DB6 inny.
>
> > > robota tego programisty zalezy od tego programisty, co do
>
> > Czytasz to Wojtku Jaczewski? I rest my case.
>
> głupaczysz jak zwykle,

Tak w ogóle to uważam, że nie warto z tobą dyskutować, ale jako
ilustracja mojej tezy o kiepskich programistach nadajesz się świetnie.
Otóż prawdopodobieństwo wprowadzenia błędu przy modyfikacji
istniejącego kodu zależy nie tylko od umiejętności modyfikującego, ale
w dużej mierze od jakości tego istniejącego kodu. Im gorszy
programista, tym trudniej wprowadzić zmianę do jego kodu nie
wprowadzając błędu: nawet dla dobrego programisty będzie stanowić to
problem, bo chociaż potrafi on zmininalizować to prawdopodobieństwo,
operacja ta wymaga czasu i niekiedy współpracy dodatkowych ludzi,
nierzadko wcale powodując, że bardziej się opłaca napisać całą część
programu od nowa, niż poprawiać po partaczu. Dlatego też wszędzie,
gdzie błędy w programie mają poważniejsze konsekwencje niż parę jobów
na forach, raczej unika się zatrudniania kolesi, którzy uważają, że
nie ma problemu, jak napiszą kaszaniasty, trudny w utrzymaniu kod, o
ile tylko "działa".

do góry

Andrzej Jarzabek <a...@g...com> napisał(a):

> On Oct 10, 11:40=A0am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > Andrzej Jarzabek <a...@g...com> napisa=B3(a):
> >
> > > On Oct 10, 10:28=3DA0am, " " <f...@g...SKASUJ-TO.pl> wrote:
> > > > Andrzej Jarzabek <a...@g...com> napisa=3DB3(a):
> >
> > > > > Nie zrozumia=3D3DB3e=3D3DB6. Poprzedni programista to ty, a nadbudo=
> wywa=3D3DE=3D
> > > 6 mia=3D3DB3by
> > > > > kto=3D3DB6 inny.
> >
> > > > robota tego programisty zalezy od tego programisty, co do
> >
> > > Czytasz to Wojtku Jaczewski? I rest my case.
> >
> > g=B3upaczysz jak zwykle,
>
> Tak w og=F3le to uwa=BFam, =BFe nie warto z tob=B1 dyskutowa=E6, ale jako
> ilustracja mojej tezy o kiepskich programistach nadajesz si=EA =B6wietnie.
> Ot=F3=BF prawdopodobie=F1stwo wprowadzenia b=B3=EAdu przy modyfikacji
> istniej=B1cego kodu zale=BFy nie tylko od umiej=EAtno=B6ci modyfikuj=B1cego=
> , ale
> w du=BFej mierze od jako=B6ci tego istniej=B1cego kodu. Im gorszy
> programista, tym trudniej wprowadzi=E6 zmian=EA do jego kodu nie
> wprowadzaj=B1c b=B3=EAdu: nawet dla dobrego programisty b=EAdzie stanowi=E6=
> to
> problem, bo chocia=BF potrafi on zmininalizowa=E6 to prawdopodobie=F1stwo,
> operacja ta wymaga czasu i niekiedy wsp=F3=B3pracy dodatkowych ludzi,
> nierzadko wcale powoduj=B1c, =BFe bardziej si=EA op=B3aca napisa=E6 ca=B3=
> =B1 cz=EA=B6=E6
> programu od nowa, ni=BF poprawia=E6 po partaczu. Dlatego te=BF wsz=EAdzie,
> gdzie b=B3=EAdy w programie maj=B1 powa=BFniejsze konsekwencje ni=BF par=EA=
> job=F3w
> na forach, raczej unika si=EA zatrudniania kolesi, kt=F3rzy uwa=BFaj=B1, =
> =BFe
> nie ma problemu, jak napisz=B1 kaszaniasty, trudny w utrzymaniu kod, o
> ile tylko "dzia=B3a".

twoj post ma slaby

http://dl.dropbox.com/u/42887985/untitled.jpg

;-) tak czy owak szczerze mowiac nie jest to dla mnie
specjalnie ciekawe, napieprzanie na mnie czy innych
nazwijmy to 'cieniaków' nie ma wiekszego sensu, ile
razy mam powtarzac ze w sensie umiejetnosci praktycznych
nie jestem zbyt dobrym programista jak na dzis, ale z
czasem jednek jest powoli lepiej (tak naprawde to wlasnie
za duzo sie przepracowywuję.. jest to 100% pewne),
zamiast tluc te nudy-pudy wolalbym juz pogadac
o sherlocku holmesie albo o tych malych wróżkach co
mieszkają w kwiatach (podobno) cynka tinkerbell i inne..
(troche zartuje ale fajnie by bylo przełaczyć klimat
- na jakis madrzejszy

fir







--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 10/10/2011 04:25 PM, Andrzej Jarzabek wrote:
[..]
> Otóż prawdopodobieństwo wprowadzenia błędu przy modyfikacji
> istniejącego kodu zależy nie tylko od umiejętności modyfikującego, ale
> w dużej mierze od jakości tego istniejącego kodu. Im gorszy
> programista, tym trudniej wprowadzić zmianę do jego kodu nie
> wprowadzając błędu: nawet dla dobrego programisty będzie stanowić to
> problem, bo chociaż potrafi on zmininalizować to prawdopodobieństwo,
> operacja ta wymaga czasu i niekiedy współpracy dodatkowych ludzi,
> nierzadko wcale powodując, że bardziej się opłaca napisać całą część
> programu od nowa, niż poprawiać po partaczu. Dlatego też wszędzie,
> gdzie błędy w programie mają poważniejsze konsekwencje niż parę jobów
> na forach, raczej unika się zatrudniania kolesi, którzy uważają, że
> nie ma problemu, jak napiszą kaszaniasty, trudny w utrzymaniu kod, o
> ile tylko "działa".

Zawsze chciałem spytać, a nie miałem okazji:

czym się różni "kaszaniasty, trudny w utrzymaniu kod" od takiego,
który taki nie jest?

Ja może mam swój pogląd, ale jestem ciekawy, jak ktoś to zdefiniuje.

Edek

do góry

On 10/10/2011 05:57 AM, Andrzej Jarzabek wrote:
> On 09/10/2011 19:52, Wojciech Jaczewski wrote:
>> Andrzej Jarzabek wrote:
>>
>>> Nie omówić. Wypytać. Oczywiście będzie to obarczone jakimś tam błędem,
>>> ale raczej niewielkim.
>>
>> Zaintrygowała mnie ta odpowiedź.
>>
>> Uważam, że mi od jakiegoś czasu udaje się tworzyć nie-wywalające się
>> programy - oczywiście przy pierwszych uruchomieniach czasem się i wywalą,
>> ale po poprawieniu działają już dobrze. Dużo trudniej jest doprowadzić do
>> tego, aby każdy szczegół działał zgodnie z wymaganiami, niż do tego aby
>> program się nie wywalał.
>
> Zgodzę się, że to jest trudniejszy problem, ale to nie jest tylko
> kwestia umiejętności programisty. Zresztą samo "wywalanie się" to był
> skrót myślowy, możemy sobie rozszerzyć czy dodefionować pojęcie na
> nieprawidłowe działanie programu wynikające z błędu programistycznego, w
> przeciwieństwie do błędnego czy niedostatecznego sformułowania lub nie
> do końca zrozumienia wymagań.

Skrajne podejście do sprawy: pisanie kodu to spełnienie wszystkich
ograniczeń, z czego jednym z ograniczeń są wymagania. To eksperyment
myślowy, ale też prawda.

>
>> Jednak jedyne co mógłbym powiedzieć o "technice", jak to robię jest:
>> robić
>> najprościej jak się da i realizować wyłącznie tę funkcjonalność, która
>> jest
>> wymagana. Taka odpowiedź miałaby jednak taką wadę, że do takiej
>> odpowiedzi
>> każdy, niezależnie od doświadczenia i umiejętności, mógłby przygotować
>> się w
>> minutę, a jednocześnie: to co jeden uważa za program prosty, dla drugiego
>> może być programem bałaganiarskim.
>
> No ale jeśli kandydat powie coś takiego na rozmowie, to oczywistym jest
> kolejne pytanie, co konkretnie robi, żeby jego kod był prosty. Zeby
> podał jakieś konkretne przykłady ze swojej praktyki na przykład, albo
> odpowiedział na pytanie - jeśli funkcja ma realizować skomplikowaną
> działalność, jak ją napisać, żeby była prosta. Dwie do pięciu minut na
> odpowiedź dużo ci powie.

Dodam:
Podziwiam ludzi, którzy mówią o prostocie i zawsze się zastanawiam,
czy rozumieją. Każdy problem ma wiele błędnych ale prostych rozwiązań,
w wielu dziedzinach przybliżony wynik nie spełnia wymagań. W zasadzie
zgodnie z zasadą prostoty nie powinien istnieć skomplikowany kod,
a z empirycznych, moich przynajmniej, doświadczeń ze światem kod
skomplikowany istnieje i ma się dobrze, a co najważniejsze działa
i swięcie wierzę w to, że autorzy co jak co ale uprościli go ile
się da i dalej się nie da.

Dla mnie każdy, kto zaczyna od tekstu keep it simple jest lekko
podejrzany. Co nie znaczy, że do wielu zadań się nie nadaje i że
ja sam komplikuję sprawy bez powodu.

>
>> Jeśli możesz, to przedstaw, jakie wg Ciebie techniki się wykorzystuje
>> podczas robienia nie-wywalających się programów (wystarczy mi odnośnik do
>> jakiegoś tekstu). Powinny spełniać następujące kryteria:
>> - pomagać w osiągnięciu celu
>> - być czasochłonne w nauczeniu się (bo gdyby dało się jej nauczyć w
>> dzień-
>> dwa, to nie byłoby sensu selekcjonować kandydatów wg kryterium znajomości
>> tej techniki).
>> - ma być trudno o nich opowiadać, jeśli samemu nie umie się ich
>> wykorzystać.
>
> Jest sporo takich technik, i o ile jest kilka w miarę uniwersalnych
> (abstrakcja, czytelność, w tym ograniczenie długości funkcji, code
> reuse, unit testing), to sporo jest zależnych od technologii (MT, OO,
> exception safety, konkretny język programowania). Co do tekstu, no to
> jest sporo książek traktujących o tych tematach, od ogólnych typu "Code
> Complete" Steve'a McConnella, "Refactoring" Martina Fowlera et al. Jeśli
> chodzi o C++ to np. "Effective C++" Scotta Meyersa itd.

...ale i tak wszystkie to gówno, jeżeli ktoś tylko przeczytał te
książki. Znam sporo osób, które przynajmniej jedną z powyższych
zasad dość świadomie olewają, a to co piszą jest łatwe w rozszerzaniu,
debugowaniu, utrzymaniu itd. Jest coś ze słowa "Art" w Programming,
chyba nie chodzi o kreatywność.

Techiniki, jest ich dużo: exception safety,
w tym nie zostawianie otwartych plików, sprawdzanie różnych
rzeczy w kodzie (inwarianty, proste null checki), jeżeli nie
ma garbage collection to unikanie leaków, jeżeli jest też,
testy, czytelność kodu, enkapsulacja, dzielenie problemu na mniejsze,
dbałość o odpowiednie sygnalizowanie błędów (nie BSOD ani "Exception:
Error Occured"), złożoność algorytmiczna (żeby test z 10 elementami
nie zajął 1/1000 tego co ze 100 elementami), komentowanie kodu,
nie robienie różnego rodzaju głupot (wbrew pozorom pewien problem
czasami, nie mówię o błędach), wzorce projektowe, o ile ktoś wie
jak ich używać (swoją drogą w C++ mówi się raczej o idioms),
RTFM jeżeli używa się funkcji systemowych i/lub bibliotek,
jak ktoś się bierze się za wątki, to musi mieć wyobraźnię
i znać zasady, umiejętność korzystania z języka w tym
z kompilatora i innych narzędzi, również
w celu unikania błędów - każdy język ma swoją specyfikę, na
przykład jeżeli chodzi o nie zainicjalizowane zmienne, type
safety, ostrzeżenia kompilatora, na czym można polegać,
a na czym nie itd. itp., nie wiem czy cześciej nie jest problemem
to, że ludzie padają na sprawach banalnych, niż na braku znajomości
wyrafinowanych reguł, a o drobiazgi "wolno" pytać.

Do tego każda dziedzina, w tym język, ma swoją specyfikę,
o którą można zapytać.

>
> W ogóle to można jeszcze zwrócić uwagę na istotny aspekt całej sprawy: w
> pisaniu programów, które się nie wywalają, samo to, że napiszesz program
> i on się nie wywala to jest tylko wierzchołek góry lodowej. Bardzo
> istotne jest również to, żeby program napisany przez ciebie nie wywalił
> się jak inny programista zacznie wprowadzać w nim zmiany, być może długo
> po tym i być może nie mając do ciebie dostępu i nie mogąc cię spytać
> dlaczego jest tak a nie inaczej. Oczywiście nie da się napisać programu
> tak, żeby inny programista nie mógł wprowadzić do niego błędów, ale też
> prawdopodobieństwo wprowadzenia później błędów jest mocno uzależnione od
> jakości pierwotnego kodu. Niby jest to oczywiste, ale myślę, że niejeden
> profesor kenobi by się przejechał na tym punkcie jak nic.

W konkursach nie to jest najważniejsze ;)

Edek

do góry

Dnia Mon, 10 Oct 2011 20:03:41 +0200, Edek napisał(a):
> Zawsze chciałem spytać, a nie miałem okazji:
>
> czym się różni "kaszaniasty, trudny w utrzymaniu kod" od takiego,
> który taki nie jest?
>
> Ja może mam swój pogląd, ale jestem ciekawy, jak ktoś to zdefiniuje.

O, tu masz niezgorsze zestawienie:
http://en.wikipedia.org/wiki/Anti-pattern

Pozdrawiam,
Waldek

do góry

On 10/10/2011 09:59 PM, Waldek M. wrote:
> Dnia Mon, 10 Oct 2011 20:03:41 +0200, Edek napisał(a):
>> Zawsze chciałem spytać, a nie miałem okazji:
>>
>> czym się różni "kaszaniasty, trudny w utrzymaniu kod" od takiego,
>> który taki nie jest?
>>
>> Ja może mam swój pogląd, ale jestem ciekawy, jak ktoś to zdefiniuje.
>
> O, tu masz niezgorsze zestawienie:
> http://en.wikipedia.org/wiki/Anti-pattern

Znam lepsze źródła, gdzie jest miejsce na dyskusję z poczuciem humoru.

Generalnie, definiujesz kod jako "kaszaniasty i trudny w utrzymaniu"
wg. tej strony wikipedii, z której połowa jest nie na temat
(zarządzanie)? Według Ciebie review to check-lista z antywzorcami?
Jakby to było takie proste, to byłyby toole, które to sprawdzają.
A jest takich tooli mało i zazwyczaj więcej jest z nimi problemów
niż jest z nich pożytku; na pewno człowieka nie zastępują.

Edek

PS. Design by Comitee moim zdaniem definitywnie szczytuje, lepsze
jest Herb Sutter From M$ Knows Best (Tm)

PS2. Nie zareaguję na flame, nie o to mi chodzi, możesz mnie nazwać
Natural Born Anti Pattern Programmer From Anti Anti Hell i nic...
zobacz wykrzyknik na stronie.

do góry

On 10/10/2011 09:59 PM, Waldek M. wrote:
> Dnia Mon, 10 Oct 2011 20:03:41 +0200, Edek napisał(a):
>> Zawsze chciałem spytać, a nie miałem okazji:
>>
>> czym się różni "kaszaniasty, trudny w utrzymaniu kod" od takiego,
>> który taki nie jest?
>>
>> Ja może mam swój pogląd, ale jestem ciekawy, jak ktoś to zdefiniuje.
>
> O, tu masz niezgorsze zestawienie:
> http://en.wikipedia.org/wiki/Anti-pattern

Po chwili zastanowienia:

dla Ciebie wzorce i antywzorce to Silver Bullet? Sprawdź listę ;P

Edek

do góry

On 10/10/2011 19:08, Edek wrote:
> On 10/10/2011 05:57 AM, Andrzej Jarzabek wrote:
>>
>> Zgodzę się, że to jest trudniejszy problem, ale to nie jest tylko
>> kwestia umiejętności programisty. Zresztą samo "wywalanie się" to był
>> skrót myślowy, możemy sobie rozszerzyć czy dodefionować pojęcie na
>> nieprawidłowe działanie programu wynikające z błędu programistycznego, w
>> przeciwieństwie do błędnego czy niedostatecznego sformułowania lub nie
>> do końca zrozumienia wymagań.
>
> Skrajne podejście do sprawy: pisanie kodu to spełnienie wszystkich
> ograniczeń, z czego jednym z ograniczeń są wymagania. To eksperyment
> myślowy, ale też prawda.

Mówiliśmy o tym, co należy do kompetencji programisty. Programista nie
musi i zwykle nie będzie znał wszystkich wymagań, a w praktyce raczej
rzadko się zdarza, żeby była specyfikacja wymagań, która jest kompletna,
bezbłędna i jednoznaczna. Oczywiście sztka robienia programu tak, żeby
był zgodny ze wszytkimi wymaganiami jest też istotna, ale rola
programisty w tym wszystkim zależy od różnych rzeczy, na przykład od
procesu, poza tym jest to proces iteracyjny, gdzie w danej kolejnej
iteracji zazwyczaj się pisze program mniej lub bardziej nie spełniający
wymagań itd. itd., to jest temat rzeka.

Ja akurat pisałem o aspekcie niezawodności, bo on jest ściśle związany z
umiejętnościami programisty, a z drugiej mowa o dziedzinach, gdzie
często niezawodność ma duże znaczenie.

> Podziwiam ludzi, którzy mówią o prostocie i zawsze się zastanawiam,
> czy rozumieją. Każdy problem ma wiele błędnych ale prostych rozwiązań,
> w wielu dziedzinach przybliżony wynik nie spełnia wymagań. W zasadzie
> zgodnie z zasadą prostoty nie powinien istnieć skomplikowany kod,

Każde rozwiązanie ma też wiele sposobów wyrażenia, które mogą być
prostsze lub mniej proste (w zasadzie jeśli w tym kontekście ma być
jakieś przeciwieństwo prostego, to raczej lepiej niż "skomplikowane"
wyraża o co chodzi określenie "zagmatwane").

> a z empirycznych, moich przynajmniej, doświadczeń ze światem kod
> skomplikowany istnieje i ma się dobrze, a co najważniejsze działa
> i swięcie wierzę w to, że autorzy co jak co ale uprościli go ile
> się da i dalej się nie da.
>
> Dla mnie każdy, kto zaczyna od tekstu keep it simple jest lekko
> podejrzany. Co nie znaczy, że do wielu zadań się nie nadaje i że
> ja sam komplikuję sprawy bez powodu.

Powiem tak: pisanie kodu robiącego skomplikowane rzeczy tak, żeby był
prosty jest trudne i jest jedną z najważniejszych umiejętności
programisty. Niestety również jest to rzecz, którą ciężko sprawdzić u
kandydata na rozmowie.

Poza tym rzeczywiście samo pojęcie "prostoty" jest problematyczne -
czasem lepszy projekt wymaga np. dodatkowych klas, interfejsów, relacji
czy czego tam i intuicyjnie wcale nie można określić go jako "prostszy".

>> Jest sporo takich technik, i o ile jest kilka w miarę uniwersalnych
>> (abstrakcja, czytelność, w tym ograniczenie długości funkcji, code
>> reuse, unit testing), to sporo jest zależnych od technologii (MT, OO,
>> exception safety, konkretny język programowania). Co do tekstu, no to
>> jest sporo książek traktujących o tych tematach, od ogólnych typu "Code
>> Complete" Steve'a McConnella, "Refactoring" Martina Fowlera et al. Jeśli
>> chodzi o C++ to np. "Effective C++" Scotta Meyersa itd.
>
> ...ale i tak wszystkie to gówno, jeżeli ktoś tylko przeczytał te
> książki.

Zgadza się. Co więcej, można nie przeczytać wcale tych książek, a
wszystkie te rzeczy mieć opanowane. Ale przedpiśca chciał mieć namiary
na teksty, to ma.

A jeśli chodzi o sedno sprawy, to chociaż tych książek nie da się
przeczytać w pół dnia, to wydaje mi się, że nie będzie strasznie
problematyczne wyczajenie na rozmowie kwalifikacyjnej, czy ktoś te
książki "tylko przeczytał", czy zna problemy z praktyki.

I: jeśli ktoś jest programistą z jakąkolwiek praktyką, ale bez
znajomości dobrych praktyk, ale dla dostania pracy przeczyta wszystkie
te książki i przygotuje się do odpowiadania tak, jakby stosował je w
praktyce, to potencjalnie jest bardzo dobrym programistą i cennym
pracownikiem.

> Znam sporo osób, które przynajmniej jedną z powyższych
> zasad dość świadomie olewają, a to co piszą jest łatwe w rozszerzaniu,
> debugowaniu, utrzymaniu itd. Jest coś ze słowa "Art" w Programming,
> chyba nie chodzi o kreatywność.

Czemu nie, nikt nie twierdzi przecież, że wszystkie praktyki i techniki
powinny być zawsze i wszędzie stosowane.

> Techiniki, jest ich dużo: exception safety,
> w tym nie zostawianie otwartych plików, sprawdzanie różnych
> rzeczy w kodzie (inwarianty, proste null checki), jeżeli nie

Też w tym temacie: kiedy stosować assert.

> [...] komentowanie kodu,

A właśnie: spotkałem się z opinią, do której się przychylam, że jeśli w
kodzie potrzeba wielu komentarzy, to wskazuje to na problem z jego
strukturą, że raczej należy starać się pisać kod tak, żeby komentarz nie
był potrzebny.

> a na czym nie itd. itp., nie wiem czy cześciej nie jest problemem
> to, że ludzie padają na sprawach banalnych, niż na braku znajomości
> wyrafinowanych reguł, a o drobiazgi "wolno" pytać.

Ale też często padnięcie na sprawie banalnej jest wynikiem nie
zastosowania wcześniej wyrafinowanej reguły.

>> prawdopodobieństwo wprowadzenia później błędów jest mocno uzależnione od
>> jakości pierwotnego kodu. Niby jest to oczywiste, ale myślę, że niejeden
>> profesor kenobi by się przejechał na tym punkcie jak nic.
>
> W konkursach nie to jest najważniejsze ;)

Racja. W konkursach jest najważniejsze, żeby wypić litr piwa w sześć sekund.

do góry