On Fri, 19 Jul 2013 00:05:48 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
>komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
>przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
>komentarze są bez sensu.
>

Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
CO. Inaczej zrobi sie niekontrolowany burdel

>To, co przedstawiasz, to fałszywa alternatywa. Albo zatrudniasz
>fachowców i wtedy masz wybór między zatrudnianiem fachowców i
>testowaniem a zatrudnianiem fachowców i nie testowaniem,

To jest nonsens. WSZYSCY robia bledy, rowniez wysoko kwalifikowani
fachowcy.

>Jakie testy do testów? Do testów nie piszesz testów przecież.

Pisze sie testy do testow. Ja pisalem, na przyklad. Testy moga byc
calkiem skomplikowanymi procedurami. Musi byc pewnosc ze test jako
taki dziala prawidlowo. Z rdguly test polega na tym ze dla okreslonych
danych wejsciowych metoda musi generowac okreslone wyniki. Ale to czy
ustalilismy JAKIE wyniki sa prawidlowe? I czy jak ktos cos zmieni w
tescie, to przypadkiem nei spieprzy testu?

Przyklad - pewna metoda rozwiazuje "w srodku" zadanie metoda
Programowanie Liniowego. Tezt musi sparedzic czy dla okreslonych
danych wynik jest prawidlowy. Wiec tez musi rozwiazac zadanie
programowania liniowego, ale metoda "na skroty" - z pominieciem calej
zlozonosci testowanej metody. Czy to obliczanei "na skroty" ma sens?
Do tego potzrebny jest test

Oczywiscie, nikt nei robi tego w nieskonczonosc, ale test do testu to
czesto spotykana praktyka

Poza tym koncepcja ze "siada sie i pisze test a potem implementacje"
sprawdza sie tylko przy programowaniy "getters" i "setters".

> Co to jest
>w tym przypadku "moduł weryfikujący"? Testy jednostkowe (a także
>acceptance tests) są testowane w metoldach TDD ręcznie w bardzo prostu
>sposób - zaczynasz od pisania testu, jeśli test przechodzi, znaczy że
>jest źle napisany.

Ze co?...

>Następnie implementujesz to, co test testuje i
>regularnie zapuszczasz testy, jeśli testy przejdą zanim skończysz, to
>znaczy że test jest źle napisany. Jeśli skończysz, a test nie
>przechodzi, to dedukujesz tradycyjnymi metodami dlaczego i albo
>znajdujesz błąd w kodzie, albo w teście.
>

Przepraszam, ale to nei ma sensu. Wiem ze to jest napisane w
ksiazkach, ale to niczego nei dowodzi

>> Wszystko to zabiera czas i zasoby (ludzkie, nie komputera). A tych
>> zasobów jest ograniczona ilość.
>
>Oczywiście, ale konsekwencje braku unit testów (i innych testów
>automatycznych) często zabierają więcej czasu i zasobó niż pisanie tych
>testów.
>

W normalnych warunkach pzremyslowych czas projektu oblicza sie z
testami. Srednio 75% kodu pisanegp pzrez programiste to sa testy.

Jak u mnie, testy sa puszczane kazdej nocy pzrez specjalny zespol
zajmujacy sie testowaniem. Maja do tego dedykowany hardware i dosyc
skomplikowany software. Dodatkowo, kazdy programista musi puszczac
testy, i jak robi "check in" do systemu kontroli kodu (Subversion
konkretnie) to musi miec pewnosc ze jego testy pzrechodza. Jak nei
pzrechodza i wykryje to team testujacy, to programista dostaje
starszny opierdol

A.L.

do góry

On Fri, 19 Jul 2013 01:38:36 +0100, Roman W
<b...@g...pl> wrote:

>On Thu, 18 Jul 2013 08:09:35 -0500, A.L. <a...@a...com> wrote:
>> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme
>Programming
>> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
>
>No więc ja pracuję w firmie ktora buduje cos czego nikt inny przedtem
>nie zrobil, i wymagania wobec systemu zmieniają sie praktycznie co
>tydzień w miarę jak uczymy sie nowych rzeczy o tym czego potrzeba
>klientom, czego klienci myślą ze im potrzeba i jakie sa warunki
>przyrodnicze w których to ma byc zrealizowane. I Agile jest w
>zasadzie jedynym rozwiązaniem: żeby przeżyć i osiągnąć swoj cel,
>firma nie moze reagować na zmianę wymagań i uwarunkowań z
>parotygodniowym opóźnieniem potrzebnym na uzgodnienie aneksu do
>umowy.
>

Jezeli macie klientow ktorzy sa gotowi placic za wasza nauke i
pomylki, to nic tylko pogratulowac. Ale obawiam sie ze to raczej
wyjatek niz regula

A.L.

do góry

On Thursday, 18 July 2013 15:09:35 UTC+2, A. L. wrote:
> On Thu, 18 Jul 2013 04:47:22 -0700 (PDT), Adam Klobukowski
>
> <a...@g...com> wrote:
>
> >Nigdy nie napisałem że metodologia Agile jest najlepsza.
>
> >Tu nie chodzi o to że programiści źle zrozumieli. Zasadą metodyk Agile jest to że
wymagania są płynne i mogą się zmienić. Taka zmiana nie jest czymś negatywnym.
>
> No, ale to przeciez od zawsze bylo. Pisal sie ansksy do omowy i tak
> dalej. Ale wszystko zalatwialo sie porzadnie a nei an "urrraaa"

Od zawsze? Zmiana wymagań w klasyczynych metodach wytwarzania oprogramowania to
zawsze problem, bo założeniem jest że wymagania nie powinny się zmieniać. W Agile
nigdy, bo założenie jest że wymagania się zmienią.

> >> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
> >> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
> >> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
> >> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
> >> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
> >> w sadzie. O czym prasa fachowa od czasu do czasu donosi
>
> >Nie chodzi też o odstępstwa od umowy. Wystarczy podpisać umowę która zakłada że
finalny produkt może się zmienić.
>
> Buduje dom, Ustalamy ze ma byc dom i w zasadzie moze nadawac sie do
> mieszkania. Przychodza chlopcy i leja beton. I mowia: jak sie cos nei
> spodoba to potem odkujemy. I drapia sie w glowe: tu pierdykniemy
> sreczyk a tu kuchnie. Kuchnia bedzie na pieterku a sraczyk w piwnicy.
> ten facio co bedzie tu mieszkal i tak nei ma pojecia. A mysmy tu tylle
> domow wybudowali... No a w koncu w umowie jest napisane ze mzoemy
> sobie wybudowac co chcemy
>
> Tak sie domow nie buduje. I softu tez. Byc moze gdzies sie buduje. Ale
> nei slyszalem.

Domy to nie oprogramowanie. Porównywać można, ale budowa oprogramowania to zupełnie
co innego niż budowa domu.


> >Przy budowie każdego dużego systemu informatycznego wymagania zmieniają się
praktycznie zawsze. Czas powstawania dużego projektu to zazwyczaj co najmniej rok,
zazwyczaj więcej. W tym czasie wiele może się zmienić. W przypadku klasycznych
metodologii, klient zazwyczaj widzi system dwa razy - jak mu go sprzedają i jak mu go
dostarczają. Odstęp czasowy pomiędzy tymi momentami jest dużym problemem. To że
klient coś zamówił, to nie znaczy że jak to dostanie to właśnie tego chce.

>
> Przy budowie duzego systemu informatycznego projekt dzieli sie na
> etapy - ?\"milestones'. Po kazdym etapie nastepuje pzreglad zgodnosci
> z umowa. Jezeli cos sie nie zgadza algo klientowi sie cos odwidzialo,
> pisze sie "protokol niezgodnosci", potem ustala sie dalsza akcje.
> Czestosc takich spotkan zalezy od umowy. W piecioletnim projekcie z
> klientem w Euuropie a firma robiaca soft w USA takie spotkania byly co
> 6 miesiecy.

W przypadku Agile reprezentant klienta uczestniczy w projekcie na bierząco. Nie co 6
miesięcy, ale założenie jest że jest on członkiem zespołu wytwarzającego system.

> >W przypadku Agile, klient jest włączony w cały proces powstawania systemu, często
może zacząć go używać już w trakcie jego powstawania. W ten sposób klient ma lepszą
widoczność tego jak system będzie wyglądał a kiedy (co nieuniknione) zmienią się jego
wymagania co do systemu, to wykonawca nie wypnie się mówiąc 'mieliśmy taką a taką
umowę' ale odpowiednio dostosuje się to tych wymagań. W ten sposób klient dostanie
produkt z jego punktu widzenia lepszy i lepiej dostosowany do tego do czego jest mu
potrzebny.

> Bez systemu Agile tez sie tak robi. Nazywa sie to "partial
> deployment". Gdy projekt trwa 5 lat, raczej nie czeka sie az caly
> projekt sie skonczy tylko oddaje po kawalku.

Owszem, ale w klasycznym modelu, zmiana już dostarczonych elementów to... problem. Z
Agile to normalna, wręcz oczekiwana praktyka.

> Wszsystkie "niowoczesne methodologie" typu Agile, Extreme Programming
> itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
> "Wicie, rozumicie, zastsowalismy najnowsza merodologie - Agile - i nie
> wyszlo. The act of God. Sila wyzsza"

W taki sposób rozumując, to każda metodologia jest dupochronem.

AdamK

do góry

On Thursday, 18 July 2013 15:55:29 UTC+2, Maciej Sobczak wrote:
> > Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.
>
> Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.
>
> Widziałem ostatnio (ale nie mam linka) takie rozważania, że w "tradycyjnej"
metodologii zmiany były kosztowne, ale wszyscy o tym wiedzieli - klienci też, dlatego
klienci *starali się*, żeby tych zmian było jak najmniej. Starali się przez
poważniejsze potraktowanie początkowych etapów, czyli analizy i zbierania wymagań.
>
> Agile niejawnie sugeruje, że zmiany były są i będą, w związku z tym są normalne -
czyli tanie. I przy takim założeniu klienci w ogóle się nie starają, przez co zmiany
są dużo częstsze, niż mogłby by być, gdyby się starali.
>
> Pytanie teraz: który wariant jest korzystniejszy.

Nikt nie mówił że zmiany będą tanie.

W metodologiach Agile, klient jest (teoretycznie) nieco głębiej zaangażowany w
projekt. W ten sposób, przy wprowadzaniu zmian ma lepszą widoczność kosztów zmian.
Przy założeniu że rezultaty projektu są widoczne wcześniej, zmiany też mogą pojawić
się wcześniej, co dodatkowo obniża ich koszt.

Zresztą Agile to nie tylko relacje klient-wytwórca. To też relacje wewnątrz wytwórcy
pomiędzy menagerami a zespołami wytwórczymi.

AdamK

do góry

On 2013-07-19 03:08, A.L. wrote:
>> wymagane, są podane jako przykład "dobrych" komentarzy. Jako zły rodzaj
>> komentarza było pisanie kto napisał przy poszczególnych kawałkach kodu,
>> przykład z książki "Added by Rick". No więc ja się zgadzam, że takie
>> komentarze są bez sensu.
> Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
> zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
> CO. Inaczej zrobi sie niekontrolowany burdel

Tym burdelem zarządza skutecznie system kontroli wersji powiązany z
jakąs bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na
programistów kończy się tak jak pliki nagłówkowe do mikrokontrolerów
Atmela które są perfekcyjnym anty-przykładem. Co chwile inna permutacja
fixów, wersji, numerków często identycznych, nieaktualnych komentarzy i
ad-hoc poprawek która wynika z założenia że historia pliku przechowywana
jest w nim i zarzadzana przez ludzi. Wyszła sieczka.

W dużym kodzie jedyne co wzbudza zaufanie to automat CVS.

do góry

W dniu 2013-07-17 17:56, A.L. pisze:
[...]
> To jest mniej wiecej takie pisanie jak to ze komunizm jest najlepszym
> ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta ktory placi
> dodatkowo za to ze programisci cos na odwrot zrozumieli.

Współpraca z klientem oznacza, że to nie programiści coś na odwrót
zrozumieli, tylko programiści i klient nie porozumieli się. W ramach
umowy zrobili wszystko, co trzeba - nie ma "winnych". Teraz mogą
zakończyć współpracę (bo się nie dogadują), albo zastanowić się nad
zmianą w metodach komunikacji (bo chcą dalej _współpracować_).

> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
> w sadzie. O czym prasa fachowa od czasu do czasu donosi

Tyle, że umowa może być albo "twarda" - czyli załącznikiem jest
kilkaset lub kilka tysięcy stron wymagań, albo "miekka" - z deklaracją
współpracy i krótkimi okresami rozliczeń i wypowiedzeń. Faktycznie to
drugie często wynika z tego, że klient sam nie wie dokładnie czego chce
i - co ważne - ma tego świadomość i nie boi się do tego przyznać. Taka
sytuacja bywa nieusuwalną cechą pewnych biznesów (być może nie tych,
z którymi masz styczność). A klient woli mieć choćby ułomny, ale jakoś
działający kawałek funkcjonalności za miesiąc. Jak poświęci choć dwa
tygodnie na negocjację umowy z załącznikami jak Biblia, to już jest
w plecy.

--
Paweł Kierski
n...@p...net

do góry

Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:v60hu8914m576u2i5utsudha48i9cbrkiv@4ax.
com...

>swobodnie agilowac. Ale obawiem sie ze nawet Przedsiebiorstwo
>Kanalizacyjne nie wmontowaloby sie w projekt bez ustalenia ile

Czemu nie? Jeżeli firma realizująca projekt należy do zięcia teścia
szwagra...

>deweloperem i patrzal mu na rece. Parcownicy Pzredsiebiorstwa
>Kanalizacyjnego musza sie bowiem zajmowac kanalizacja

Marzenie! Utopia!

do góry

Użytkownik "Paweł Kierski" <n...@p...net> napisał w wiadomości
news:ksau48$11u$1@somewhere.invalid...
>W dniu 2013-07-17 17:56, A.L. pisze:
> [...]
>> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
>> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
>> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
>> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
>> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
>> w sadzie. O czym prasa fachowa od czasu do czasu donosi
>
> Tyle, że umowa może być albo "twarda" - czyli załącznikiem jest
> kilkaset lub kilka tysięcy stron wymagań, albo "miekka" - z deklaracją
> współpracy i krótkimi okresami rozliczeń i wypowiedzeń. Faktycznie to
> drugie często wynika z tego, że klient sam nie wie dokładnie czego chce
> i - co ważne - ma tego świadomość i nie boi się do tego przyznać. Taka
> sytuacja bywa nieusuwalną cechą pewnych biznesów (być może nie tych,
> z którymi masz styczność). A klient woli mieć choćby ułomny, ale jakoś
> działający kawałek funkcjonalności za miesiąc. Jak poświęci choć dwa
> tygodnie na negocjację umowy z załącznikami jak Biblia, to już jest
> w plecy.

Z tego co ja widze, to AL nigdy nie mial stycznosci z klientem. Najwyrazniej
wlasnie bazuje na doniesieniach prasowych. Wyobrazanie sobie, ze klient od
razu wie czego chce, albo, ze ma czas i srodki zeby kazdy szczegol opisywac
dokladnie w setkach zalacznikow oraz omawiac na gremialnych spotkaniach to
jakas utopia. Albo chcesz wspolpracowac, albo napierdzielac sie i traktowac
caly swiat jak terytorium wroga. Ci drudzy zwykle szybko koncza wszelkie
biznesowe przygody (sprawdzic czy nie mafia).

do góry

Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:353hu8ddr8vgbq5kkva6tlbnk4phsdsuac@4ax.
com...

>Mam watpliwosci. Kod jes twspolna wlasnoscia. Kazdy mzoe zrobic
>zmiany. Jezeli zrobil zmiany, powinien te zmiany udokumentowac. KTO i
>CO. Inaczej zrobi sie niekontrolowany burdel

We wspomnianej książce Robert Martin nie ma nic przeciw "udokumentowywaniu",
jednak uważa, że tego rodzaju (kto np. napisał dany fragment) notki powinny
być w zapisywane osobno, w systemie kontroli wersji. I w czasie pracy nad
tekstem źródłowym programu po prostu ma ich być nie widać.

Autor ma prawo (chyba że go nie ma, tzn. kwestia na ile ma prawa do kodu, a
na ile te prawa ma np. firma) umieszczać informację kto jest autorem danego
dzieła (tj. pliku, fragmentu pliku) wprost w dziele, tj. np. właśnie
wewnątrz pliku. Zwłaszcza, że tego rodzaju wpis nijak nie wpływa na finalny
produkt (tj. nie jest kompilowany itd.)

Jeszcze inaczej: w każdej książce jest napisane, kto jest autorem. Gdyby zaś
konsekwentnie realizować pomysł Martina, to książki nie powinny zawierać
imienia i nazwiska autora, bo przecież te są dostępne w katalogu
bibliotecznym i/lub w bazie danych wydawnictwa.

Po pierwsze, integralność podpisu twórcy i dzieła jest uznawaną praktyką
(podpis Picassa na obrazie Picassa to chyba normalne?).

Po drugie, jest prawdopodobne że informacje o pliku z systemu kontroli
wersji mogą po prostu zaginąć.

Po trzecie, rozwiązania w rodzaju javadoc dobrze się sprawdzają - a przecież
dokumentacja też mogłaby być trzymana osobno, czyż nie...

Teraz kwestia widać-nie-widać. Jeżeli autor podpisał swoje dzieło, to trochę
szczeniackie jest udawać że kod jest anonimowy. A takim udawaniem jest
kasowanie komentarzy zawierających nazwiska autorów lub ukrywanie ich w inny
sposób.

do góry

Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:ksan9m$aue$...@n...news.atman.pl...

>Tym burdelem zarządza skutecznie system kontroli wersji powiązany z jakąs
>bazą danych bugs i bazą danych testów. Zrzucanie tego zadania na

Przecież nie trzeba pisać kto jest autorem książki/filmu - jakaś baza danych
wystarczy.

Przecież nie ma sensu aby malarz podpisywał się na obrazie - wystarczy że
mamy rachunek za malowidło.

do góry