On 16/10/2012 00:51, M.M. wrote:
> W dniu poniedziałek, 15 października 2012 23:59:13 UTC+2 użytkownik Andrzej
Jarzabek napisał:
>
>> sieczka gdzieniegdzie zrobi, to da się ją posprzątać. Powiesz, że
>> klienta nie interesuje, czy jest sieczka, czy nie. Ale czy nie
>> interesuje go również, czy zaimplementowanie kolejnego wymagania zajmie
>> dwa tygodnie, czy - z powodu sieczki - dziesięć? Czy nie interesuje go
>> ile razy na miesiąć system będzie padał i jaki będzie miał downtime?
> Raczej powiem że w praktyce nie potrafię albo przepchnąć takiej argumentacji,
> pomimo że moim zdaniem też jest oczywista, albo w praktyce zrobienie dobrego
> projektu jest w ogóle trudne do osiągnięcia.

Tru dat. Dlatego w swojej masie projekty programistyczne przekraczają
budżety, terminy i produkują duże ilości bugów. Ale tak w ogóle da się
zrobić dobrze, i nawet nie o to chodzi, że zrobienie dobrze jest trudne
samo w sobie - jest trudne w pewnych organizacjach, z pewnycmi ludźmi,
dla pewnych klientów.

> Chodzi mi o taką praktykę...
> jakby to zgrabnie określić, może... całą praktykę biznesową, nie tylko
programistyczną.
> Nie potrafię przepchnąć takiej argumentacji w najróżniejszych okolicznościach. A to
w
> rozmowie z kolegą z zespołu ciężko, bo zaraz rozmowa przyjmie taki ton, że
> uważam iż on zrobił sieczkę a nie porządny kod. Gdy poczuje zagrożenie z mojej
> strony, to strach się bać co mi za plecami odwinie.

Znaczy ne należy przyjmować takiego tonu z jednej strony, ale z drugiej
też nie należy się bać. Po pierwsze można od razu powiedzieć, że to nie
musi być czyjaś wina, że robi sieczkę, tylko że taka jest naturalna
tendencja w kodzie utrzymywanym na dłuższym odcinku czasu. I może w
ogóle lepiej przedstawić całą sprawę jako "odkryłem zajebisty sposób na
to, żeby nie mieć problemów takich, jakie mamy" niż "robisz kaszanę,
kaszaniarzu".

Z drugiej strony jeśli nie można powiedzieć, że coś dobrze by było
naprawić czy zrobić lepiej, bo od razu ktoś poczuje się urażony, to też
nie jest najzdrowsza sytuacja.

> Z managementem ciężko, bo łatwo górę bierze chciwość i zaoszczędzenie odrobiny
czasu.

Znowu, można próbować przekonać, że jeśli program ma być dalej
rozwijany, to tak będzie szybciej i taniej. Jeśli nie są przekonani, to
można zbierać na nich kwity w postaci "mogę to zrobić trochę szybciej
teraz, ale jeśli dalej będzie ten program trzeba utrzymywać, to będzie
to trwało przez to dłużej i będzie więcej bugów, proszę o decyzję" - jak
masz na piśmie kilka decyzji "zrób szybciej teraz, chrzanić później" -
to potem możesz pokazać, że bugi, zawalone terminy itd. wynikają
bezpośrednio z decyzji managementu. :)

> Z klientem to już w ogóle najtrudniej, bo klient nie dysponuje odpowiednią
> wiedzą, a często chce narzucać pewne rzeczy.

Ale chyba raczej niekoniecznie to, jak ma wyglądać kod.

> Kolejna sprawa to wypada operować konkretami.

Ale właśnie o to chodzi, że zwykle nie ma konkretów, są tylko
niewiadome. O sensowne danej liczbowe też ciężko, najlepiej chyba w
takiej sytuacji wyjść z takiej pozycji, że jako praktyk masz opinię, że
lepiej (taniej, szybciej) będzie właśnie tak i tyle, a jak chcą zrobić
inaczej, to potem mogą mieć tylko pretensje do siebie.

> Trzeba podać jakie rozbudowy, o ile przyspieszą późniejszy czas wykonania,
> itd.

Jak już masz rzucać jakąś liczbą, to ja bym rzucił taką, że sensowne
oszacowanie wysiłku to 20% tego wysiłku - i to się nie wlicza do dalszej
pracy, czyli jak zrobienie czegoś będzie trwało 10 miesięcy, to
oszacowanie tego faktu zajmie miesiące dwa, a oszacowanie i zrobienie 12.

> Nie da się przecież tak zaprojektować programu, żeby zupełnie każda modyfikacja
była w
> przyszłości łatwa.

Da się (relatywnie), tylko nie tak, jak myślisz. Projektowanie programu
od początku tak, żeby był jak najbardziej elastyczny jest niewłaściwą
techniką.

> Z kolei żeby operować konkretami to trzeba dobrze znać dziedzinę, ale
> nawet jak się zna dziedzinę to jest trudno oszacować czas i próg opłacalności.

IMO znajomość dziedziny niewiele ci da. Tego, co zajmie ci najwięcej
czasu i tak i tak nie przewidzisz.

> W mojej praktyce nigdy większego projektu nie robiłem dla dziedziny o której
> na starcie miałem pojęcie. Zawsze musiałem douczyć się na szybko. Właściwie to
> nie wiedziałem nawet co w ogóle może być użyteczne w systemie i jakie rozbudowy
> zaproponować.

Najlepiej w ogóle nic nie proponować. Jedyne, co trzeba ustalić, to czy
klient sam będzie chciał rozbudowy - z mojego doświadczenia wynika, że o
ile używa programu, to będzie.

> W takich warunkach musiałem oszacować czas, cenę i, co tu dużo mówić,
> odgadnąć jaki projekt będzie najlepszy. Nie można bez dobrej znajomości dziedziny
zrobić
> dobrego projektu, można go co najwyżej odgadnąć.

E tam. Zrobienie dobrego projektu nie ma wiele wspólnego z
przewidywaniem przyszłych wymagań. Jeśli program spełnia wyamagania
aktualne, a przy tym ma prostą konstrukcję i czytelny kod, to już
projekt jest dobry.

> Kolejny problem jest taki, że krótko po
> rozpoczęciu chcą zobaczyć jakiś prototyp, tak jakby dla pewności że prace w
> ogóle trwają.

No więc praca w ten sposób, żeby bieżący stan można było krótko po
rozpoczęciu i często potem demonstrowac jest bardzo dobrą praktyką...

> Prototyp wprost z definicji da się wykonać na skróty.

...tylko że do tego nie należy stosować prototypu w takim sensie.

Takie prototypy (zwane niekiedy spike solutions) mają prawo bytu, ale
przy zrozumieniu, że po wykonaniu są wwyrzucane, więc jako takie nie
dają żadnej pewności, że "prace trwają".

Natomiast owszem, jak najszybsze doprowadzenie kodu właściwego do stanu,
w którym można pokazać, że działa, jest bardzo wartościowe. Ale to
wszystko pod warunkiem, że wszystko jest obwarowane solidnymi testami i
porządnie napisane.

> Chociażby
> można go zrobić bez uprzedniego przemyślenia jak będzie testowany, ale jest
> więcej pułapek. Potem przy przechodzeniu z prototypu do pełnej wersji może nagle
> się okazać, że program będzie bardzo trudny w testowaniu.

Najlepiej zatem zacząć od pisania testów.

> We wszystko powyższe czasami wplata się problem wydajnościowy, a kod
> po zoptymalizowaniu to już masakra w utrzymaniu.

Bo ja wiem? Niezrozumiałe identyfikatory wcale nie działają szybciej od
zrozumiałych. Zamiana bloku kodu w funkcji na wywołanie funkcji inline
niczego nie spowalnia. W C++ nawet obiektowe wrappery na proste typu nic
nie kosztują.

> P.S.
> Czy widac polskie znaki?

Bez problemu.