Ciekawe studium przypadku dotyczące skalowania projektów wykorzystujących dynamiczny i zinterpretowany język można znaleźć w Beginning Scala autorstwa Davida Pollaka.
Zacząłem szukać sposobu na wyrażenie kodu w moim mózgu w prostszy, bardziej bezpośredni sposób. Znalazłem Ruby i Rails. Czułam się wyzwolona. Ruby pozwoliła mi wyrazić koncepcje w znacznie mniejszej liczbie wierszy kodu. Railsy były o wiele łatwiejsze w użyciu niż Spring MVC, Hibernate i inne „usprawnione” frameworki Java. Dzięki Ruby and Rails mogłem wyrazić znacznie więcej tego, co było w mojej głowie w krótszym czasie. To było podobne do wyzwolenia, które odczułem, kiedy przeniosłem się z C ++ na Javę ...
Gdy moje projekty Ruby i Rails wykroczyły poza kilka tysięcy wierszy kodu i gdy dodałem członków zespołu do moich projektów, wyzwania związane z dynamicznymi językami stały się oczywiste.
Spędziliśmy ponad połowę czasu na pisanie testów, a znaczna część wydajności, którą zauważyliśmy, została utracona podczas pisania testów . Większość testów byłaby niepotrzebna w Javie, ponieważ większość z nich miała na celu upewnienie się, że zaktualizowaliśmy program wywołujący, gdy zmieniliśmy kod, zmieniając nazwy metod lub liczby parametrów. Odkryłem również, że praca w zespołach, w których dochodziło do połączenia umysłu między dwoma do czterech członków zespołu, w Ruby wszystko poszło dobrze, ale kiedy próbowaliśmy przyciągnąć nowych członków do zespołu, połączenia mentalne były trudne do przekazania nowym członkom zespołu .
Poszukałem nowego języka i środowiska programistycznego. Szukałem języka, który byłby tak wyrazisty jak Ruby, ale równie bezpieczny i wydajny jak Java ...
Jak widać, głównym wyzwaniem dla autora w skalowaniu projektu było opracowanie testów i transfer wiedzy.
W szczególności autor omawia różnice w pisaniu testowym między językami o typie dynamicznym i statycznym w rozdziale 7. W sekcji „Poignently Killing Bunnies: Dwemthy's Stairs” autor omawia port Scali konkretnego przykładu Ruby:
Dlaczego Lucky Stiff ... wprowadza niektóre koncepcje metaprogramowania Ruby w Dwemthy's Array, w której królik walczy z szeregiem stworzeń. N8han14 zaktualizował przykład do pracy w Scali ...
W porównaniu z kodem Ruby części biblioteki Scala były bardziej złożone. Musieliśmy wykonać wiele pracy, aby upewnić się, że nasze typy są prawidłowe. Musieliśmy ręcznie przepisać właściwości Creature w klasach DupMonster i CreatureCons. To więcej pracy niż method_missing. Musieliśmy również wykonać sporo pracy, aby wesprzeć niezmienność naszych stworzeń i broni.
Z drugiej strony wynik był znacznie potężniejszy niż wersja Ruby. Gdybyśmy musieli napisać testy dla naszego kodu Ruby, aby przetestować to, czego zapewnia nas kompilator Scala, potrzebowalibyśmy o wiele więcej linii kodu. Na przykład możemy być pewni, że nasz Królik nie mógł władać siekierą. Aby uzyskać tę pewność w Ruby, musielibyśmy napisać test, który zapewni, że wywołanie |^Królika nie powiedzie się. Nasza wersja Scala zapewnia, że tylko Broń zdefiniowana dla danego Stworzenia może być używana przez to Stworzenie, co wymagałoby dużo refleksji w środowisku uruchomieniowym w Rubim ...
Czytanie powyżej może sprawić, że w miarę powiększania się projektów pisanie testowe może stać się zbyt kłopotliwe. Takie rozumowanie byłoby błędne, o czym świadczą przykłady udanych bardzo dużych projektów wspomnianych w tym samym pytaniu („Python jest z powodzeniem wykorzystywany do ... YouTube”).
Rzecz w tym, że skalowanie projektów nie jest tak naprawdę proste. Bardzo duże, długowieczne projekty mogą „pozwolić sobie” na inny proces opracowywania testów, z zestawami testowymi jakości produkcyjnej, profesjonalnymi zespołami testerów i innymi ciężkimi materiałami.
Zestawy testów YouTube czy Kit Java Compatibility pewien żyć innym życiem niż testy w małym projekcie samouczek jak Array Dwemthy użytkownika .