Forum Debian Users Gang

Może tak:

Raczej nie mam specjalnego doświadczenia w kończeniu dużych projektów, za to z zaczynaniem... :) generalnie leży u mnie na dysku prosty system operacyjny, interpreter i runtime dla własnego języka, kilka gier, system kontroli wersji i kilkanaście mniejszych pierdół - wszystko zaczęte, nic nie wyszło poza fazę alfa. Pewnie ktoś, kto się bardziej zna, zaraz mnie uciszy, wytknie błędy w moim podejściu do designowania, ale co tam. Więc... Ja robię to tak:

1. Zbieram do kupy wszelkie pomysły. Zabazgrowuję ładnych kilka kartek w zeszycie. Robię notki w Basket. Porównuję mój projekt z innymi, podobnymi projektami, próbując wskazać gdzie będzie od nich lepszy, gdzie wygodniejszy, gdzie estetyczniejszy, a gdzie po prostu inny. Określam dokładnie jeden, jedyny problem, jaki mój program ma rozwiązać - może to być duży problem, składający się z mniejszych problemów, oczywiście. Tym problemem niech będzie na przykład stworzenie odtwarzacza muzyki, który nie będzie do dupy. Jako nie bycie do dupy rozumiem na przykład: brak zbędnego GUI, lekkość, wygoda obsługi zarówno z powłoki basha jak i IPythona (korzystam regularnie z obu, na przemian).

2. Staram się dzielić projekt na mniejsze moduły. Jeśli będzie to np. ten odtwarzacz muzyki, podzielić go można na część odpowiedzialną za samo odtwarzanie (silnik), część od playlisty, część od bazy utworów, część od interfejsu, itd. Robię na kartkach diagramy, strzałeczkami pokazuję sobie który moduł gada z którym - np. interfejs gada z playlistą, by nią manipulować, i z bazą, by ją odpytywać. Playlista gada z bazą, by pobrać nazwy plików, oraz z silnikiem od muzy, by mu powiedzieć czy czas odtwarzać ten utwór czy tamten. Sam silnik jest równie inteligentny jak mpg123 i jego jedynym zadaniem jest pobrać plik z dysku i na komendę zacząć lub przestać go odtwarzać, itd. Tutaj trzeba po prostu wyczucia - jak układać po sobie warstwy, by jedna nie właziła w drogę innej. Jak rozmieścić poszczególne funkcje odtwarzacza - aby na przykład moduł odpowiedzialny za samo odtwarzanie (silnik) nie musiał nigdy gadać bezpośrednio z bazą utworów. Na tym etapie zazwyczaj kartka jest już cholernie pokreślona, sam design zaś mniej więcej kompletny - nie zmieniam go potem, najwyżej zostawiam miejsce na dodatkową warstwę pomiędzy dwoma modułami, by potem móc jakoś zrobić np. equalizer (i zrobić go tak, żeby nie rozp... reszty). To chyba najtrudniejsza część - dobrze ją zrobisz i reszta jest oczywista. Spieprzysz - będziesz do niej wracał, aż wszystko w końcu zadziała.

3. Próbuję dobrać odpowiedni język i biblioteki do wykonania zadania. Dopiero na tym etapie zastanawiam się, czy np. lepiej jest zrobić interfejs w GTK czy w ogóle CLI. Czy lepiej zakodować szajsik w C czy w Pythonie. Jako "silnik" odtwarzacza wybieram na przykład GStreamera, gdyż wystarczy mu podać nazwę pliku i powiedzieć "graj", resztę zrobi sam. Na interfejs wybieram na przykład linię komend, bo nie lubię pisać programów w GUI. Jako język wybieram Pythona, gdyż projekt nie wymaga "mielenia numerków" i ogólnie jest lekki dla procesora, zaś krytyczne części i tak znajdują się w zoptymalizowanych bibliotekach. Python ma też bindingi do GStreamera, i znalazłem przykładowy kod pokazujący jak np. odtworzyć pojedynczy film czy mptrójkę. Innymi słowy - zazwyczaj dobieram narzędzie do danego podproblemu dopiero wtedy, gdy ów podproblem jest już jasno określony. Warto więc czasem mieszać punkty 2 i 3 - widząc, że dany podproblem da się z miejsca rozwiązać, oszczędzam sobie zachodu (tak np. nie muszę się martwić, czy mój odtwarzacz będzie obsługiwał mp3, ogg, wav, wma - tym martwi się za mnie GStreamer).

4. Szukam więcej przykładowego lub podobnego kodu, który częściowo rozwiązuje jeden z wytyczonych podproblemów (np. wyszukiwanie w przód i w tył po utworze). Zbieram takie "snippety", często zrzynając po kilkadziesiąt linii, a czasem nawet całe hierarchie klas, notując licencje i autorów (by wymienić ich w creditsach). Gdy licencja mi nie pasi - wzoruję się na istniejącym kodzie, by napisać od nowa własny. Piszę następnie klasy "wrappujące" owe fragmenty w moduły, tworząc proste i przejrzyste interfejsy: na przykład klasa "owijająca" GStreamera powinna mieć takie metody jak "teraz zajmij się tym plikiem", "odtwarzaj obecny plik", "jaka jest pozycja kursora w utworze", "ustaw pozycję kursora", itp, zaś klasa gadająca z bazą danych niech umożliwi łatwe wydobywanie typowych odpowiedzi, jak np "podaj mi utwory z albumu o tej nazwie, tego artysty", "podaj mi utwory pasujące do tego wyrażenia regularnego", itd. Wypełniam brakujące miejsca, po drodze uruchamiając klasę w IPythonie (polecenie "%run ./plik.py") i na bieżąco dokonując poprawek, jeśli pojawiają się gdzieś nieoczekiwane zachowania (bo moje programy nie mają błędów - po prostu robią czasem nie do końca to, co myślałem, że zrobią :P). Jeśli wszystko zostało dobrze zaprojektowane, każdy z tych niskopoziomowych modułów będzie można uruchomić niezależnie od pozostałych, pobawić się nim trochę, być może też już teraz potrafi zrobić coś pożytecznego...

5. Gdy bardziej niskopoziomowy moduł jest gotowy, zaczynam tworzenie kolejnej warstwy - na przykład playlista. Playlista będzie prostą klasą, jej interfejs będzie uwzględniał takie metody jak "następny utwór", "jaka jest pozycja bieżącego utworu", "dodaj utwór do końca listy", "podaj mi listę utworów", "zapisz się do pliku", itp. Jest to design tz. "inside out" - zaczynamy od niższych warstw, i na nich budujemy wyższe (Eric Raymond chwali ten sposób designowania w swej książce, "The Art of Unix Programming"). Na tym poziomie już zazwyczaj nie ma co zdzierać z istniejących projektów - trzeba po prostu pomyśleć i pogłówkować, zaprojektować tej playliście interfejs, który ładnie będzie można owinąć w buttony i listboxy, albo wygodnie obsługiwać wklepując komendy z terminala. Jeśli wszystkie niskopoziomowe moduły działają jak należy, napisanie takiej klasy - playlisty to niemal formalność. W razie potrzeby tworzymy też kolejne przewidziane moduły i przygotowujemy je tak, aby np. odpowiedzi z bazy danych nie wymagały specjalnej obróbki przed dodaniem do listy (np. na zapytanie "daj mi wszystkie utwory wszystkich artystów, którzy wydali płytę w 1988 roku" baza odda długą listę obiektów typu "utwór", którą to listę będzie można podać jako argument do metody "dodaj utwory do końca playlisty").

6. Interfejs użytkownika. Tutaj trzeba dokładnie się zastanowić, jak go zaprojektować, aby użytkownik nas za niego nie znienawidził. Jeśli to ma być ów commandlinowy odtwarzacz, trzeba rozważyć podział programu na klienta i serwer - klient będzie jedynie wysyłał pytania do serwera i wyświetlał odpowiedzi. Można na przykład dać takie opcje: "musicclient --play-or-pause", "musicclient --next", "musicclient --append ~/music/Britney\ Spears/", itd - ale użytkownik znienawidzi interfejs, w którym musi za dużo pisać (albo szybko porobi sobie aliasy). Zamiast tego można rozważyć np. takie opcje: skrócić nazwę binarki klienta do jednej-dwóch liter, i następnie jednej litery oznaczającej komendę, np. "mcp" jako "play/pause", "mcn" jako "next", "mca" jako "append", i następnie porobić symlinki z takimi nazwami i niech program sprawdzi swą nazwę w argv[0] (aczkolwiek ludzie w książce "Unix Haters' Handbook" nie wyrażali się o tej praktyce zbyt pochlebnie). Kolejna opcja to zrezygnować z pojedynczych wywołań klienta z linii poleceń, i zrobienie coś w rodzaju prostej powłoki, z własną składnią, dopełnianiem, historią, itp (można użyć modułu cmd i readline). Ale tutaj też trzeba spojrzeć, czy użytkownik raczej będzie wydawał rzadkie pojedyncze komendy, czy raczej woli podumać nad playlistą, powrzucać kilka kawałków, po czym przełączyć okno w screenie. Jeśli zdecydowałbym jednak na tworzenie aplikacji w GUI - niech obsługą interfejsu zajmie się osobny wątek (hurra synchronizuj teraz ten shit >_<). Innymi słowy - trzeba pokombinować co będzie wygodne, i jakie rozwiązania będą najlepsze. Dlatego interfejs tworzę zawsze na samym końcu - jeśli jeden nie wyjdzie, łatwo go wywalić i wstawić inny. Gorzej by było, gdyby np. sposób w jaki działa obiekt-playlista zależał od sposobu, w jaki działa interfejs - co w przypadku projektowania "outside in" (skrytykowanym przez Raymonda, dominującym w środowisku programistów Maców) spowodowałoby małą katastrofę.

7. Powinno grać :)

W skrócie:
1. Zbierz ideę do kupy, dowiedz się co ma robić program a czego nie.
2. Podziel problem na mniejsze problemy, wiążące się ze sobą.
3. Dobierz narzędzia, które ułatwią ci rozwiązywanie najdrobniejszych problemów.
4. Znajdź kolejne gotowe rozwiązania i dostosuj je. Zacznij rozwiązywać pozostałe najdrobniejsze, niskopoziomowe problemy.
5. Gdy wszystkie małe problemy składające się na duży problem zostaną rozwiązane, rozwiązanie dużego problemu jest formalnością.
6. Dopero wtedy ubierz to w interfejs, za który ludzie cię nie znienawidzą.
7. Powinno grać :)


Aczkolwiek, sądzę że dla pewnych szczególnych przypadków ten sposób designowania nie zawsze jest idealny. Jeśli założeniem projektu jest stworzenie konkretnego interfejsu użytkownika, trzeba wygląd i semantykę tego interfejsu opracować na samym początku - potem zaś zacząć budować warstwy od dołu, tak, aby najwyższa z nich ładnie "wpasowała" się w UI. Jeśli opracowywany system wśród swoich założeń ma minimalizację ilości i grubości owych warstw i modułów (np. specjalny interpreter Pythona bootowalny bezpośrednio z GRUBa, bez udziału żadnego kernela (nawet był taki projekt - Cleese)), trzeba kombinować, jak pominąć istniejące dotychczas warstwy. Jeśli tworzymy NAPRAWDĘ wielkie bydle, np. system operacyjny, trzeba jeszcze przed napisaniem "sterownika" konsoli tekstowej wiedzieć, czy interesuje nas zgodność z posixem. Itd.



Mam też drugi sposób designu, zwany LJOEASWC ("let's just open emacs and start writing code"). Dla wielu projektów okazuje się doskonały, lecz zazwyczaj są to te, które nie mają przekroczyć parudziesięciu linijek. ACZKOLWIEK. Jedną moją grę zacząłem właśnie w ten sposób - zanim pierwszy raz ją spróbowałem uruchomić, miałem już około 600 linijek bardzo ładnego, ustrukturyzowanego i modularnego kodu - i o dziwo, bezbłędnie działającego o_0 potem przełączyłem się na "incremental development" - dodaję trochę, odpalam, oglądam, wracam do edytora, poprawiam znów trochę, i tak w kółko. I o dziwo, dopiero wtedy zaczęły się pojawiać bugi... (nad jednym siedziałem dwa dni, a wiązał się z nieodpowiednią kolejnością update'owania kamer i reszty obiektów w ramach jednej klatki, co prowadziło do bardzo brzydkich efektów). Gra ma obecnie 1000 linii, jest po przeniesieniu większości statycznej, początkowej zawartości do plików z resourcami, i w trakcie dodawania obsługi multiplaya - i na tym stanęła, i nie da się jej uruchomić ani w trybie single ani w multi, bo straciłem zainteresowanie projektem :)



Oczywiście na wszelkie moje porady radzę szczerze - patrzeć krytycznym okiem :P faktem jest, iż jak do tej pory żadnego większego projektu nie ukończyłem. Zazwyczaj gdy zaczyna już stać na własnych nogach, nagle odkrywam nową, niezwykłą, ekscytującą gałąź Computer Science i rzucam wszystko wpi, by np. zacząć tworzyć własny interpreter Lispa (: i gdy po wpisaniu (+ 2 2) na ekranie pojawia się 4, w tym momencie zaczynam tworzyć klona GTA2... I tak w kółko.

Dopełniając dość obszerny opis harrego666t zainteresuj się dziedziną informatyki jaka jest Inżynieria oprogramowania , która właśnie opisuje cały proces produkcji oprogramowania i skupić się na UML ( najlepsze narzędzie to Rational Rose lecz niestety płatny choć sa triale i są tez inne narzędzia opensourcowe lecz co tu pisac nie podskakują do pięt) czy wzorcach projektowych dobra książka przetłumaczona w polsce jest "Wzorce projektowe"autorstwa Gamma Erich, Helm Richard, Johnson Ralph, Vlissides John. Jest to bardzo rozległa dziedzina a i dość ciekawa.

Ostatnio edytowany przez ba10 (2008-10-07 09:05:50)

czadman napisał(-a):

W sumie to znalazłem jakiś plugin do eclipse pyUML, cza obczaić. Takie to eclipse wychwalane to może do uml się przyda. ;)

spe tez ma UML (cokolwiek to jest)

Jakbym troche poszperał w poczcie to pewnie bym coś znalazł z inżynierii oprogramowania - jak ci to interesuje to daj znać. Chociaż z tego co pamiętam wartościowe materiały mam w formie papierowej

Ostatnio edytowany przez guzzi (2008-10-06 14:28:08)

guzzi napisał(-a):

Jakbym troche poszperał w poczcie to pewnie bym coś znalazł z inżynierii oprogramowania - jak ci to interesuje to daj znać. Chociaż z tego co pamiętam wartościowe materiały mam w formie papierowej

Czadman ja mam gdzieś wykłady w wersji elektronicznej jeśli jesteś zainteresowany moge podesłać na maila.
Możesz tez spróbować Poseidona całkiem nieźle się prezentuje, jest chyba jakaś darmowa wersjia tylko trzeba się zarejestrować i sie otrzymuje klucz. Jest też jakiś plugin Appolo do Eclipse od Poseidona. Co do Umbrello bawiłem kiedyś tym i jednak był ten program za słabo rozwinięty ( brakowało sporo diagramów) ale to było dawno ( jakieś 1,5 roku temu) więc mogło się dużo zmienić.

Ostatnio edytowany przez ba10 (2008-10-07 09:13:46)