Czy dynamiczne języki mają niekorzystny wpływ na sprawny rozwój?

12

Z tego, co przeczytałem, zwinne programowanie często wymaga refaktoryzacji lub inżynierii wstecznej kodu do diagramów. Oczywiście jest o wiele więcej, ale jeśli weźmiemy pod uwagę praktyki oparte na tych dwóch metodach, czy dynamiczne pisanie języków jest niekorzystne?

Wydaje się, że języki o statycznym typie znacznie ułatwiłyby refaktoryzację i inżynierię wsteczną.

Czy refaktoryzacja lub (zautomatyzowana) inżynieria wsteczna jest trudna, jeśli nie niemożliwa w dynamicznie pisanych językach? Co projekty realnego świata mówią o używaniu dynamicznie typowanych języków do metodologii zwinnej?

agile dynamic-typing static-typing

— Gerenuk
źródło

5

Czy przekształcić kod inżynierii w diagramy? Dlaczego miałbyś to robić w Agile?

— CaffGeek

7

Zwinne nie oznacza „najpierw kod, później dokument”.

— Gort the Robot

@CaffGeek: Niektóre często polecane książki sugerują rysowanie diagramów na tablicy, a następnie kodowanie, a na koniec odwracanie kodu inżynierskiego do diagramów na następne spotkanie.

— Gerenuk

1

Uważam, że należy mocno wpisywać słowa z tagów i tekstu tego pytania. Wydaje się, że chodzi o statyczne vs dynamiczne, a nie silne i słabe.

— Winston Ewert

@WinstonEwert - Dobra rozmowa, zmieniłem tagi na dynamic-typingistatic-typing

— Carson63000,

11

Języki dynamiczne są teoretycznie w niekorzystnej sytuacji, wszystkie pozostałe są równe, ponieważ określają mniej o tym, jak działa kod (jakie są ograniczenia), a zatem mniej refaktoryzacji można wykonać automatycznie, a pojawiających się problemów nie można również automatycznie wykryć .

Ale wszystko inne nie jest równe. Najpopularniejsze języki dynamiczne pozwalają na uzyskanie bardzo zwartego, ale zrozumiałego kodu, co ogólnie przyspiesza ich rozwój i sprawia, że logika (która może ulec zmianie w refaktoryzacji) jest łatwiejsza do zauważenia wizualnie. Więc chociaż możesz stracić względną przewagę w pracy w dynamicznym języku, nadal możesz wyjść na przód, szczególnie jeśli i tak planujesz ręczne refaktoryzowanie.

Z drugiej strony istnieją języki o typie statycznym z zasadniczo tymi samymi zaletami co języki dynamiczne (tj. Kompaktowe i zrozumiałe - z typami w większości wywnioskowanymi, ale bardzo tam): Haskell jest być może wiodącym przykładem, ale OCaML / F #, Scala, i inne również należą do tej kategorii. Niestety, ponieważ są rzadziej używane niż najpopularniejsze języki o typie statycznym, nie mają dla nich tak szerokiego zestawu narzędzi (np. Do refaktoryzacji).

Podsumowując, myślę, że odpowiednio dostosujesz się do zwinnych metodologii w większości języków; Nie powiedziałbym, że jest teraz wyraźny zwycięzca, ponieważ praktyka jeszcze nie dogoniła teorii.

— Rex Kerr
źródło

Myślę, że ta odpowiedź najlepiej odnosi się do kluczowych punktów pytania :) Czy mógłbyś również wyjaśnić znaczenie bezpiecznego refaktoryzacji i inżynierii wstecznej dla zwinnego rozwoju? Zakładałem, że odegrał bardzo ważną rolę? Może to mniej, niż myślałem, a narzędzia do dynamiki języka są wystarczająco dobre.

— Gerenuk

1

@Gerenuk - Nie mam wystarczającego doświadczenia z zwinnym rozwojem (szczególnie w dynamicznych językach), aby udzielić wiarygodnej odpowiedzi - czy aspekt refaktoryzacji jest odciśnięty, pozostawiony taki sam itp.? Należy pamiętać, że inne typowe aspekty tego procesu - na przykład rozwój oparty na testach - mogą pomóc w określeniu, gdzie przebiegło refaktoryzacja, i jeśli włożysz nieco więcej wysiłku w, powiedzmy, fazę projektowania, możesz nie potrzebować refaktoryzować tyle. Nie sądzę, że jedna konkretna technika jest kluczem - ma pod ręką pełny zestaw narzędzi, często wdrażanych i współpracujących.

— Rex Kerr

14

Zautomatyzowane refaktoryzowanie zostało wynalezione w języku Smalltalk, dynamicznie pisanym języku. Więc nie, nie jest niemożliwe automatyczne refaktoryzowanie w dynamicznie pisanym języku. To, jak trudne jest, zależy znacznie bardziej od innych czynników oprócz dyscypliny pisania. Zarówno C ++, jak i Java są typami statycznymi, ale narzędzia refaktoryzacji naprawdę istnieją tylko dla Javy. Smalltalk dzięki introspekcji i prostej składni był naprawdę dobrym kandydatem do narzędzi refaktoryzacyjnych.

W pewnym sensie dynamiczne pisanie ułatwia refaktoryzację. Jeśli masz dobry pakiet testowy, możesz być pewien, że twoje refaktoryzacje niczego nie zepsuły. Dynamicznie wpisywana baza kodu jest zazwyczaj mniejsza. Ponadto refaktoryzacje mają zwykle wpływ na mniej kodu. W sumie wysiłek włożony w ręczne refaktoryzowanie dynamicznej bazy kodu jest mniejszy niż w przypadku statycznej podstawy kodu.

— Winston Ewert
źródło

1

A co z inżynierią odwrotną? Czy Smalltalk różni się od Pythona pod względem pisania? Trudno jest wydedukować wszystkie typy w Pythonie, a tym samym ustalić, która metoda jest naprawdę identyczna, a nie tylko ta sama nazwa.

— Gerenuk

2

Smalltalk nie różni się tak bardzo od Pythona pod względem pisania. Jest to jednak znacznie różnią się w odniesieniu do oprzyrządowania . Narzędzia i środowiska IDE dostępne dla Smalltalk są znacznie lepsze niż narzędzia dostępne dla Pythona, a nawet C #, C ++ i Java. Powodem, dla którego IDE dla Pythona są złe, nie jest to, że Python jest dynamicznie typowany, to dlatego, że IDE dla Pythona są złe. Nie zapominajmy, że IDE, które znamy teraz jako Eclipse, kiedyś nazywało się VisualAge dla Smalltalk. Społeczność Smalltalk ma 40 lat doświadczenia w tworzeniu IDE i stosuje to w Javie.

— Jörg W Mittag

@Gerenuk, pisanie Smalltalk nie różni się niczym od Pythona. Na inne sposoby, takie jak introspekcja, Smalltalk zapewnia zestaw funkcji bardziej przyjazny dla refaktoryzacji. Wnioskowanie typu w pythonie wymagałoby pracy, ale zostało zrobione, patrz projekt PyPy.

— Winston Ewert

1

@WinstonEwert "ale możesz refaktoryzować ręcznie, a dynamiczne języki faktycznie sprawiają, że jest to dość łatwe" - Nie, ręczne refaktoryzacja nie skaluje się. Obsługa narzędzi do refaktoryzacji zmienia wszystko, nawet gdy refaktoryzacja nie jest w 100% automatyczna (patrz fragmenty studium przypadku poniżej - programmers.stackexchange.com/a/166594/4334 )

— igouy

1

Prawie każdy punkt w „dynamicznym programowaniu faktycznie ułatwia refaktoryzację” jest wątpliwy lub niesekuruje. Programowanie dynamiczne nie oznacza, że masz bardziej wszechstronny zestaw testów, tylko większy (ponieważ niektóre rzeczy wymagają testowania, które w przeciwnym razie zostałyby przechwycone statycznie). Nie oferujesz żadnego wsparcia dla „refaktoryzacji ma tendencję do wpływania na mniej kodu” (jako dodatek do „projekt i tak jest mniejszy”, co prawdopodobnie jest prawdą, biorąc pod uwagę obecny zbiór języków dynamicznych). A „wysiłek związany z ręcznym refaktoryzowaniem” wydaje się niewłaściwy, chyba że masz na myśli, że nawet nie pozwolisz, aby Twój kompilator Ci pomógł!

— Rex Kerr

8

Refaktoryzacja została wynaleziona w dynamicznych językach. Zautomatyzowane narzędzia do refaktoryzacji zostały wynalezione w dynamicznych językach. IDE zostały wynalezione w dynamicznych językach. Opracowano kilka metodologii zwinnych w dynamicznych językach.

Naprawdę nie widzę żadnego problemu.

— Jörg W Mittag
źródło

„Smalltalk nie różni się tak bardzo od Pythona pod względem pisania. Jest jednak znacznie inny pod względem oprzyrządowania”. - Może to się zaczyna zmieniać, patrz jetbrains.com/pycharm/features/index.html

— igouy

3

Aby nie zapomnieć, „zwinny” sposób pracy, który stał się znany jako Extreme Programming (XP), został stworzony w projekcie Smalltalk (a Smalltalk z pewnością liczy się jako język „dynamiczny”).

Oto studium przypadku przemysłowego zastosowania narzędzia do refaktoryzacji wyposażonego w dynamicznie pisany język:

W firmie Cargill opracowano bardzo dużą aplikację Smalltalk, która wspiera obsługę podnośników zbóż i związane z tym działania związane z obrotem towarami. Aplikacja kliencka Smalltalk ma 385 okien i ponad 5000 klas. Około 2000 klas w tej aplikacji wchodziło w interakcję z wczesnym (około 1993 r.) Ramem dostępu do danych. Struktura dynamicznie przeprowadzała mapowanie atrybutów obiektów na kolumny tabeli danych.

Analiza wykazała, że chociaż dynamiczne wyszukiwanie zajęło 40% czasu wykonania klienta, nie było to konieczne.

Opracowano nowy interfejs warstwy danych, który wymagał od klasy biznesowej dostarczenia atrybutu obiektu do mapowania kolumn w sposób jawnie zakodowany. Testy wykazały, że interfejs ten był o rząd wielkości szybszy. Problem polegał na tym, jak zmienić 2100 użytkowników klasy biznesowej warstwy danych.

Duża opracowywana aplikacja nie może zamrozić kodu podczas konstruowania i testowania transformacji interfejsu. Musieliśmy skonstruować i przetestować transformacje w równoległej gałęzi repozytorium kodu z głównego strumienia programistycznego. Gdy transformacja została w pełni przetestowana, następnie zastosowano ją do głównego strumienia kodu w jednej operacji.

W 17 100 zmianach znaleziono mniej niż 35 błędów. Wszystkie błędy zostały szybko rozwiązane w ciągu trzech tygodni.

Jeśli zmiany zostaną wprowadzone ręcznie, szacujemy, że opracowanie reguł transformacji zajęłoby 8500 godzin.

Zadanie zostało ukończone w 3% oczekiwanego czasu przy użyciu Przepisywania Przepisów. Jest to poprawa 36-krotnie.

z „Transformacji warstwy danych aplikacji” Will Loew-Blosser OOPSLA 2002

Również - „Narzędzia do dokonywania niemożliwych zmian - doświadczenia z narzędziem do przekształcania dużych programów Smalltalk”

— igouy
źródło

1

Wasze zasady są dla mnie poprawne .

Języki o silnym typie, takie jak C #, są dobrymi kandydatami na bazę kodu, która stale wymaga ponownego faktorowania. Zasadniczo większość dostępnych na rynku narzędzi do przefakturowania (takich jak Resharper, JustCode itp.) Jest bardzo skuteczna w statycznych językach programowania.

Co projekty realnego świata mówią o używaniu dynamicznie typowanych języków do metodologii zwinnej?

Dla zespołu programistów, który ćwiczy metodologię Agile / Scrum, bardzo pomocne (nawet krytyczne) jest posiadanie dobrego zestawu narzędzi do faktoringu pod zbroją. W przeciwnym razie wszystkie nagłe zmiany w nadchodzącym sprincie mogą być koszmarem do modyfikacji lub przeprojektowania.

Zatem zwinna metodologia nie zapewnia korzyści dla języków o typie statycznym ani dynamiki jeden raz. Zapewnia iteracyjne podejście do tworzenia solidnej aplikacji.

— Jusubow
źródło

4

Języki dynamiczne miały zautomatyzowane narzędzia do refaktoryzacji na długo przed istnieniem C # i gdy Notepad był nadal najmocniejszym środowiskiem Java IDE.

— Jörg W Mittag

4

Moje doświadczenie całkowicie nie potwierdza tej odpowiedzi. Języki dynamiczne są zazwyczaj szybciej niż robić rzeczy w bardziej konwencjonalnych statycznie typowanych te (ja mam uczyć się Haskell lub ml lub coś podobnego, że kiedyś). Są też o wiele szybsze do modyfikacji, jeśli nagle będą potrzebne, co doprowadziło mnie do wniosku, że Common Lisp był najlepszym językiem, gdy tak naprawdę nie wiedziałeś, co robisz. Ponadto, jak myślisz, gdzie rozpoczęła się refaktoryzacja?

— David Thornley,

1

dlaczego tak myślisz, na przykład javascript jest językiem dynamicznym, ale Re-sharper nie wykonuje tej samej zręcznej pracy jak w C #. Po drugie, NIE powiedziałem, że „języki dynamiczne działają wolniej”.

— Yusubov

Od osób, które przyniosły Ci IntelliJ IDEA - PyCharm - „Zmiana refaktoryzacji pozwala na bezpieczne i natychmiastowe dokonywanie zmian w kodzie globalnym. Lokalne zmiany w pliku są wykonywane w miejscu. Refaktoryzacje działają w prostych projektach Python i Django. Użyj wprowadzenia Zmienna / Field / Constant i Inline Local do poprawy struktury kodu w metodzie, Extract Method, aby rozbić dłuższe metody, Extract Superclass, Push Up, Pull Down i Move, aby przenieść metody i klasy. ” jetbrains.com/pycharm/features/index.html

— igouy

@igouy, w mojej odpowiedzi mam na myśli Resharper i JustCode. Dotyczy to zatem kontekstu, do którego się odnosi.

— Yusubov