Jak wy rozpoczynacie pisanie programu

Jak wy rozpoczynacie pisanie programu czy robicie najpierw model konceptualny programu czy od razu piszecie kod, ja wiem, że powinno się najpierw projektować model konceptualny programu jednak tego nie robię jako nie potrafię, a jak wy robicie model konceptualny to w czym ?

"model konceptualny" dot. bazy danych więc jak program nie korzysta z bazy to go nie trzeba robić.

Ja zawsze piszę System.out.println("Hello World"); a potem już nic, ponieważ zastanawiam się w którym frameworku JS zrobić front.

Czasami rysuję sobie jakiś wstępny diagram powiązań między modułami, czasami schodzę niżej i robię to samo dla klas.
A czasami nie.

Pisze notatke co ma ten program robic. Np. w Markdown.

Ja tam lubię sobie rozpisać wszystko na kartce papieru - jakiś wstępny koncept, który prawie zawsze ulega zmianie już na tej kartce papieru.

kod się jakoś sam układa, za to na kartce rozrysowuje sobie projekt interfejsu, bo to jest zawsze problematyczne.

mr_jaro napisał(a):

kod się jakoś sam układa, za to na kartce rozrysowuje sobie projekt interfejsu, bo to jest zawsze problematyczne.

Jeśli chodzi o rozrysowanie na szybko to ja używam tego https://www.draw.io

Ja wypisuję sobie w punktach co ma robić program i jak. W jednym przypadku napisałem na kartce schemat blokowy pokazujący działanie pewnej najważniejszej funkcji w programie, ponieważ po prostu nie mogłem sobie dokładnie ogarnąć "w głowie" jak ma to działać.

Tutaj masz podobny wątek poruszany - Problem z prawidłowym rozplanowaniem aplikacji - diagram klas pajęczyna

Jak piszę dla siebie, to przeważnie są to proste programiki/toole i uprawiam radosną twórczość, i później najwyżej poprawiam/przepisuję.

Jak mam napisać coś bardziej złożonego to już się zastanawiam co i jak, i zawsze mam zapisanych kilka kartek A4.

ja zaczynam od throw new NotImplementedException();

Niczego nie rozpisuję. Od razu kod. Tyle tylko że zaczynam od minimalnej wartościowej funkcjonalności. Przeważnie na początku jako prototyp w jakimś szybkim język, przeważnie bash lub awk. Potem iteracyjnie, krok po kroku. Gdy przyjdzie pora można zakodować coś w bardziej wydajnym języku jeśli zachodzi konieczność. Może też się zdarzyć, że na przykład po drodzę zmodyfikuję kod któregoś programu składowego, bo nie pasuje do oczekiwań :)

projektować model konceptualny programu jednak tego nie robię jako nie potrafię, a jak wy robicie model konceptualny to

Dla mnie bardzo ważne jest mieć pewien model mentalny w głowie, tzn. rozumieć swój program na głębszym poziomie, umieć wyobrazić sobie, jak działają jego poszczególne części. Wtedy można sobie spokojnie rozplanować poszczególne moduły, sposób w jaki się między sobą komunikują, jak będzie wyglądać format danych itp. Wyobraźnia przede wszystkim i ogarnianie tego umysłem.

Jeśli wyobraźnia nie wystarcza, to są jeszcze kartki papieru, narzędzia do diagramów (np. draw.io), czy inne tego typu rzeczy - kiedyś nawet w Blenderze (programie do robienia 3D) zrobiłem wizualizację architektury programu.

Czasem też warto stworzyć na szybko działający prototyp programu, który też pomoże odpowiedzieć na wiele pytań i wykryć wiele problemów (wiele problemów po prostu nie jest widocznych, zanim człowiek nie ruszy d**y i niezaprogramuje czegoś w praktyce).

Jak wy rozpoczynacie pisanie programu czy robicie najpierw model konceptualny programu czy od razu piszecie kod

Przy porzuceniu waterfalla okazuje się, że wcale nie jest aż takie ważne od czego się zacznie, skoro i tak w następnej iteracji można zacząć od czegoś innego.

(czasem przyjmuje się, że 1 iteracja = 1 sprint, ale dla mnie to zbyt sztywne pojmowanie koncepcji iteracji. Sprint to kupa czasu, a dla mnie już w ciągu dnia powinna być widoczna iteracyjność, inaczej mamy do czynienia z waterfallem na mniejszą skalę).

Ilustrując - mogę np. siąść do kompa i nie myśląc i napisać od razu kod (taki na brudno, taki prototyp). Ale to mnie nie wiąże specjalnie, ponieważ np. po 2 godzinach, mogę odejść od kompa i zacząć myśleć nad rozwiązaniem. A potem znowu do kodu, może będę kontynuował to, co napisałem, może będę pisał od nowa (bo po przemyśleniu się okaże, że istnieje lepszy sposób na napisanie czegoś).

I efekt jest taki, że na koniec dnia* coś tam zrobię, jakiś progres zostanie osiągnięty, zarówno jakiś kodzik napisany, jak i moja wiedza o projekcie ("model mentalny") się powiększy. Jednak czy będzie miało znaczenie, czy zacząłem od pisania kodu, czy zacząłem od projektowania, jeśli wszystko się przeplata i nic nie jest definitywne (raz napisany kod można przecież skasować czy zrefaktoryzować, raz rozplanowaną rzecz można zawsze zmienić, jeśli w trakcie implementacji okazuje się, że plan był zły).

* śmieszy mnie popularność tej kalki z angielskiego, bo to jakby po angielsku mówić "thank you from the mountain", ale tutaj akurat pasuje, bo faktycznie chodzi o koniec dnia.

Z reguły pomysł na daną funkcję siedzi i kwitnie w głowie, ale często pomagam sobie rozpiskami na kartkach (gdy jest więcej informacji do zapamiętania lub gdy problem jest nieco bardziej skomplikowany).

Ja piszę program, dzięki któremu wiem jak ten program ma wyglądać.

LukeJL napisał(a):

Przy porzuceniu waterfalla okazuje się, że wcale nie jest aż takie ważne od czego się zacznie, skoro i tak w następnej iteracji można zacząć od czegoś innego.

Agile w praktyce - nie wiemy co robimy, nie wiemy po co, nie wiemy czy będą warstwy, ile będzie modułów, czy będzie baza danych, czy relacyjna, czy obiektowa, czy z czymś się trzeba integrować, nic nie wiemy tylko siedzimy i napieprzamy w klawiaturę jak małpki. :D

Zdecydowanie od zrobienia dobrej kawy ;)

1. Spisuje co ma robić program.
2. Robię poglądowy szkic architektury, przepływu danych, etc. ( jak i w czym? ołówkiem w zeszycie :) )
3. Zaczynam kodowanie. Czasami wracam do punktu 2.

@somekind

I napisałeś, że nieważne od czego się zaczyna... jak Leszek Miller normalnie.

Ale ja pisałem w kontekście wielu dni. Każdy dzień to rozpoczęcie czegoś na nowo. Więc nie ważne, czy jednego dnia zacznę od kodowania, czy od myślenia, bo i tak będzie tu i myślenie i kodowanie.

Ale jeśli miałbym powiedzieć od czego zaczynam projekt tak od samego początku, to pewnie od zrozumienia problemu, bo to jest najważniejsze, żeby rozumieć problem, co jest do zrobienia, jak to zrobić itp.

Tylko, że w praktyce proces zrozumienia u mnie to nie jest coś na zasadzie "siedzę i myślę nad każdym szczegółem, a potem mam wszystko ustalone i tylko napieprzam w klawiaturę". To by się nie sprawdziło i tak, ponieważ i tak każdy najdoskonalszy plan idzie w p...u wcześniej czy później. Jak czegoś nigdy nie robiłem, to zwykle nie mam na tyle dużej wiedzy o problemie, żeby dobrze zaprojektować rozwiązanie (mało kto ma).

Raczej jest tak, że robię sobie w głowie wstępny plan, ale potem jednak siedzę i koduję - np. może robię proof of concept, czy jakiś prototyp, może jeden z modułów, może robię szkielet aplikacji.

Potem jednak znowu się zatrzymuję i patrzę na to, co zrobiłem. Być może pierwsze założenia były złe. Może trzeba będzie dalej przemyśleć problem.

Wolę więc się posuwać powoli, ostrożnie. Planując każdy krok i mieć przemyślane wszystko, co zakoduję (więc myślenie i kodowanie będą się przeplatać), niż po prostu wymyślić sobie jakiś naiwny skomplikowany plan raz a dobrze i go tylko realizować wierząc, że pierwszy plan był dobry (bo zwykle nie jest).

LukeJL napisał(a):

Więc nie ważne, czy jednego dnia zacznę od kodowania, czy od myślenia

No tak, niektórym jest wszystko jedno ;)

Wolę więc się posuwać powoli, ostrożnie. Planując każdy krok i mieć przemyślane wszystko, co zakoduję (więc myślenie i kodowanie będą się przeplatać), niż po prostu wymyślić sobie jakiś naiwny skomplikowany plan raz a dobrze i go tylko realizować wierząc, że pierwszy plan był dobry (bo zwykle nie jest).

Nie chodzi o to, żeby zaprojektować każdą metodę w aplikacji od razu, a potem zacząć implementować, tylko o zaprojektowanie sensownego kawałka pracy. Dzień w dzień może to być zestaw klas czy metod do napisania na dany dzień, ale na początku projektu, siadając przed pustym IDE, trzeba mieć chociaż zgrubny plan jakichś modułów i warstw oraz interakcji ze światem zewnętrznym.
Brak tego wygląda na brak wiedzy o tym, co się ma zamiar zrobić.

1. Jeśli wiem co i jak napisać, to siadam i piszę.
2. Jeśli nie wiem, to myślę / pytam / gadam z ludźmi, aż będę wiedział. A potem goto 1.

http://programming-motherfucker.com

Bardzo dużo zależy od kontekstu, tj. im większy projekt tym ważniejsza jest robota na starcie i projektuje się na wyższym poziomie.

Zazwyczaj jednak to jest tak, że trzeba doklepać jakiś kawałek do czegoś istniejącego, wtedy po prostu określam, w jaki sposób coś ma współdziałać z resztą świata.

zwykle zaczynam od pograzenia sie na pare chwil w infantylnych marzeniach jak to bedzie fajnie dzialac i od razu zabieram sie do kodowania.
po okolo tygodniu wywalam i startuje od nowa, z wiedza czego mam nie robic :)

W sumie ja źle zaczynam pisanie programu bo jeszcze za nim nie mam ustalonej kategorii co ma robić program to ja już pisze kod.

przełożony: siadaj i pisz
programista: ale co mam pisać?
przełożony: pisz, pisz, potem ci powiem.

Prywatne projekty rozrysowuje w umlu w stylu DDD. Jak mam wszystko rozrysowane to staram się pisać testy BDD, następnie koduje modele.
Jak już wszystko pod spodem działa jak należy i przechodzi testy to zaczynam tworzyć UI.
W pracy staram się robić podobnie, ale zwykle najpierw tworze minimum testów, i dopisuje je stopniowo. Niestety w pracy nie zawsze mamy od razu wszystkie wymagania wiec podejście jest bardziej agile ;)