Podejście do nowego projektu.

Witam,

chciałbym zapytać w jaki sposób Wy podchodzicie do nowego projektu. Powiedzmy że dostajecie "zlecenie" na napisanie takowego programu:

Napisz program wspomagający naukę słownictwa w języku angielskim.

opcje programu:

• dodawanie słów do bazy danych
• wylosowanie rekordu i w zależności od wybranej opcji czy chcemy pisać polskie tłumaczenie czy ang wyświetlenie najpierw słowka i oczekiwanie na tłumaczenie.
• sprawdzenie podanego tłumaczenia i wyświetlenie odpowiedniego komunikatu.

i teraz moje Pytanie. W jaki sposób podchodzicie do projektu na początku? Kartka papieru i wypisanie najpierw nazw klas jakie będą potrzebne? czy to wychodzi w trakcie pisania? jakie kwestie przemyślicie na samym początku projektu? (pomijam trywialność owego "projektu").

Kartka papieru i wypisanie najpierw nazw klas jakie będą potrzebne? :D :D :D tak, a potem rysuje wszystkie diagramy... :P

Na początku to wybieram sobie mniej więcej w jakiej technologii chciałbym to zrobić, w jakim języku, czy to desktop czy web itd. Potem montuje stuba dla tego projektu a potem to się po kolei klepie co tam ma być.

czyli piszesz kod bez większego planu na żywca??;)

Trellloooo! ;) Zawsze gdy wpada mi jakiś pomysł czy ogólnie zadanie/projekt do zrobienia... staram się go rozpisać na trello. Zaczynam od opisania ogólnie tego co mam zrobić i podziału na ogólne "moduły" i tak schodzę bardziej do szczegółów.

Trelo jest dość spoko do takich rzeczy szczególnie, że jest darmowe.

Doswiadczenie z gra ktora pisze pokazuje ze warto spedzic troche czasu na zastanowieniu sie co i jak i chocby bardzo ogolnym rysunkiem jak to bedzie dzialac, co z czym bedzie rozmawiac czego uzywac etc.

Zalozenie mialem takie: pisze na zasadzie byle szybko, dozwolone kopiuj wklej, magic numbers, wszystko na public etc. Tak jak sie robi prototyp :) I jaki efekt? Na poczatku do pewnego momentu wszystko idzie ladnie szybko, a pozniej zmiana czegokolwiek, poprawa buga etc zaczynaja zajmowac duzo czasu, takze teraz bawie sie w refaktoring, wyciaganie interfejsow i programowanie do nich etc. Gdybym tak zrobil od razu - byloby szybciej. Z drugiej strony warto samemu przez cos takiego przejsc zeby zobaczyc jak szybko potrafi sie zrobic syf w projekcie.

No właśnie miałem podobnie jak pisałem jakiś czas temu większy projekt. Też uznałem że będę pisał na bieżąco i w efekcie okazało się że to co pisałem bez większego przemyślenia albo musiałem od nowa przepisywać albo poprawka czegokolwiek była czasochłonna. Z drugiej strony tak jak to napisał @Shalom po dłuższym przemyśleniu rozpisywanie na kartce papieru nazw klas itp nie ma sensu gdy projekt jest znacząco rozbudowany...

wiosek jest taki że trzeba wyrobić sobie porządek w kodzie od pierwszych linii kodu?

rafal20-1988 napisał(a):

wiosek jest taki że trzeba wyrobić sobie porządek w kodzie od pierwszych linii kodu?

Bez przesady: Porządek przeszkadza cały czas (bo tracisz czas na jego utrzymanie). Bałagan przeszkadza dopiero jak się potykasz.

Punkt 0 - jest taki, że nie ma prostej odpowiedzi

Punkt 1
jak piszesz sobie sam - to nie warto przesadzać z porządkiem - jak się potykasz to sprzątaj od razu, ale może nie warto wcześniej...,
jak piszesz w zespole - to im większy zespół (5 programistów to już dużo) - tym więcej narzucaj reguł i porządku, całkiem fajnie pomaga review
(robisz coś - na czuja, porządkujesz przed review, robicie review - i dopiero potem (magicznie!) okazuje się jak powinna wyglądać struktura tego kawałka programu, zwykle zupełnie inaczej niż byś to sobie na kartce zaprojektował (przynajmniej mi tak wychodzi...)).

Punkt 2:
Ale są też indywidualne preferencje - na poziomie kodu - tak jak przedstawiłeś - lubię bałagan ( cieszę się jak mi coś zadziała, a nie wiem czemu :-) ). Znam dużo takich programistów jak ja.
Ale znam też programistów co potrafią sobie całkiem dużo zaprojektować, i nawet im to potem od razu działa. (Ale nie rozumiem jak można sobie tak psuć zabawę :-) ).

Punkt 3:
Ale oprócz takich rzeczy jak klasy, moduły (i inne pier...ły) sa też rzeczy ważne: np. przepustowość systemu, bezpieczeństwo danych, odpornośc na różnego rodzaju awarie, komunikacja z innymi systemami.. Tu niestety zwykle potrzebuje sobie coś poprzepliczać, rozrysować itp. Ale pewnie są też goście co ogarniają to z głowy i nie muszą sie wspomagać żadnym (tfu...) "planowaniem".
Ten punkt jest ogólnie smutny, ale jeśli pracujesz dla firmy, masz jakiś konktrakt, kary itp. to niestety trzeba to odbębnić. Bo czasem się okazuje, że kontrakt jest nierealizowaly przy założonej technologii :-) (Hard real time, CAP). Albo może cię zasokoczyć np. ochrona danych osobowych....(nie w twoim przykładowym systemie, ale mnie kiedyś zaskoczył problem).