MarcinC# napisał(a)
Żałosne to są komentarze co niektórych - widzę musicie się dowartościować kosztem innych, cóż...
patrzac po Twoich rozmowcach, wierz mi, ze nie musza.. moze nie wszystkie sa politycznie poprawne, ale tak to juz jest w internecie w czesci IT, ze objawy bezmozgowia zwykle sa natychmiast tepione. nie ma celu ocenianie ich.
MarcinC# napisał(a)
Macie swój punkt widzenia ale nie potraficie zrozumieć argumentów innych niż Wasze... Swoją drogą - zadałem w tym wątku KONKRETNE pytanie, a zamiast dostać konkretną odpowiedź - przerodził się on w dyskusję o "wielkości i nieomylności" jednych metod nad innymi. Skomentuję to krótko bo kończę ten temat - uważałem i będę uważał, że pisanie programów to nie tylko znajomość zaawansowanych elementów języka, ale też umiejętność kontaktów z ludźmi, określania ich potrzeb, rozumienie celu który chcą osiągnąć etc.
i dostales kilka konkretnych odpowiedzi. nie doczytales postow? co do dyskusji, patrz powyzej. Twoje podejscie zostalo uznane za niewlasciwe, stad reakcja. Nie dasz rady nikogo przekonac, ze Twoje podejscie jest ok --- poniewaz nad tymi sprawami myslalo juz wiele osob, takze zwacych sie naukowcami, socjologami, projectmanagerami, dyrektorami (..) i stworzylo cos, co zwie sie inzynieria oprogramowania, metodykami prowadzenia projektow, cyklami zycia projektow (..) slowem - teorie programowania, teorie informacji, oraz algorytmike. i szczerze mowiac, to co jak do tej pory napisales, w wiekszosci stoi z nimi w sprzecznosci. pytanie: myla sie setki ludzi przez dziesiatki (juz!) lat, czy jedna osoba ... ktora w dodatku widac ze nie zna jezyka ktorym sie posluguje. spojrz z tej strony, a moze zrozumiesz ostra reakcje forumowiczow - oni w znacznej czesci znaja i stosowali podejscie podobne do Twojego, oraz znaja i stosuja w/w teorie, i .... znaja wady/zalety obu.
MarcinC# napisał(a)
A sposób ich realizacji - mniej lub bardziej "elegancki" - jest drugorzędny tak długo, jak długo program spełnia swoją funkcjonalność w sposób zadowalający.
zgadza sie. to jest podstawowe prawo kazdej rzeczy ktora sie wykonuje. szkopul tkwi w slowie "zadowalajacy".. raz, ze musi spelniac wymagania uzytkownikow, dwa, ze musi, o dziwo, pozwalac Tobie na dalsza, sensowna prace nad nim. oczywiscie, mozna rzec, ze skoro zamawiajacy twierdzi ze masz pisac byle jak byle dzialalo i bylo tanio, ze nigdy nie bedziesz musial tego rozbudowywac ani poprawiac - to nie ma co sie szczypac i nie ma co tej drugiej kwestii brac pod uwage.. jest to jednak kopanie dolkow pod soba samym, klienci zazwyczaj szybko to odszczekuja i okazuje sie ze masz duzo jeszcze dodatkowych rzeczy do dodania. w tym momencie, jesli Twoj twor jest wiekszy niz kilkanascie klas (ew. paredziesiat funkcji) na krzyz, okazuje sie ze takie terminy jak 'elastycznosc', 'latwosc rozbudowy' czy 'koszt utrzymania kodu' okazuja sie niebanalne i Twoje 'praktyczne' podejscie przegrywa z 'teoriami'. um. wlasciewie.. nie przegrywa. w takim momencie, ono przychodzi zebrac do teorii po jakikolwiek ratunek. na Twoim miejscu radzilbym Ci potraktowac tutejsze ostre slowa jako ostrzezenia przed potencjalna katastrofa ktora sam sobie przygotowujesz..