• 18/11/2007 12:45
• 

• Git! 0

  Kit! 0

>Adept napisał
>>Ja nie istnieje (FURBY) napisał
>>a Google ze swoimi roziązaniami obsysa lame koda
>generują
>>tam strasznego.
>
>a Co się to obchodzi jaki kod jest generowany? Zwłaszcza
>że tam jest obfuscator włączony, który (z tego co
>pamiętam) można wyłaczyć.
>
>ten kod javascriptowy to coś ala Bytecode/binarka więc po
>co to ma być czytelne?
>
>moim zdaniem GWT to genialny wynalazek - i świetlana
>przyszłość przed nim jest.

Znam paru ludzi pracujaych z googlach i opowiadali mi jak sie tam koduje :)

• 18/11/2007 12:47
• 

• Git! 0

  Kit! 0

>Ja nie istnieje (FURBY) napisał
>no i jeszcze o NetBeans i Ruby.. mówisz ze niema IDE ale on
>bardzo dobrze wspiera Rubiego.. troche jeszcze wolno
>podpowiada bo powinien taj jak Intelisens w 1 ms :P no i do
>VS też są wtyczki integrujące Inteli Sens z rubym ale to
>juz niestety platne rozwiazanie. Ale testowalem i dziala
>zajebiaszczo

NIe nie - nie mówie ze nie ma - ale wsparcie to,w porównaniu do jezyków statycznych, jest po prostu marne. A z tego co słyszałem na prezentacji ruby to refactoringu w ogóle nie ma (bo przeciez język dynamiczny.)

• 18/11/2007 12:48
• 

• Git! 0

  Kit! 0

>Adept napisał
>>Ja nie istnieje (FURBY) napisał
>>pozatym IDE takie jak Eclipse czy WSAD czy NetBeans(ten
>>wspiera Rubiego) ma tak ogromne zaczenie tylko w modelu
>>wytwarzania oprogramowania na "harpagana" jesli masz
>dobrze
>>ułożony plan działania i podzielony program na sensowne
>>moduły/komponety to niema problemu z tym ze ci sie
>>skladania nie podpowiada bo i tak z góy wiadomo co i jak
>>bedzie ponieważ jest pewien plan który się wypełnia.
>
>chyba żartujesz... Albo po prostu nie pracujesz zawodowo
>tylko powtarzasz to co usłyszysz na wykładach.
>
>UML to praktycznie tylko teoria - w praktyce nie słyszałem
>zeby gdzies był używany. Klient ma to do siebie że lubi
>zmieniać wymagania - a przy tym zmienia się i kod.
>
>Nigdy nie wiadomo co będzie - tylko wiadomo co jest w danej
>chwili. a dalej jest już tylko refactoring.
>

no widzisz jak myslisz o tym ze klient moze zmieniac wymagania to robisz elastyczne rozwiazania.

Pozatym UML to nie jest praktycznie tylko teoria, bo wlasnie Duze projekty sie tak realizuje a nie z buta, :) Przykro mi , to że uczestniczyc w metodologii Zwinnej nie oznacza ze inne firmy nie stosują RUP , ja pracowalem rzy projekcie ktory mial po zliczeniu 243 k lini kodu :) i był to RUP. Acha... to sie liczy kod nie robiony od generatorow i bez komentow.

• 18/11/2007 12:49
• 

• Git! 0

  Kit! 0

>Adept napisał
>>Ja nie istnieje (FURBY) napisał
>>no i jeszcze o NetBeans i Ruby.. mówisz ze niema IDE ale
>on
>>bardzo dobrze wspiera Rubiego.. troche jeszcze wolno
>>podpowiada bo powinien taj jak Intelisens w 1 ms :P no i
>do
>>VS też są wtyczki integrujące Inteli Sens z rubym ale
>to
>>juz niestety platne rozwiazanie. Ale testowalem i dziala
>>zajebiaszczo
>
>NIe nie - nie mówie ze nie ma - ale wsparcie to,w
>porównaniu do jezyków statycznych, jest po prostu marne. A
>z tego co słyszałem na prezentacji ruby to refactoringu w
>ogóle nie ma (bo przeciez język dynamiczny.)
>
>

Pobaw sie NetBeansem 6.0 beta 2... i dopieor wtedy mów dalej :) z tego co widzialem są wszystkie ficzery Dzafofskie dostępne.. łądnie z zaawansownaym podpowiadaniem skladni etc.

• 18/11/2007 12:52
• 

• Git! 0

  Kit! 0

>Ja nie istnieje (FURBY) napisał

>Pozatym UML to nie jest praktycznie tylko teoria, bo wlasnie
>Duze projekty sie tak realizuje a nie z buta, :) Przykro mi
>, to że uczestniczyc w metodologii Zwinnej nie oznacza ze
>inne firmy nie stosują RUP , ja pracowalem rzy projekcie
>ktory mial po zliczeniu 243 k lini kodu :) i był to RUP.
>Acha... to sie liczy kod nie robiony od generatorow i bez
>komentow.

Nawet jeśli tak.. to jeśli chcesz mi wcisnąć kit że nie robiliście refactoringu przynajmniej kilka razy - to CI po prostu nie uwierze

>Ja nie istnieje (FURBY) napisał

>Pobaw sie NetBeansem 6.0 beta 2... i dopieor wtedy mów
>dalej :) z tego co widzialem są wszystkie ficzery
>Dzafofskie dostępne.. łądnie z zaawansownaym
>podpowiadaniem skladni etc.

wszystkie? jakim cudem? przecież możesz używać zmiennych bez ich deklarowania.. mozesz sobie do obiektów dodawać metodu... nie używałem tego NB ale pewne cechy jezyków dynamicznych zdają się wyeliminowywać refactoring.

• 18/11/2007 12:55
• 

• Git! 0

  Kit! 0

no jasne ze pojawiał sie refactoring pewnych rzeczy , ale zawsze były to akcje przemyslane. Wiadomym jest ze jak ktos napisze Bazówke to sie jej nazwy zmienic juz nieda :D pozniej ale można robic inne rzeczy.. generalnie po to sie stosuje Design Patterns zeby wyeliminowac potrzeby refaktoryzacji kodu :) ukrywa sie implementacje etc. z reszta jako programista Javy powinnes byc ostrym specem od Wzorców Projektowych :) wkoncu java to jeden wielki wzorzec :D

• 18/11/2007 12:59
• 

• Git! 0

  Kit! 0

mnie tam np najbardzije przydawala sie opcja akurat w VS jaką bylo "go to the definition" i to chyba najwazniejsze w kazdym ide :)

no a refactorign pod ruby w netbeans się juz rozwija od 2005 roku :)

• 18/11/2007 13:14
• 

• Git! 0

  Kit! 0

>Ja nie istnieje (FURBY) napisał
>no jasne ze pojawiał sie refactoring pewnych rzeczy , ale
>zawsze były to akcje przemyslane. Wiadomym jest ze jak ktos
>napisze Bazówke to sie jej nazwy zmienic juz nieda :D
>pozniej ale można robic inne rzeczy.. generalnie po to sie
>stosuje Design Patterns zeby wyeliminowac potrzeby
>refaktoryzacji kodu :) ukrywa sie implementacje etc. z
>reszta jako programista Javy powinnes byc ostrym specem od
>Wzorców Projektowych :) wkoncu java to jeden wielki wzorzec
>:D



Jakoś nie widze związku zastosowania wzorców z brakiem refactoringu. a Usuń wpis
Cytuj
Odpowiedz
jesli widze to bardzo nie wielki.

ale za speca dzięki; )

• 18/11/2007 13:19
• 

• Git! 0

  Kit! 0

jak nie widzisz zwiazku to lipa, po to sie stosuje wlasnie wzorce aby niwelowac potrzebe "wielkich zmian" np. fabryka abstrakcyjna... widzisz juz powiazanie ?

• 18/11/2007 13:31
• 

• Git! 0

  Kit! 0

Taki dosc spory refactor widzialem tylko jak SqlAlchemy przechodzilo z 0.3.0 -> 0.4.0 :) a tak to zawsze był bardzo drobne sprawy :)

• 22/11/2007 10:32
• 

• Git! 0

  Kit! 0

Tu jest lista obecnie dzialajacych algorytmow do automatycznego refactoringu w Ruby: http://r2.ifs.hsr.ch/trac/wiki/TheR...

• 19/12/2007 17:45
• 

• Git! 0

  Kit! 0

Glos w dyskusji Java vs. jezyki dynamiczne: http://steve-yegge.blogspot.com/200...
Polecam.

• 28/12/2007 23:53
• 

• Git! 0

  Kit! 0

Piszecie kkurcze tutaj o tym czy java jest dobra itp. a przecież tematem tego wątku nie jest; )
Jeśli chodzi o mnie, to tworzę właśnie grę. Coś co jest na kurniku - piłka. Projekt na zaliczenie; )

• 29/12/2007 04:08
• 

• Git! 0

  Kit! 0

:]
nareszcie coś na temat. Ja ciągle brnę przez Thinking in Java nie poddając się; ) jak skończysz to nie omieszkaj pokazać grę

• 29/12/2007 11:00
• 

• Git! 0

  Kit! 0

Też chciałem czytać TinJ ale dałem sobie spokój; )
Jak to powiedział kolega z pracy: Life is too short for java; )
Pokażę, pokażę; ). Jak będę miał problem z czymś to będę pytał.

• 31/12/2007 23:31
• 

• Git! 0

  Kit! 0

>Maciek Makowski napisał
>Glos w dyskusji Java vs. jezyki dynamiczne:
> http://steve-yegge.blogspot.com/200...
>Polecam.

Interesujący artykuł.

Jestem jeszcze mało doświadczonym programistą, największy projekt w jakim uczestniczyłem miał jakieś 30k linii kodu. :D

Ale czy to nie jest przypadkiem tak, że oszczędzając na ilości linii kodu i z pół miliona linii przechodząc na 150 tys. przy okazji program nie traci na czytelności na poziomie szczegółów?

Np. można znaleźć przykład prostego muda napisanego w ruby, który ma 15 linijek kodu:

http://redhanded.hobix.com/bits/mud...

Ale przyznam się, że nie rozumiem kodu.

Podejrzewam, że kurcząc 5 razy kod i zachowując przy tym czytelność kod raczej straci na czytelności.

No chyba, że był to kod robiony po części metodą kopiuj-wklej, zawiera powtórzenia. Ale tego można unikać korzystając z każdego języka programowania, w tym Java.

• 01/01/2008 15:30
• 

• Git! 0

  Kit! 0

> Ale czy to nie jest przypadkiem tak, że oszczędzając na ilości
> linii kodu i z pół miliona linii przechodząc na 150 tys. przy okazji
> program nie traci na czytelności na poziomie szczegółów?

Niekoniecznie. Tu nie chodzi o uprawianie hackerstwa, tylko o wykorzystanie idiomów dostępnych w jednych językach a niedostępnych w innych. Jeśli jest się przyzwyczajonym do takich własności języka jak otwarte klasy, domknięcia (closures) czy dynamiczne typowanie to kod wcale nie musi być mniej czytelny.

Od jakiegoś czasu trwa dyskusja na temat dodania domknięć do Javy. Przy tej okazji Joshua Bloch bodajże wygłosił opinię, że domknięcia nie pasują do charakteru tego języka, bo jest to "blue collar language" (w odróżnieniu od języków "akademickich") -- chodziło mu o to, że Java jest językiem do pracy, a nie do podziwiania jakie to sprytne tricki można w nim stosować. Dla mnie niestety to sformułowanie ma inną konotacje, mianowicie języka dla wyrobników, który specjalnie pozbawiony jest wyrafinowanych możliwości, żeby mniej rozgarnięci programiści i analitycy się nie pogubili.

Do postu Steve Y. wracając, wydaje mi się że głównym problemem jest nie tyle rozmiar samego kodu (zakładając, że rozmiar ten nie wziął sie z kopiowania i wklejania), ile skomplikowanie idei w tym kodzie zawartym. Jeśli prawidłowo zaprojektowany program w Javie ma setki tysięcy linii kodu, to ilość logiki w nim zawarta powoduje, że zorientowanie się w całości praktycznie nie jest możliwe -- w czym by ten program nie był napisany.

• 02/01/2008 05:33
• 

• Git! 0

  Kit! 0

Moim zdaniem problemem jest rozrost programu, który nie był od początku zaplanowany do bycia dużym i skomplikowanym.

Można tak zaplanować nawet bardzo duży program - dzieląc go na moduły, a te z kolei na podmoduły - by ogólna architektura nie była kosmicznie skomplikowana (w końcu system operacyjny taki jak Windows XP ma wiele milionów linii kodu, a mimo to programiści nad nim pracujący potrafią się połapać). Wtedy ogólna architektura modułów, ich funkconalności i wymiany danych między nimi będzie do objęcia umysłem. Z kolei zagłębiając się architektura podmodułów każdego z modułów też może być do objęcia umysłem. I tak dalej - kilka warstw abstrakcji - aż do poziomu klas - dzięki czemu by zrobić coś sensownego wystarczy przejrzeć parę diagramów i niewielki procent kodu.

Problemem jest raczej rozwój już istniejącej aplikacji.
Gdy taka aplikacja rośnie to:
1) Nie każdy na samym początku tak zaplanował aplikację, by ułatwić wzrost razem z zachowaniem łatwej do zarządzania struktury.
2) Podczas powiększania aplikacji o dodatkowe funkcje zazwyczaj bardziej patrzy się na czas (klient chce dodatkowej funkcjonalności na wczoraj albo z innego powodu mamy mało czasu) niż na to, by przemyśleć architekturę zmian. Jak zauważyłem ludzie więcej czasu poświęcają przemyśleniu architektury na etapie tworzenia pierwszej wersji niż przy dodawaniu dalszych kolejnych zmian.

Dlatego moim zdaniem ważne jest robienie od czasu do czasu przeglądu struktury i kodu programu i ewentualnie refaktoryzacji. Bo nie robiąc tego regularnie można przerobić aplikację na potworka, który już przy 15 tys. linii kodu będzie nie nadawał się do szybkiego orientowania się w nim (tak, zdarzyło mi się popełnić takiego potworka, którego potem musiałem mozolnie refaktoryzować, miałem okazję na na własnej skórze poznać, że myślenie o architekturze w trakcie rozwoju programu jest jednak ważne).

Podejrzewam, że Steva dopadło to, że aplikacja tworzona metodą dodawania niewielkich funkcjonalności urosła "wszerz" - zrobiło się bardzo dużo modułów na tym samym, że tak to nazwę, poziomie abstrakcji.

Ilość logiki może być problemem jeśli chcemy cały czas we wszystkich częściach być szczegółowo zorientowani.
Jeden programista wysiada, dla mnie zadziwiające jest, że Steve sam doszedł do 500 tys., dla mnie to ogromna ilość kodu.
Moim zdaniem jednak nie trzeba być cały czas dokładnie zorientowanym we wszystkich częściach kodu.
Jeśli mamy mapy o różnej szczegółowości mówiące co jest po co i gdzie (czyli dokumentację, diagramy), kod opisany komentarzami i odpowiednią strukturę to można coś sensownego zrobić nie obejmując cały czas całości logiki aplikacji umysłem.
Gorzej jak struktura jest kiepska i by coś dodać lub zmienić trzeba w 100 różnych miejscach wprowadzać zmiany porozrzucane po programie jak rodzynki w cieście - tak wygląda na przykład zabawa z jakimś większym modyfikowaniem OS-Commerce w php (a najlepszym sposobem by sobie popsuć architekturę i utrudnić życie jest metoda kopiuj-wklej kawałków kodu - zresztą chyba każdy programista szybko się tego uczy na własnej skórze).

• 02/01/2008 05:42
• 

• Git! 0

  Kit! 0

W sumie to tak się zastanawiam: czy jeśli przerobi się program, nie zmieniając znacznie jego struktury, ale dodając te dodatkowe właściwości języka, które nieco "kompresują" zapis, to czy program stanie się bardziej czytelny?
Mam na myśli czytelny w sensie:
- łatwego poruszania się po nim i wprowadzania zmian
- połapania się w strukturze programu

Z jednej strony mam trochę wątpliwości.
Ale z drugiej strony na przykład szybciej mi się i pisze i czyta (a więc i często stosuję) zapis "a ? b : c" zamiast tego z "if ... else ...". Więc może z tymi dodatkowymi możliwościami jest podobnie.