Jak to wygląda, dostajecie problem do rozwiązania i jak postępujecie. Piszecie program od razu, czy najpierw rysujecie algorytm. Jak to jest ?
0
1
Zależy od poziomu skomplikowania i doświadczenia w rozwiązywaniu danych problemów.
9
Myślałem że to jakaś ankieta typu "Jak często się myjesz".
Ja osobiście piszę sobie, rzeczy które chce zaimplementować. Po prostu wypisuje je w notatniku lub w komentarzach w kodzie.
Zwykle zaczynam pisać program od razu, choćby to miało być zrobienie GUI, bo już wiem że coś robie, a planować można w nieskończoność.
Umiejętność to dobrać długość planowania do stopnia problemu.
3
Hmm myję się każdego dnia - co prawda pod prysznicem bo chwilowo nie mam Windowsa 8, żeby łazienkę okafelkować ale się myję.
Dobra a tak na serio to najpierw biorę kartkę, ołówek i w ogóle piszę co ten program ma robić. Następnie modeluję sobie różne klasy i zachowania - też na kartce. Potem przystępuję do pisania. Ale nie tak, jak mówi @ubuntuser, że zaczynam od GUI.
Zaczynam od konsoli, gdzie sprawdzam poprawność działania wszystkich klas a następnie robię plan GUI, odpalam Expression Blenda i te GUI robię ;) Potem już z górki. Napisanie prostego programu w domu - for fun zajmuje mi mniej więcej dwa tygodnie z czego jeden tydzień poświęcam na planowanie a drugi na implementację - to działa.
1
Większość rzeczy nie jest na tyle skomplikowana, by wymagać ode mnie długiego myślenia "na sucho" czy pisania czegoś na kartce. Pod wieloma względami, robię tego typu planowanie i zastanawianie się rzadziej niż kiedyś.
Głównie dzięki większemu doświadczeniu oraz znajomości technik refaktoryzacji. Niewielkie fragmenty aplikacji preferuję pisać praktycznie bez planowania, można powiedzieć "na pałę", ale non-stop korzystam z doświadczenia, znajomości wzorców, zasad umożliwiających zachowanie jakości etc. Gdy tylko zauważę, że coś mogłem zrobić lepiej, natychmiast refaktoryzuję. Wydzielam funkcje, zmieniam nazwy zmiennych, zmieniam algorytmy.
Teraz, znacznie częściej niż kiedyś, korzystam z metody zstępującej. W zasadzie może dlatego szkice są mi zwykle niepotrzebne. Rozbijam problem na warstwy, na podproblemy. Idę od góry. Co algorytm ma robić tak ogólnie? Streszczam to sobie w kilku, zwykle nie więcej niż pięciu, krokach. Często jest tam jakiś warunek czy pętla. Robię z tego szablon pięciolinijkowej funkcji. Większość kroków to wywołania innych funkcji. Daję im nazwy, pomijając chwilowo ich implementację. Czasem zaznaczam sobie w głowie, że dana nazwa jest raczej słaba i że muszę pamiętać, by wymyślić coś lepszego i odpowiednio ją zmodyfikować, ale raczej nie zatrzymuję się na dłużej niż kilka małych minut, by koniecznie wymyślić tę lepszą nazwę w tym momencie. Gdy mam już szablon mojej funkcji, przechodzę do implementacji tych funkcji, które mają reprezentować poszczególne kroki. I powtarzam cały proces rekurencyjnie.
Powyższy proces przypomina projektowanie w pseudokodzie. Czasami faktycznie niektóre kroki zapisuję z początku jako komentarze, a nie wywołania funkcji.
Czasem -- niestety nie zawsze -- używam TDD lub BDD i wtedy wysokopoziomowy interfejs definiuję sobie najpierw w testach.
Niekiedy jednak trzeba się nad czymś zastanowić. Np. gdy projektuje się architekturę większego systemu. Tutaj refaktoryzacja jest już trudniejsza i wypada starannie przeanalizować wymagania stawiane przed systemem i środki do ich osiągnięcia, jeszcze zanim napisze się kod.
Ostatnio zajmowałem się właśnie czymś takim. Na razie już ze 2-3 dni siedziałem wraz z 1-2 innymi programistami w salce konferencyjnej, z tablicą do pisania, rzutnikiem i otwartymi jedynie plikami i edytorami służącymi do tworzenia dokumentacji. Do projektowania architektury zostali wybrani programiści, którzy mieli już wcześniej do czynienia z podobnymi aplikacjami. Zorganizowaliśmy też konferencję z firmowymi specjalistami od UX (User Experience) by architektura zapewniała realizację wymagań ze strpmy interfejsu i użytecznych, wygodnych funkcjonalności.
Stworzyliśmy diagramy obiektów, ustaliliśmy część wysokopoziomowych interfejsów, analizowaliśmy przypadki użycia, napisaliśmy trochę BUS-ów (Business User Stories), a także trochę snippetów kodu korzystającego z naszego przyszłego API żeby zobaczyć, na ile wygodne będzie używanie go w standardowych i niestandardowych sytuacjach. Perspektyw architektury stworzyliśmy kilka. Nie tylko diagram hierarchii obiektów, ale też np. diagram praw użycia (moduł X ma prawo używać modułów A i B, ale nie G). Mówiąc "diagram" mam na myśli coś bardzo ogólnego, bo zamiast postaci graficznej może to być zwyczajna lista cech w zwykłym teście.
Czyli, odpowiedź brzmi jak zwykle: to zależy.
Wracając do higieny, to w firmie mam na szczęście elegancki prysznic. Przydaje się, bo jestem biegaczem i lubię sobie do firmy pobiec (trwa to dużo szybciej niż komunikacja miejska+chód lub jazda samochodem w korkach), albo nawet zrobić przerwę w pracy na rundkę dookoła jeziora by oczyścić umysł. Po porządniejszej przebieżce, pominięcie prysznica mogłoby spowodować katastrofę ekologiczną i panikę na Wyspach Dziewiczych. Oj tak, higiena to ważna rzecz.