Stosowalność Scali w dużych projektach
Łukasz Kawalec
Rozważam czy wykorzystać Scale w dużym projekcie i potrzebuje Waszej
opinii. Zastanawiam jakie problemy mogą wyniknąć, jakie są wady, jakie
zalety.
Proszę o Wasze doświadczenia
Dzięki
Piotr Gęga
Problem ze znalezieniem ludzi do pracy (teraz lub w przyszlosci )?
--
pozdrawiam / best regards,
Piotr Gęga (pietia)
microblog: http://twitter.com/piotrgega
open source: http://www.github.com/pietia
linkedin: http://pl.linkedin.com/in/piotrgega
goldenline: http://www.goldenline.pl/piotr-gega
Przemyslaw Pokrywka
W BLStream wykorzystaliśmy Scalę w projekcie średniej wielkości.
Slajdy z mojego wystąpienia na ten temat na WrASSE można obejrzeć tutaj:
http://docs.google.com/fileview?id=0BzjGWKocIt-DZmUyZWY5MmQtNzI2My00Y2ZjLTljZWItNjgyY2MxYTIwODYz&hl=en
Użycie Scali u nas bardzo się opłaciło.
Pytanie o problemy, wady i zalety to temat rzeka i najlepiej rozeznać
się w tym we własnym zakresie po forach anglojęzycznych - najwięcej
doświadczeń ludzie zebrali chyba na razie poza granicami naszego
kraju.
Dodatkowo, bez urazy, pytanie o zalety Scali może świadczyć o
nienajwiększej obecnie wiedzy o tym języku. Jeśli tak jest, to
rozpoczynanie dużego przedsięwzięcia z jego użyciem niesie ze sobą
ryzyko. Wtedy lepszym wyjściem może być wypróbowanie Scali w
wydzielonym komponencie systemu (np. implementującym interfejsy
Javowe) albo użycie jej w testach jednostkowych.
Ja mogę odnieść się do popularnych wyobrażeń nt. Scali i zderzyć je z
rzeczywistością naszego projektu.
Zacznę od kwestii znalezienia ludzi do pracy:
- pokutuje przekonanie, że znaleźć takich jest trudno. Na rynku, w tej
chwili, owszem. Za to bardzo rozsądną opcją jest wyszkolenie własnych.
Moje doświadczenia wskazują na to, że dobrzy deweloperzy Javy
odnajdują się w Scali błyskawicznie. Jeśli ktoś płynnie porusza się we
wzorcach projektowych, dba nie tylko o to, aby działało, ale też o
jakość kodu, w Scali odnajduje najczęściej możliwości, których od
dawna brakowało mu w Javie, mimo że tego nie podejrzewał. W naszym
projekcie Scalę znały początkowo dwie osoby (ja i kolega, którego
zachęciłem do użycia Scali pół roku wcześniej). Kolega, który nie znał
jej kompletnie, a jest bardzo dobrym deweloperem zaczął być w pełni
produktywny po dwóch tygodniach i został fanem Scali.
Kwestię zespołu można więc sprowadzić do kwestii posiadania dobrych
deweloperów Javy plus pewnego czasu na poznanie języka.
Jeśli chodzi o trudność nauki, to przejścia z Javy na Scalę nie można
porównywać do przejścia z C++ na Javę np. albo z Javy na Ruby. Scala
buduje na Javie. Język jest owszem znacznie bogatszy, ale do
korzystania z niego wystarczy jedynie pewne minimum, które z czasem
można rozszerzać o nowo poznawane możliwości. Daje się w nim używać
wszystkich bibliotek Javy i tworzyć kod w sposób podobny jak w Javie,
więc przejście daje się bardzo rozkładać w czasie.
Jest w tej chwili już też sporo dostępnych książek i materiałów na jej
temat w sieci. W wielu wypadkach zapoznanie się z niektórymi
frameworkami Javy (jak np. Liferay) może stanowić większe wyzwanie,
niż nauka Scali.
Kwestia stylu kodowania - wielu nie mieści się w głowie, jak można
używać języka, w którym dozwolone jest "przeciążanie operatorów", co
oczywiście natychmiastowo ma wywołać w stylu kodowania kompletny chaos
(dokładniej, w Scali nie istnieje przeciążanie operatorów znane z C++
a jedynie nazwy metod mogą zawierać wiele znaków specjalnych, jak np.
znak plus). W zespole byłych programistów Javy o problemie takim można
zapomnieć. Każdy stosuje konwencje znane z Javy i jedynie przy
korzystaniu z nowych cech języka zespół dochodzi do porozumienia,
jakiej konwencji się trzyma. Jest już zresztą opublikowana przydatna
konwencja opracowana dla Scali przez Daniela Spiewaka, z której można
skorzystać.
Słaby tooling - to jest akurat kwestia aktualna teraz i
najprawdopodobniej jeszcze przez dłuższy czas. Obecne IDE mają wyraźne
słabsze wsparcie dla Scali, niż dla Javy. Nie ma też takiego bogatego
ekosystemu narzędzi jak dla Javy - szczególnie mam na myśli różne
statyczne analizatory kodu, generatory diagramów itp. - chyba że
operują na bajtkodzie, który jest ten sam.
Przestawiając się z Javy trzeba liczyć się z tym, że stracimy
możliwość wykonywania automatycznie niektórych refaktoryzacji (wiele
już jest napisanych dla Scali), być może będziemy musieli zmienić IDE
(my ze względu na beznadziejnie zabugowany plugin Scali w Eclipse
musieliśmy przestawić się na IntelliJ IDEA, darmową od jesieni 2009).
Pluginy są w ciągłym rozwoju, więc czasem będziemy potrzebowali
zajrzeć im w opcje, poczyścić cache itp. żeby obejść ich jakieś błędy.
Nasz zespół był doświadczony w walce z bugami rozmaitych wtyczek do
Eclipse'a w innych projektach, więc nie poddawaliśmy się i znaleźliśmy
rozwiązania wielu bolączek.
Mówiąc o narzędziach, trzeba też wspomnieć o tym, że niektóre funkcje
narzędzi Javy nie są już w Scali potrzebne, dlatego, że dużo ułatwia
sam język. Np. duże refaktoryzacje programów Scalowych często
przeprowadza się szybciej, niż analogicznych Javowych dzięki dużej
zwięzłości kodu w Scali i płynącej stąd zwiększonej czytelności. Mniej
czasu zajmuje zorientowanie się w kodzie i podjęcie decyzji, co należy
przerobić.
Tooling dla Scali pozostaje w tyle względem toolingu dla Javy, jednak
nasze doświadczenia wskazują na to, że zalety języka niwelują nieraz
niedostatki w narzędziach.
Napisz, jeśli miałbyś jakieś specyficzne pytania.
Pozdrawiam,
Przemek
JAZ
[...]
> Słaby tooling - to jest akurat kwestia aktualna teraz i
> najprawdopodobniej jeszcze przez dłuższy czas. Obecne IDE mają wyraźne
> słabsze wsparcie dla Scali, niż dla Javy. Nie ma też takiego bogatego
> ekosystemu narzędzi jak dla Javy - szczególnie mam na myśli różne
> statyczne analizatory kodu, generatory diagramów itp. - chyba że
> operują na bajtkodzie, który jest ten sam.
> Przestawiając się z Javy trzeba liczyć się z tym, że stracimy
> możliwość wykonywania automatycznie niektórych refaktoryzacji (wiele
> już jest napisanych dla Scali), być może będziemy musieli zmienić IDE
> (my ze względu na beznadziejnie zabugowany plugin Scali w Eclipse
> musieliśmy przestawić się na IntelliJ IDEA, darmową od jesieni 2009).
Darmowa wersja IntelliJ IDEA nie ma wsparcia do Scali. A wersja pełna
nie jest darmowa. Od jakiegoś czasu wsparcie Scali w Eclipse bardzo
się poprawiło i (z tego co ludzie mówią) jest nawet lepsze od
IntelliJ. Warto zauważyć, że przy każdej nowej edycji Scali zawsze
jest informacja o tym, że wyszedł też zaktualizowany plugin Scali dla
Eclipse. Wygląda na to, że Eclipse jest zalecanym IDE dla twórców
Scali. Jest nawet oddzielna strona poświęcona Eclipse i Scali o dosyć
znamiennej domenie: http://www.scala-ide.org/
Poza tym dobry post.
--
pozdr.
Jaroslaw Zabiello
Piotr Adamski
--
Pozdrawiam
Piotr Adamski
skype: piotr.adamski.
pkrol
Dość dobre wsparcie dla scali ma Netbeans szczególnie plug-in
http://sourceforge.net/projects/erlybird/ tylko dla wersji 6.9
Netbeansa
Łukasz Kawalec
Dziękuje za odpowiedź. Mam nadzieje, że użycie scali opłaci się
również w naszym projekcie. Nie mam narazie doświadczenia w
programowaniu w scali dlatego tak bardzo cenie sobie każda Waszą
opinie. Bardzo dobrym pomysłem wydaje mi się żeby na początku stosować
scalę tylko w jednym module, można będzie zdobyć doświadczenie, a
jednocześnie nie ryzykuje się tak bardzo w razie pojawianie się
trudności. Jeśli chodzi o IDE to jestem zawiedziony tym co piszecie o
pluginie do eclipsa i osobiście przestawiam się na IntelliJ IDEA.
Pozdrawiam
On 22 Lip, 01:35, Przemyslaw Pokrywka <przemyslaw.pokry...@gmail.com>
wrote:
>
> W BLStream wykorzystaliśmy Scalę w projekcie średniej wielkości.
>
>
>
> > 2010/7/21 Łukasz Kawalec <lukaszkawa...@gmail.com>: