Projektowanie i planowanie kodu

Ciekawi mnie w jaki sposób planujecie swój program/kod. Przykładowo macie stworzyć aplikację, która parsuje dane wyciągając ze z jakiegoś np. pliku czy strony, umieszcza je w bazie danych w wielu tabelach, na żądanie użytkownika wykonuje wiele różnych akcji zwracając np. wynik jakichś działań na danych, wykresy, umożliwia użytkownikowi manipulacje danymi.
W skrócie - program mający w pizdu opcji.

Zabieracie się za robotę. Macie specyfikację (albo chociaż jakiś pomysł na to jak to ma wyglądać) i co dalej? Siadacie i kodujecie, układacie sobie w głowie strukturę kodu, rozrysowujecie sobie na kartce, używacie jakichś programów?

Dzielę problem do rozwiązania na jeszcze więcej problemów do rozwiązania :D Spróbuj to działa.

Ostatnio piszemy grę z kumplem i ja jestem w niej taki "project managerem" więc ja to zaplanowałem.
Napisałem listę klas co po czym dziedziczy, opisałem trochę te klasy oraz przedstawiłem jak ta gra ma wyglądać (a zapomniałem jeszcze, zaznaczyłem kolorkami kto co robi). Później File > Save as pdf wysłałem to koledze, on zadał kilka pytań odpowiedziałem i zaczęliśmy pisać ;)
To takie proste projektowanie ale jednak.
Jeśli chcesz ładnie zaprojektować klasy to polecam program Poseidon bardzo intuicyjny i ładny program ;)
Moim zdaniem lepiej zaprojektować niż później (przepraszam) kur#!%ać - mówię to z mojego małego doświadczenia.

Ja zazwyczaj odpalam Lucidchart i tam rozrysowuję sobie większość. Głównie ERM i jak to jest to zaczyna się http://programming-motherfucker.com/.

Co do 'po prostu programowania', jest takie powiedzonko: "if you fail to plan, you plan to fail". Tworzenie architektury 'w biegu' nie jest rozsądnym wyjściem, a dlatego, że potem powstaje za dużo zależności, chyba że ma się w tym dużą wprawę. Poza tym, im bardziej skomplikowany projekt, tym bardziej jest wymagający pod kątem projektowania.

Ja pochwalam metodę kartki + ołówka. Wypisuje sobie, jakie zadania/funkcje ma mieć mój soft, na podstawie tego tworzę klasy, zależności i opisuję za co każda klasa jest odpowiedzialna i w jaki sposób się między sobą komunikują. Jednak bez wprawy ciężko od razu stworzyć coś fajnego, dlatego często korzystam z drugiej metody, czyli "jak to działa z zewnątrz". Wypisuje sobie, co ma się po kolei wykonywać, aby uzyskać wykonanie zadania. Wtedy jakoś łatwiej mi rozplanować zakres działań dla każdej z klas i co tak naprawdę jest mi potrzebne.

Projektowanie wymaga doświadczenia a doświadczenie pozwala na swobodne programowanie bez projektu. Serio. Ale tak da się ogarnąć tylko jak samemu robi się projekt. Jeśli jest się w grupie to od projektowanie jet właśnie człowiek z doświadczeniem. W większej grupie człowiek od projektowania to tak na prawdę zespół ludzi ogarniających problem od każdej strony.

Projektowanie klas na podstawie tylko "co to ma robić" bardziej podchodzi pod "Jebne se klase... Jebłem". Po to są wzorce projektowe, aby z nich korzystać. Nie za bardzo łatwo jest też opisać projekt bez znajomości założeń systemu z jeden strony, a czytelnego dla programistów zapisu z drugiej strony...

i tak mógłbym pisac ale odpowiadając na główne pytanie @Wizzie - gdy mam "grubasa" do zrobienia i jestem tym od projektowania, to zabieram się od zdefiniowania problemu biznesowego i podproblemów, potem przekładam to na pierwszorzędne wzorce projektowe, a następnie pod to dopasowuje resztę tak, aby nie robić waterfalla, ale bardziej coś na wzór agile. Gdy mam do zrobienia coś małego - PROGRAMMING MOTHERFUCKER!

nie planuje/nie projektuje. Wszystko w glowie, spontanicznie robione.

A może ktoś polecić jakiś soft do zbierania wymagań? Taki by miał zależności graficzne. Kiedyś u jednego PM'a widziałem takie coś ale zapomniałem nazwy :/

Idea taka, że wszystkie rzeczy są grupowane i do każdej grupy można wprowadzać podgrupy, do których można dalej wprowadzać podgrupy, co graficznie tworzy nam taką piękną jakby 'gwiezdną mapkę'. Dzięki czemu można zmieniać sobie scope widząc np same moduły.

Spisywanie wymagań w wordzie nawet jak to się robi od myślników szybko prowadzi do zgubienia scope'a modułowego, czy zatarcia się współdzielonych rzeczy.

wasiu napisał(a):

A może ktoś polecić jakiś soft do zbierania wymagań? Taki by miał zależności graficzne. Kiedyś u jednego PM'a widziałem takie coś ale zapomniałem nazwy :/

Jira.

Jak zwykle to zalezy:)

Jesli mala rzecz poza procesem w pracy (narzedzie, skrypt itp) siadam i robie odplajac co chwile i patrzac czy idzie wszystko w dobra strone. Jesli trzeba robi sie potem workaroundy, lata dziury itp. Tutaj wazne jest by bylo szybko i by rezultat dziala (za to utrzymanie pozniej i zmiany moga byc trudniejsze). Np. jak potrzebuje skrypt shellowy ktory cos sprawdza, przetwarza itp. wiecej czasu zajmie rozpisywanie tego na kartce niz napisanie.

Z kolei jak jest cos wiekszego lubie zaczac od prototypu, poskladac cos co z grubsza zacnzie robic to co trzeba. Pozniej bazujac na wiedzuy ktora mam projekt.rozpisanie na kartce i do roboty.

Z kolei na Compo najpierw cala noc sie ustala co robimy, jak sie dzielimy obowiazkami, ktore rzeczy najpierw, ktore pozniej, a ktore sa opcjonalne jak czasu brak a pozniej sie daje z siebie wszystko. Niestety w codziennej pracy sie tak nie da bo po 1-2 tygodniach czlowiek by wyladowal w szpitalu z przemeczenia.

Ja zwykle robię to tak:

Jeżeli problem jest rozbudowany, staram się go podzielić / zredukować do prostszego lub wcześniej rozwiązanego problemu. Zastanawiam się, co jest najważniejszą funkcją (jak to mawiają "minimum viable product"), która nadawałaby się do pokazania komuś. Na początku skupiam się tylko na najważniejszej.

Jeżeli ta najważniejsza funkcja jest nadal za duża, aby zakodować w jeden dzień, to zaczynam od eksplorowania rzeczy najbardziej ryzykownych / najtrudniejszych / zwykle ukrytych przed użytkownikiem. Czyli nie zabieram się za interfejs, dopóki nie mam zrobionego silnika. Później zwykle jest już z górki. Po prostu piszę kod, zwykle bottom-up, równolegle z testami, stopniowo dodając funkcjonalność. Tzn. trochę kodu, trochę testów. Pisanie bottom-up ma tę zaletę, że praktycznie od pierwszych 5 minut kodowania zawsze mam coś działającego i przetestowanego. Składam kod z małych kawałków, często przerabiam, często refaktoryzuję, szukam możliwości uproszczenia. Przed napisaniem danego fragmentu kodu (czy to klasy, czy metody) również sprawdzam, czy nie da się zrealizować jakąś biblioteką.

W pewnym momencie dochodzę do etapu, kiedy jest funkcjonalność jest na tyle bogata, że można zrobić demo i/lub myśleć o włączeniu mojego kodu do reszty.