Przepływ pracy z piskiem

Question

Jestem nowicjuszem w pisowni i Smalltalk, ale nie programowaniem w ogóle (mam pewne doświadczenie w Pythonie).

Rozumiem różne narzędzia obecne w środowisku skrzypiącym, takie jak obszar roboczy, przeglądarka systemu, a także konstrukcje językowe Smalltalk. Rozumiem, jak działają w izolacji, ale nie wiem, jak mają być używane jako całość.

Moje pytanie brzmi: jaki jest typowy przebieg pracy podczas rozwijania w pisku. O ile rozumiem

I open squeak. 
I create a Class in the System Browser. 
I then write/test/execute code in the Workspace, adding methods 
to my class based on the code I tried out in the Workspace. 
Rinse and repeat for other classes. 

Czy powyższe zazwyczaj co smalltalkers śledzić czy są rzeczy, które Tęskniłam. Również inne ogólne wskazówki/gotchy (jeśli są) będą doceniane.

Dzięki.

BTW, ja nie szukać na ten temat i przeczytać kilka tutoriali, ale nie dostał żadnych satysfakcjonujących odpowiedzi, więc nie lmgtfy linki proszę;)

Answer 1

Co można opisać nazwałbym osobisty styl rozwoju. Ponieważ nie ma definitywnego sposobu, w jaki powinieneś się rozwijać, trudno powiedzieć.

Ale to, co opisujesz, jest realną opcją. Zwłaszcza jeśli nie jest jasne, jak rzeczy naprawdę pasują do siebie. Smalltalk ma siłę, że masz wszystkie przedmioty pod ręką. Można go wypróbować w przestrzeni roboczej. Jeśli masz pojęcie o tym, jak to powinno działać, nadszedł czas, aby umieścić swój kod na metodach. Jednocześnie dobrym pomysłem jest napisanie testu. W przestrzeni roboczej przetestowałeś swój kod z przykładowymi wartościami. To jest dokładnie test. Gdy umieścisz kod bez wartości w metodzie, możesz umieścić użycie tej metody z przykładowymi wartościami w teście. Testy pomagają rozpoznać, czy zmieniasz coś fundamentalnego podczas konstruowania całości.

Innym stylem rozwoju, którego używam, jest użycie inspektora. Zwłaszcza jeśli przynosi się rzeczy z sieci, to dość łatwe do zrobienia. Powiedzmy, że odzyskujesz xml z api sieci z sieci. W obszarze roboczym wydaję polecenie pobierania url i otwieram inspektora na wynik. W inspektorze zaczynam analizować wynik i na każdym pojedynczym kroku przetwarzania otwieram kolejnego inspektora na wynik, aż uzyskam wynik, który chciałem osiągnąć. Od tego momentu wszyscy inspektorzy są ustawieni jeden na drugim. Po prostu tworzysz metody od każdego inspektora, poczynając od ostatniego kroku, kończąc inspektora, wziąwszy następnego inspektora i tworząc z niego metodę, itd.

Wreszcie wielu deweloperów lubi rozwijać się przy pomocy debuggera. Po prostu piszemy kod tak, jakby już istniał. Możesz zmienić kod podczas korzystania z debuggera i możesz ponownie uruchomić bieżące wykonanie bieżącej metody. Wykonanie go dostanie ci następny debugger. Dodajesz kolejną potrzebną metodę, a następnie kontynuujesz program. Otrzymasz następny debugger itp.

Widzisz, istnieje wiele możliwych stylów. Ale który z nich jest najlepszy, to twoja osobista opinia.

Answer 2

Zazwyczaj pracuję z trzema otwartymi oknami: dwoma przeglądarkami i testrem. Piszę test, aby dowiedzieć się, jak chcę rozmawiać z obiektem - jego API, jeśli chcesz. Następnie uruchamiam TestRunner, upewniając się, że test się nie powiedzie z powodów, których się spodziewam.

Zrobię jedną z dwóch rzeczy - albo zapisz nową metodę, której potrzebuję bezpośrednio w Debuggerze, i zrestartuj test, aż będzie zielony, albo przejdź do drugiej przeglądarki i napisz potrzebną metodę.

Czasami używam Workspace, głównie jako rodzaju scratchpad, tak jak można używać REPL Pythona. Jeśli napisałeś klasową metodę #initialize, prawdopodobnie będziesz chciał ponownie zainicjować swoją klasę z Workspace.

Answer 3

TDD jest również opcją do opracowania Smalltalk. Squeak pochodzi z SUnit.

Możesz połączyć TDD i debugger, uruchamiając test - który kończy się niepowodzeniem, ponieważ jeszcze nie napisałeś tej metody - więc używasz debuggera do stworzenia metody, następnie wkraczasz do metody i piszesz tylko tyle kodu, aby uzyskać test do zaliczenia.