Temat: SOLIDny kod

@Darku, poruszyłeś ważny temat.
Twój przykład z FANN jest bardzo dobrym przykładem: biblioteka działa, ma się dobrze - i to jest jak najbardziej potwierdzeniem tezy, że struktura kodu ma się nijak do działania produktu końcowego. Ale weź coś w tym zmodyfikuj później - albo, co gorsza, znajdź błąd i go popraw. Właśnie po to jest potrzebna dobra organizacja kodu: żeby później dało się z nim sensownie (wydajnie/szybko/tanio) pracować. W momencie tworzenia systemu organizacja kodu nic nie wnosi, a nawet potrafi nieco spowolnić pracę. Ale później, po wdrożeniu, kiedy zaczynają się poprawki, modyfikacje itd itp - dobrze zorganizowany kod jest bezcenny.
Dlatego warto. Zawsze i wszędzie.

@Jarek - dokładnie o to chodzi :)
Sam wielokrotnie spotkałem się z takim podejściem: po co mam pisać porządnie, skoro moi koledzy w zespole piszą "na kolanie"? Jasne. Po co. Ale później takiego gościa nie wybiorę na senior programmera, albo na team leadera.
W zasadzie nic nie trzeba. Tylko później taki jeden z drugim się żali, że pracuje już 10-ty rok za 2500 i szans na awans zero.
Jakoś tak ludzie stracili umiejętność patrzenia do przodu i przewidywania konsekwencji swoich działań i prezentowanych postaw ;) No, ale z drugiej strony, jakby wszyscy byli zbyt dobrzy i awansowali to by nie było komu kodu pisać :) :) :) Potrzebni są i ludzie od łopaty, i murarze, i architekci :)

Temat: SOLIDny kod

Piotr G.:
Jakoś tak ludzie stracili umiejętność patrzenia do przodu i przewidywania konsekwencji swoich działań i prezentowanych postaw ;)

wyjaśnił mi to zgrabnie kolega: 'bo to ten outsourcing: rotujący programiści nie mają do czynienia z konsekwencjami własnej pracy ale chętnie narzekają na cudza...." ;)

Temat: SOLIDny kod

Jarosław Ż.:

Piotr G.:
Jakoś tak ludzie stracili umiejętność patrzenia do przodu i przewidywania konsekwencji swoich działań i prezentowanych postaw ;)

wyjaśnił mi to zgrabnie kolega: 'bo to ten outsourcing: rotujący programiści nie mają do czynienia z konsekwencjami własnej pracy ale chętnie narzekają na cudza...." ;)

Bingo.
To jest chyba najlepsze wytłumaczenie tego, dlaczego obecnie tworzony kod zwykle jest... marny.

Temat: SOLIDny kod

Piotr G.:

Jarosław Ż.:

Piotr G.:
Jakoś tak ludzie stracili umiejętność patrzenia do przodu i przewidywania konsekwencji swoich działań i prezentowanych postaw ;)

wyjaśnił mi to zgrabnie kolega: 'bo to ten outsourcing: rotujący programiści nie mają do czynienia z konsekwencjami własnej pracy ale chętnie narzekają na cudza...." ;)

Bingo.
To jest chyba najlepsze wytłumaczenie tego, dlaczego obecnie tworzony kod zwykle jest... marny.

Oczywiście można narzekać na programistów, ale myślę że sedno problemu tkwi w nieudolności osób które organizują cały -proceder- tworzenia softu. "To nie ja, to programista którego zatrudniłem / zarekomendowałem ... "

Temat: SOLIDny kod

No wiesz, Jakub, jak by nie patrzeć to programiści dokonują wyboru, czy napiszą coś z małej litery, czy z dużej, albo czy zrobią wcięcie, czy też nie, albo czy zaimplementują coś tak czy inaczej. Nie zrzucajmy wszystkiego na management, "na dole" wszystko da się spieprzyć i będzie to jedynie wina tego, który spieprzył...
Oczywiście, można tu wrócić do ostro dyskutowanego (przeze mnie również) tematu dotyczącego zasad nazewnictwa, dobrych praktyk itp pojęć, które powinny funkcjonować w organizacji - i ustalenie takich reguł jest oczywiście rolą managementu.
Ale, bądźmy uczciwi - jeśli ktoś będzie chciał mieć to w dupie, to będzie miał i w wielu przypadkach to się nie wyda od razu. Wyda się później, kiedy ktoś inny, kto będzie musiał wprowadzić jakąś zmianę czy poprawkę, porzyga się na widok masakrycznego kodu i poświęci swój własny czas na jego refaktoryzację do znośnej postaci.
Ja już to pisałem wcześniej kiedyś: to nie ma nic wspólnego z organizacją pracy - jeśli ktoś jest fleja, żadne "dobrowolne" reguły nie pomogą, i trzeba albo go wywalić od razu, albo tyle razy dawać po premii, aż się nauczy. I to jest jedyna rola managementu w takiej sytuacji. Ewidentnie wychowawcza. Ludzi trzeba uczyć odpowiedzialności za to, co robią.

Temat: SOLIDny kod

Jarosław Ż.:
Wracając do przykładu XML, całą wiedzę o XML (składnia itp...) wrzucił bym do jednej klasy z kilkoma operacjami (analogicznie jak we jednej klasie trzymam motor tworzenia plików PDF). Tu niestety pojawia się problem (o ile wiem) z wieloma frameworkami, które "nie trzymają się SOLID" ... i pewnie dlatego wielu programistów modyfikuje je a nie raz tworzy własne....

JAVA ma gotowe klasy do obsługi XML, w tym parser. Skoro jednak masz już swój walidator, który jak sądzę działa w oparciu o określone przecież algorytmy (bo składnia poprawnego XML jest ściśle określona), to zastanów się tylko ile przypadków braku poprawności taki walidator jest w stanie sprawdzić?

Mechanizm zgłaszania wyjątków i obsługa (sterowanie) w postaci try-catch jest czymś w rodzaju bezpiecznika. Try-catch pozwala aplikacji dalej funkcjonować, inaczej po prostu zostanie zatrzymana. Prawda jest jednak taka, że nie da się uchronić przed kretynizmem a pisanie programów idiotoodpornych to nie taka prosta sprawa. Zgłoszenie wyjątku parsowania w przypadku standardowych (dostępnych już w JAVA) klas do XML jest najprostszym sposobem na zabezpieczenie aplikacji (uniemożliwienie dalszych działań na nieprawidłowych danych), bo wszystko sprowadza się w zasadzie do powiadomienia użytkownika, że plik jest nieprawidłowy i uniemożliwienie mu dalszych działań na nieprawidłowych danych.

Eclipse jest na tyle profesjonalnym narzędziem, że już w trakcie pisania kodu wyświetla czerwono-żółte ikonki, więc wykrywa możliwość zgłoszenia przez metodę określonego wyjątku. Co więcej, nawet nie pozwoli skompilować, dopóki nie wyeliminuję tych żółto-czerwonych ikonek. Dopuszczalne są tylko żółte (warnings). Czy napisany wg. pewnych zasad walidator jest w stanie przed wszystkim uchronić?Ten post został edytowany przez Autora dnia 05.05.14 o godzinie 07:21

Temat: SOLIDny kod

Piotr G.:
@Darku, poruszyłeś ważny temat.
Twój przykład z FANN jest bardzo dobrym przykładem: biblioteka działa, ma się dobrze - i to jest jak najbardziej potwierdzeniem tezy, że struktura kodu ma się nijak do działania produktu końcowego. Ale weź coś w tym zmodyfikuj później - albo, co gorsza, znajdź błąd i go popraw.

FANN jest napisana w C, więc proceduralno-strukturalnie, wynikowym plikiem jest fannfloat.dll albo fanndouble.dll, dostęp do nich jest w przypadku JAVA przez JNA, w C# jest wrapper dla .NET a to wszystko i tak korzysta w oparciu o procedury z fannfloat.dll czy fanndouble.dll.

Pewnie że mogą być błędy, tylko że w tym przypadku trzeba by w najgorszym przypadku wnikać w kod FANN w C a przecież alternatywnie można stworzyć wielowarstwową MLP w oparciu o SOLID i podział na warstwy.

Właśnie po to jest potrzebna dobra organizacja kodu: żeby później dało się z nim sensownie (wydajnie/szybko/tanio) pracować. W momencie tworzenia systemu organizacja kodu nic nie wnosi, a nawet potrafi nieco spowolnić pracę. Ale później, po wdrożeniu, kiedy zaczynają się poprawki, modyfikacje itd itp - dobrze zorganizowany kod jest bezcenny.

No tak tylko że jest pytanie: w ilu firmach przychodząc do niej mam gwarancję, że kod jest w 100% oparty o SOLID, MVC/MVP, jest nazewnictwo w 100% po angielsku a nie pomieszanie z polskimi nazwami? Obstawiam że w praktyce w wielu z nich, jak miałbym do poprawy błędy, jeśli kod nie jest oparty o w/w zasady, byłby niemal w całości do refaktoryzacji.

W moim przykładzie sprawa rozbija się o zastosowanie walidatora XML, w przypadku gdy alternatywnie bez tego można użyć obsługi wyjątku w kodzie prezentera aplikacji na androida celem wyświetlenia odpowiedniego komunikatu i uniemożliwienia dalszych działań, ewentualnie skasowania nieprawidłowego pliku. A i jeszcze na ile jest prawdopodobne, że XML zostanie zmieniony, jeśli zostanie zapisany w wewnętrznej pamięci, gdzie z poziomu menedżera plików nie ma nawet dostępu?

Nie chodzi mi o perspektywy rozbudowy tylko o uzasadnienie zastosowania parsera o w/w przypadkach.

Temat: SOLIDny kod

Jakub W.:

Bingo.
To jest chyba najlepsze wytłumaczenie tego, dlaczego obecnie tworzony kod zwykle jest... marny.

Oczywiście można narzekać na programistów, ale myślę że sedno problemu tkwi w nieudolności osób które organizują cały -proceder- tworzenia softu. "To nie ja, to programista którego zatrudniłem / zarekomendowałem ... "

Jest w tym wiele racji, idąc tym tropem szybko dojdziemy do tego, że projekty programistyczne są kontraktowane na cenę wytworzenia, a nie na kontrakt obejmujący cały cykl życia produktu: projekty "dla kogoś" to ciśnienie na koszty i nie raz metoda spalonej ziemi. W przetargach publicznych jest gorzej bo jest to metoda na "wysokie koszty" ale tu ten koszt to marża wykonawcy a nie jakość... W Polsce mamy najwyższe marże na projektach IT w Europie albo i na świecie, potrafią przekroczyć 50%, gdzie średnia w europie to ok. 25-30%.

Powoli się to normuje bo rośna naciski na projekty fixed-price (czego jestem gorącym orędownikiem).

Temat: SOLIDny kod

Piotr G.:
No wiesz, Jakub, jak by nie patrzeć to programiści dokonują wyboru, czy napiszą coś z małej litery, czy z dużej, albo czy zrobią wcięcie, czy też nie, albo czy zaimplementują coś tak czy inaczej. Nie zrzucajmy wszystkiego na management, "na dole" wszystko da się spieprzyć i będzie to jedynie wina tego, który spieprzył...

Piotrze, niestety życie uczy, że pracownik (członek zespołu) nienadzorowany raczej zepsuje niż naprawi, mitologizowanie jakoby programiści to jakaś inna nacja niż np. urzędnicy, lekarze czy kierowcy nie ma pokrycia w rzeczywistości... Tu z Jakubem się zgadzam: projekt ma mieć PMa, architekta i projektanta i wykonawców.

Temat: SOLIDny kod

Dariusz R.:
JAVA ma gotowe klasy do obsługi XML, w tym parser.

JAVA ma

Mechanizm zgłaszania wyjątków i obsługa (sterowanie) w postaci try-catch jest czymś w rodzaju bezpiecznika. Try-catch pozwala aplikacji dalej funkcjonować, inaczej po prostu zostanie zatrzymana.

prawda

Prawda jest jednak taka, że nie da się uchronić przed kretynizmem a pisanie programów idiotoodpornych to nie taka prosta sprawa.

prawda :)

Czy napisany wg. pewnych zasad walidator jest w stanie przed wszystkim uchronić?

To zależy od podejścia. Moim zdaniem to troszkę jak z samochodem (przypomnę, że to kilkanaście tysięcy detali): na konsoli masz kilka żółtych i czerwonych lampek, to te na które jest w stanie zareagować kierowca (np. dolać olej czy paliwo), potem masz "zatrzymanie działania w wyniku złej eksploatacji" (ale to zatrzymanie nie niszczy samochodu). Reszta to serwis (w tym narzędzia diagnostyczne). Ja osobiście podchodzę do tego tak, że aplikacja nie powinna wyrządzać szkód. Owszem, metoda obsługi błędów to zawsze będzie kompromis, ale moim zdaniem błędy także należy dzielić na dziedzinowe i "techniczne". Zły podatek VAT to błąd dziedzinowy, brak pliku do importu to błąd techniczny, ale zły format XML to błąd tego (aplikacji) która go dostarczyła. Dlatego np. w webserwisach jako "biorca pliku" raczej tylko sprawdzam i odrzucam błędne bez wnikania jaki to błąd, o to niech się martwi nadawca (stosują zasada zaufanego źródła danych).Ten post został edytowany przez Autora dnia 05.05.14 o godzinie 08:45

Temat: SOLIDny kod

Piotr G.:
Oczywiście, można tu wrócić do ostro dyskutowanego (przeze mnie również) tematu dotyczącego zasad nazewnictwa, dobrych praktyk itp pojęć, które powinny funkcjonować w organizacji - i ustalenie takich reguł jest oczywiście rolą managementu.
Ale, bądźmy uczciwi - jeśli ktoś będzie chciał mieć to w dupie, to będzie miał i w wielu przypadkach to się nie wyda od razu.

W takim razie należy tak poukładać tworzenie softu, żeby ew. "spieprzenie" było automatycznie wyłapywane i wzracane do poprawy.

Jeśli programista ma w dupie ustalone zasady i nikt mu z tego powodu nie robi problemów to świadczy to tylko i wyłacznie o złej organizacji.

I właściwie ilu jest takich programistów, którzy świadomie i z premedytacją łamią ustalone reguły dot. jakości kodu ?
Ja jeszcze takiego nie spotkałem, a programy tworzone tak jak maszyny rube goldberga to właściwie standard.

Dlatego właśnie uważam, że problem leży nie po stronie programistów (czasem tacy "pracowici" potrafią narobić więcej bałaganu niż Ci którzy "olewają" *) a managementu który tą pracę im organizuje (a najczęściej nie organizuje, bo zespoły "organizują się same") i kontroluje (strzela batem w momencie kiedy na produkcji robi się czerwono).

Oczywiście nie uważam, że każdy management jest dysfunkcyjny.

Ja już to pisałem wcześniej kiedyś: to nie ma nic wspólnego z organizacją pracy - jeśli ktoś jest fleja, żadne "dobrowolne" reguły nie pomogą, i trzeba albo go wywalić od razu, albo tyle razy dawać po premii, aż się nauczy. I to jest jedyna rola managementu w takiej sytuacji. Ewidentnie wychowawcza. Ludzi trzeba uczyć odpowiedzialności za to, co robią.

Oj tam, trzeba ustalic reguły tworzenia kodu a następnie konsekwentnie egzekwować ich stosowanie. W sytuacji kiedy dana osoba jest na te zasady odporna to ... wiadomo.

Ok, kończę bo nie jestem pewnien na jaki temat rozmawiamy ;)

*

// 

// Dear maintainer:

// 

// Once you are done trying to 'optimize' this routine,

// and have realized what a terrible mistake that was,

// please increment the following counter as a warning

// to the next guy:

// 

// total_hours_wasted_here = 42

// 

:)Ten post został edytowany przez Autora dnia 05.05.14 o godzinie 13:40

Temat: SOLIDny kod

Jakub W.:
Oj tam, trzeba ustalic reguły tworzenia kodu a następnie konsekwentnie egzekwować ich stosowanie. W sytuacji kiedy dana osoba jest na te zasady odporna to ... wiadomo.

aaaa. to teraz już wiem po co są te przeglądy kodu :)

Temat: SOLIDny kod

Nie no, Panowie, to nie tak. To nie jest przedszkole, gdzie Pani jest odpowiedzialna za każde dziecko w każdej chwili. Albo pastwisko, gdzie pastuszek odpowiada za wszystkie krowy. To nie może być tak, że pracownik nie pilnowany ma prawo pracować źle - w ten sposób dojdziemy do sytuacji, kiedy na jednego pracownika będzie potrzebny jeden pilnowacz, a ponieważ pilnowacz też jest pracownikiem, to na każdego pilnowacza będzie potrzebny jeden super pilnowacz itd... To jakiś absurd. Człowiek, jako istota inteligentna, jest ZAWSZE odpowiedzialny za to, co robi, a zrzucanie odpowiedzialności na przełożonego czy na organizację jest po prostu dziecinadą.

Temat: SOLIDny kod

Piotrze, to nie tak, to jak kanar w tramwaju: wierzymy, że ludzie są dobrzy i sumienni ale od czasu dl czasu utwierdzamy się w tym przekonaniu ;) (w wojsku jest zasada: ścisła kontrola podstawa zaufania).

A tak poważnie: jako usługodawca jestem regularnie sprawdzany bo czym innym jest "proces odbioru z możliwością zgłaszania uwag do dzieła" ? Ja nie mam z tym żadnego problemu: w dowolnym momencie klient może zażądać aktualnego stanu wiedzy o tym co robię (status projektu). Ja nawet jestem w pewnym sensie ekshibicjonistą: udostępniam klientom narzędzie do monitorowania on-line pracy nad analizą i projektem, może zgłosić uwagi w dowolnym momencie. W zasadzie tak zwane oddanie produktu dla moich klientów to kosmetyka bo i tak zna każdy diagram i akapit tekstu jak tylko go napisze...

Owszem, dla mojego klienta, nie zawsze ma sens gapienie się na wszystkie moje produkty (modele procesów tak, modele UML już nie koniecznie) ale mogę w dowolnym momencie udostępnić to co robię komuś z zewnątrz w celach kontroli (i niektórzy to robią).... i nie obrażam się bo to nie jest brak zaufania a zarządzanie ryzykiem projektu z ich strony (tak jak mnie potem zatrudniają do nadzoru nad wykonawcą).

Temat: SOLIDny kod

Piotr G.:
Nie no, Panowie, to nie tak. To nie jest przedszkole

Coraz częściej mam wątpliwości (proszę absolutnie nie brać tego do siebie)

>, gdzie Pani

jest odpowiedzialna za każde dziecko w każdej chwili. Albo pastwisko, gdzie pastuszek odpowiada za wszystkie krowy. To nie może być tak, że pracownik nie pilnowany ma prawo pracować źle -

Czy znasz człowieka który chce robić coś "źle" ?
Z resztą - tu nie chodzi o to, żeby robić "źle" albo "dobrze", ale o to, żeby dana osoba robiła to, czego się od niej oczekuje. Czy na prawdę to jest takie skomplikowane ?

w ten sposób dojdziemy do sytuacji, kiedy na jednego pracownika będzie potrzebny jeden pilnowacz, a ponieważ pilnowacz też jest pracownikiem, to na każdego pilnowacza będzie potrzebny jeden super pilnowacz itd... To jakiś absurd.

Zgadzam się. To jest absurdalne myślenie.
nie chodzi o "ideał" a o "coś co działa (niekoniecznie idealnie)".

Człowiek, jako istota inteligentna, jest ZAWSZE odpowiedzialny za to, co robi, a zrzucanie odpowiedzialności na przełożonego czy na organizację jest po prostu dziecinadą.

To za co ten przełożony odpowiada, jeśli nie za efekt pracy zespołu ?
Nawet przedszkolanka za coś odpowiada...Ten post został edytowany przez Autora dnia 05.05.14 o godzinie 20:25

Temat: SOLIDny kod

Sebastian M.:
Prawie dwa lata temu zakończyłem serię o tym jak programować obiektowo,

Cześć,

Czy to jak widziałeś programowanie obiektowe dwa lata temu nadal się sprawdza czy jednak rozwój technologii, różnych koncepcji programowania czy też ogólnie pojętej wiedzy jakoś wpłynął na twoje postrzeganie w tym temacie?

pzdr

Temat: SOLIDny kod

Paweł W.:
Czy to jak widziałeś programowanie obiektowe dwa lata temu nadal się sprawdza czy jednak rozwój technologii, różnych koncepcji programowania czy też ogólnie pojętej wiedzy jakoś wpłynął na twoje postrzeganie w tym temacie?

Z pewnością. Zaczynałbym się poważnie martwić, gdyby było inaczej :) Tak naprawdę nawet pojedyncza dyskusja może sporo wnieść do postrzegania pewnych aspektów i rozwiązań.

Nigdy się nie zastanawiałem nad tym, co się zmieniło, ale wydaje mi się, że z biegiem czasu więcej decyzji jest podejmowanych nie intuicyjnie, a z pełną (na pewno z większą) świadomością i rozumieniem. Z drugiej strony, każde nowo poznane rozwiązanie, każda koncepcja, nawet gdy jest sprzeczna z naszą własną opinią, wnosi coś, poszerza "pole widzenia", dostegasz więcej implikacji poszczególnych decyzji.

Z resztą, już niedługo będę w stanie dokładniej w tej kwestii się wypowiedzieć i zweryfikować jak duże są to zmiany, bo będę miał okazję jeszcze raz wrócić do tej pierwszej serii :) Mam nadzieję, że się nie przerażę :P

Pozdrawiam :)Ten post został edytowany przez Autora dnia 06.05.14 o godzinie 13:15

Temat: SOLIDny kod

Paweł W.:

Sebastian M.:
Prawie dwa lata temu zakończyłem serię o tym jak programować obiektowo,

Cześć,

Czy to jak widziałeś programowanie obiektowe dwa lata temu nadal się sprawdza czy jednak rozwój technologii, różnych koncepcji programowania czy też ogólnie pojętej wiedzy jakoś wpłynął na twoje postrzeganie w tym temacie?

pzdr

Pytanie nie do mnie. Ale pozwole sobie wtrącić swoje trzy grosze.
Co się przez ostatnie dwa lata zmieniło – szturm programowanie funkcjoinalnego.

Kompletnie nowy poziom abstracji, i realizacja tego, co programowanie obiektowe obiecywało.

Java jest tutaj trochę w lesie, ale już javowy groovy jest daleko, dot.netowy C# też jest bardzo mocny, a F# jeszcze mocniejszy. Jakoś właśnie dwa lata temu zacząłem pisać funkcjonalnie w goovy i mój kod skórczył się o połowe. Poprawiałem ostatnio stary (nie mój) kod w C# i z 40 linijek robiły się trzy :-)Ten post został edytowany przez Autora dnia 28.05.14 o godzinie 22:26