Proces tworzenia, projektowanie aplikacji

Jak to jest z wami używacie jakiś narzędzi do zaprojektowania aplikacji a dopiero potem zaczynacie kodzić według waszego projektu czy może kartka + ołówek a może wymyślacie na bieżąco podczas pisania kodu?

Od kilku dni piszę odtwarzacz muzyki konsolowo w c# i mam tak, że pisze jakiś fragment przez 2-3 godziny a następnego dnia to kasuje i piszę inaczej tak samo na bieżąco wymyślam/dodaje funkcje w programie i tworze im metody.
Jest to mój pierwszy projekt takiego kalibru(pisany samemu nie przykład z książki:D) i nie wiem czy od razu przy pisaniu danego fragmentu maksymalnie go optymalizować(zamiast 50 przypisań do stringa użyć stringbuildera czy lepsze zarządzanie tablicami itd...)

Jak to wygląda u was wpierw piszecie szkielet byle działało a potem wprowadzacie zmiany upiększając go?

Zależy od skali projektu. Zasadniczo podejścia są dwa:

• bottom up (czyli piszemy po kolei komponenty z ktorych program będzie się składał i na bieżąco je integrujemy)
• top down (czyli najpierw piszemy cały szkielet z zaślepkami a potem dopisujemy funkcjonalności).
  Oba podejścia są ok, w zależności od sytuacji. Np. jeśli od razu jesteś w stanie stwierdzić jakie funkcjonalności będą potrzebne i jak to ma mniej więcej wyglądać to podejście drugie jest lepsze.
  Jeśli chodzi o małe, jednoosobowe projekty to bawienie się w malowanie diagramów jest trochę przerostem formy nad treścią. Mimo wszystko warto sobie gdzieś pewne rzeczy notować, żeby się potem nie glowić nad tym "co ja tu w ogóle chciałem zrobić" ;]

Zależy od projektu, niemniej dobrych nawyków lepiej się uczyć od początku. Jeśli piszemy aplikacje, niedużą, tylko na własne potrzeby czy dla potrenowania swoich umiejętności to nic nie stoi przecież na przeszkodzie, żeby sobie ją po prostu zaplanować. Nie mam tu na myśli kupienia wielkiej tablicy, 30 markerów i 48-godzinnego rysowania diagramów UML, ale zwykły, prosty mini-projekt architektoniczny. Ja zawsze staram się po prostu rozpisać co chce zrobić, co za co będzie odpowiadać i jak będzie wyglądać. Nic szczegółowego, ot tak czysty ogólny opis, który da mi pogląd na cały projekt. Kiedy mam już ten pomysł, staram się napisać to co wiem na pewno i wtedy znowu pojawiają się dodatkowe pomysły do rozważania, a więc powracam do projektu, gdzie dodaje kolejne elementy. Nie wiem czy to podejście jest dobre, myślę, że nie jest najgorsze, ale jeśli jestem w błędzie to proszę o uświadomienie ;).
Wychodzę z założenia, że w trochę większym projekcie (np. mini-projekt aplikacji sklepowej czy bankowej) wymaga trochę więcej rzeczy, które pojawiają się np. w trakcie kodowania. Nie zawsze na początku da się wszystko zaprojektować i opisać dokładnie każdy szczegół programu. Z tego, co wiem takie podejście jest bardzo złe.
Jeśli jest to mały projekt, to oczywiście można to zrobić łatwo, szybko i przyjemnie i co ciekawe bez większych błędów. Jeśli wiemy dokładnie wszystko, co chcemy napisać - to siadamy i kodujemy.
Ogólnie rzecz biorąc, zawsze lepiej przemyśleć coś 10 razy i zrobić to dobrze, niż siąść i pisać, a potem łapać się za głowę i pytać siebie "O co tu k**** chodzi".

Ja biorę kartkę i długopis, i najpierw rysuję moduły aplikacji. Następnie dla każdego z nich wypisuję klasy, jakie musi posiadać, a potem dla każdej klasy jej publiczne metody. Następnie odpalam IDE i robię z tego szkielet aplikacji, a potem kodzę.
Kartek używam też do rozpisania sobie jakichś algorytmów, których nie jestem w stanie przemyśleć w głowie.