> Jest gorzej. Jemzyki LoLoPe daja im mozliwosc paprania znacznie lepiej, niz
> do tej pory mogli to robic w GWBASIC i BASICA.
Każdy projekt i w każdym języku się spaprze gdy wymogi w przyszłości
nas zaskoczą. Dlatego lepiej jest zrobić gorszy projekt, mniej dopasowany,
ale bardziej odporny na zaskoczenia. Ostatnio dochodzę do wniosku, że
idealny projekt to taki, w którym mam dużo i obojętnie jak spapranych
części. Gdy przyszłość mnie zaskakuje, to cała część idzie do kosza i
jest pisana na nowo. Nikomu po czasie o tal nie będzie chciało się wgryzać w
stary kod.
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Użytkownik "fir" <p...@p...onet.pl> napisał w wiadomości grup
dyskusyjnych:5...@n...onet.pl
...
> dzieleni ich komentarzami na bloki czasem tak pisalem

I tak dochodzimy do wyższości Bożego Narodzenia nad Wielkanocą.

Przecież nikt nikomu nie każde pisać ciurkiem bez komentarzy. A to czy
podział będzie ujęty w same bloki klamerkami, czy jako oddzielne nazwane
procedury... to mało ważne.

Sens procedur (metod, jeżeli OOP) to budowanie kawałków kodu wykonujących
dobrze określone operacje na dostarczonych argumentach. Dlatego właśnie
podany przez ciebie przykład "wash-and-go" jest przykładem złego podejścia
do sprawy: wczytujesz bitmapę-robiszcośznią-iwypisujesz w jednej funkcji bez
podprocedur. A przecież bardziej naturalne byłoby mieć jedną procedurę do
wczytywania, drugą do robienia i trzecią do wypisywania. Potem skleić to w
całość w czwartej procedurze.

I oczywiście możliwe byłoby trywialnie prosto używanie np. innej
robiszcośznią. I parę innych rzeczy, np.:

int proc(char* nameIn,char* nameOut,int (*f)(char*))
{
BitmapType* bitmap;

int succed = 0;
if (readBitmap(nameIn,bitmap))
{
succed = f(bitmap) && writeBitmap(nameOut,bitmap);
free(bitmap);
}
return succed;
}

Oczywiście, nic nie stoi na przeszkodzie aby dać zmienną liczbę argumentów
itd. itp. - wtedy możesz łatwo zastosować kilka przekształceń itd. itp. - co
w wariancie "jedna duża procedura" - nie bardzo ci się uda. No chyba ze
obudujesz jakimiś switch-ami itd. itp. - ale wtedy będzie to już bardzo
bardzo nieczytelne.

do góry

Użytkownik <m...@t...pl> napisał w wiadomości grup
dyskusyjnych:5...@n...onet.pl
...
> Każdy projekt i w każdym języku się spaprze gdy wymogi w przyszłości
> nas zaskoczą. Dlatego lepiej jest zrobić gorszy projekt, mniej dopasowany,
> ale bardziej odporny na zaskoczenia. Ostatnio dochodzę do wniosku, że

???

Aby rozróżniać lepsze-gorsze potrzeba wprowadzić relację porządku, czyli
możliwość porównywania a < b .

Takich relacji można podać wiele różnych. Na przykład: wielkość programu,
szybkość jego działania... ale także zyski ze sprzedaży, przenośność,
łatwość obsługi itp.

Zawsze realizujesz - niezależnie od tego czy tego chcesz czy nie -
subiektywnie najlepszy projekt. Choć być może i tak, że kryterium będzie:
"zrobić najgorzej działający program, który doprowadzi firmę do upadku". Po
prostu ludzie działają subiektywnie racjonalnie.

> idealny projekt to taki, w którym mam dużo i obojętnie jak spapranych
> części. Gdy przyszłość mnie zaskakuje, to cała część idzie do kosza i
> jest pisana na nowo. Nikomu po czasie o tal nie będzie chciało się wgryzać
> w
> stary kod.

Jeżeli robisz cokolwiek odpowiedzialnego, to "wgryzanie się" może być
konieczne. Bo program jest komuś potrzebny, a potrzeby mają to do siebie, że
ewoluują. I łatwiej jest np. gdy zmienił się format danych nieco przerobić
2% kodu źródłowego - niż pisać wszystko od nowa.

Cały cyrk polega właśnie na umiejętności sprzedawania tego samego Burka -
czyli używania tego co się raz zrobiło - po wielokroć. Jeżeli potrafisz w
kolejnym projekcie użyć 90% ze starego... to po prostu piszesz 10x szybciej
i robisz 10x mniej błędów.

do góry

>

> > Jest gorzej. Jemzyki LoLoPe daja im mozliwosc paprania znacznie lepiej, niz
> > do tej pory mogli to robic w GWBASIC i BASICA.
> Każdy projekt i w każdym języku się spaprze gdy wymogi w przyszłości
> nas zaskoczą. Dlatego lepiej jest zrobić gorszy projekt, mniej dopasowany,
> ale bardziej odporny na zaskoczenia. Ostatnio dochodzę do wniosku, że
> idealny projekt to taki, w którym mam dużo i obojętnie jak spapranych
> części. Gdy przyszłość mnie zaskakuje, to cała część idzie do kosza i
> jest pisana na nowo. Nikomu po czasie o tal nie będzie chciało się wgryzać w
> stary kod.
> Pozdrawiam
>

mozna po prostu powiedziec ze tresc jest wazniejsz niz forma
- jesli ktos lepiej orientuje sie czy lepiej mu sie pisze
w kompletnym balaganie (a moze tak byc np nie traci energii
na mozolniejsze dopracowywanie tylko skupia sie na
najwazniejszych rzeczach - samym tworzeniu nowego a nie
formatowaniu go) to praca w takim balaganie moze
isc o wiele lepiej niz w porzadku - sam osobicie lubie domyslac
i dopracowywac dokladnie rozmaite szczegoly ale jak pisze
i chce szybko sprawdzic, jak mam jakis pomysl, jak cos wyjdzie,
robie zwykle balagan; choc znane mi jest tez uczucie potrzeby prob
cyzelowania i dopracowywania - poki co to co pisze jest
pisane na poly w trybie eksperymentow na zywym ciele kodu,
na poly zas sklada sie z przemyslanych technik i stylistyk,
ktorych sie mozlolnie dopracowalem w ciagu kilku lat prob i nauki
programowania




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> Aby rozróżniać lepsze-gorsze potrzeba wprowadzić relację porządku, czyli
> możliwość porównywania a < b .
W tym przypadku: Czas wykonania akceptowanej wersji przez klienta/użytkownika.

> Jeżeli robisz cokolwiek odpowiedzialnego, to "wgryzanie się" może być
> konieczne. Bo program jest komuś potrzebny, a potrzeby mają to do siebie, że
> ewoluują. I łatwiej jest np. gdy zmienił się format danych nieco przerobić
> 2% kodu źródłowego - niż pisać wszystko od nowa.
Dokładnie o to mi chodzi. Wywalam cały blok, który stanowi... od 1% do 5%
całości. Same bloki nie są porządnie napisane, są nastawione na całkowite
wywalenie. Natomiast cały projekt jest bardzo staranny. Mogę szybko
przeszkolić nowego programistę co do ogółów projektu. Szczegółów mu
oszczędzam, a sobie oszczędzam czas. On z kolei nie traci czasu na wgryzanie
się w stary kod. Pisze nową funkcjonalność i nie ma bladego pojęcia jak
działa reszta.

> Cały cyrk polega właśnie na umiejętności sprzedawania tego samego Burka -
> czyli używania tego co się raz zrobiło -  po wielokroć. Jeżeli potrafisz w
> kolejnym projekcie użyć 90% ze starego... to po prostu piszesz 10x szybciej
> i robisz 10x mniej błędów.
Właśnie ostatnio odnoszę wrażenie, że to jest możliwe gdy projekt jest
elastyczny a nie nadmiernie dopasowany. Brakuje mi właściwego słownictwa...
Generalnie straciłem wiarę w możliwość szybkiej poprawy starego kodu. I wolę
już na etapie projektu dobrze wydzielić to co będzie wywalone w całości i
nadpisywane od nowa.
Pozdrawiam


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

Użytkownik "Marszalkowski" <m...@t...pl> napisał w wiadomości grup
dyskusyjnych:5...@n...onet.pl
...
> Właśnie ostatnio odnoszę wrażenie, że to jest możliwe gdy projekt jest
> elastyczny a nie nadmiernie dopasowany. Brakuje mi właściwego
> słownictwa...

... magiczne słowa to "metodyki zwinne", czyli agile development .

do góry

slawek wrote:
>
> Użytkownik "Marszalkowski" <m...@t...pl> napisał w wiadomości grup
> dyskusyjnych:5...@n...onet.pl
...
>> Właśnie ostatnio odnoszę wrażenie, że to jest możliwe gdy projekt jest
>> elastyczny a nie nadmiernie dopasowany. Brakuje mi właściwego
>> słownictwa...
>
> ... magiczne słowa to "metodyki zwinne", czyli agile development .

Taaa. Agile sie nadaje tylko do malych projektow. Moooze od biedy do
srednich. Na pewno nie do duzych!

do góry