Jak powinienem zaplanować swoją bazę kodu? [Zamknięte]

Obecnie pracuję nad projektem, który ma osiągnąć ponad 5000 wierszy kodu, ale tak naprawdę nigdy nie do końca przemyślałem projekt. Jakich metod należy użyć, aby ustrukturyzować i zorganizować kod? Papier i długopis? Diagramy UML? Coś innego?

Prawdopodobnie masz tyle różnych poglądów, ile będzie odpowiedzi. Ale oto moja perspektywa.

Na początek 5000+ linii kodu jest bardzo małym projektem. Jak teraz zajmujesz się projektowaniem projektów, które rosną. Po pierwsze, projektujesz swój system, a nie kod. Kod jest właściwie drugorzędny w stosunku do architektury. Zacznij od obsługi minimalnych wymagań prądu. Umieść uproszczony rysunek komponentów. Osobiście lubię UML, ale wszystko co wizualne będzie dobre. Najlepiej, jeśli chcesz przestrzegać dobrych praktyk projektowych (interfejsy, separacja problemów itp.).

Gdy spełnisz minimalne wymagania w swoim projekcie, koduj go. Ponownie spróbuj zastosować dobre praktyki kodowania.

Następnie iteracyjnie dodaj więcej funkcji, gdy pojawią się nowe wymagania. Idealnie chcesz również zaktualizować swój projekt.

Na podstawie mojego doświadczenia ważne jest, aby nie projektować systemu w oczekiwaniu na nieistniejące wymagania. W przeciwnym razie Twój projekt będzie rozwijał się bardzo szybko i stanie się bardzo złożony w krótkim czasie. Ponownie - przestrzegaj dobrych praktyk i zacznij od konkretnych bieżących wymagań.

Diagramy przepływu, diagramy klas, diagramy przypadków użycia to diagramy obowiązkowe dla dużych projektów. Wyszukaj i wybierz potrzebne biblioteki zewnętrzne oraz wyszukaj podobne kody open source, których możesz użyć (aby nauczyć się i skrócić czas opracowywania).

Sugeruję, abyś kupił białą tablicę oraz kolorowe magnesy i post-it. Pomoże ci to zidentyfikować twoje zadania.

PS 5000+ linii kodów nie są jednak „duże”. Oprogramowanie CMS / Forum ma ponad 5000 linii kodów.

Chciałbym tworzyć diagramy pakietów i klas. Na schemacie pakietów chciałbym grupować klasy i interfejsy w sposób logiczny. Chciałbym również stworzyć pakiety wewnętrzne itp ...

Ale najpierw musisz pomyśleć, co powinien zrobić program. Możesz tworzyć diagramy przypadków użycia lub robić to ręcznie. Robię to ręcznie za pomocą diagramu klas, ponieważ wolę natychmiast uzyskać kod, a później łatwiej jest zamienić na pakiety diagramów klas. Korzystanie ze schematu klas daje mi java. Jeśli mi się nie podoba, to ręcznie go zmieniam. Nowy kod jest automatycznie aktualizowany do moich diagramów. Mam wizualnie zaktualizowaną reprezentację mojego kodu na wysokim poziomie. Naprawdę pomocne, ponieważ nawet jeśli koduję, zawsze mogę poświęcić kilka minut na graficzne spojrzenie na mój projekt. Po prostu ręcznie przeciągam i upuszczam elementy w odpowiednim pakiecie, aby go uporządkować. Myślę, że mój kod jest lepszy przy użyciu wyższego poziomu pakietu abstrakcji i diagramów klas.

_{(źródło: ejb3.org )}

niektórzy z moich kolegów powiedzieli, że mój sposób pracy to bzdury .... ale podoba mi się to :-)

Zdecydowanie. Mam małą tabliczkę suchościeralną „tablet”, której można używać do tego rodzaju rzeczy, ale używaj wszystkiego, co ci odpowiada. Ważne jest to, że możesz łatwo sprowadzić myśli i zobaczyć duży obraz tego, jak wszystko do siebie pasuje.

Niektórzy ludzie wolą bardziej formalne plany, takie jak diagramy UML, ale uważam, że zbyt łatwo jest przyłapać się na mikromanowaniu, jak powinna wyglądać każda metoda. Ponownie jednak skorzystaj z tego, na co masz ochotę.

EDYCJA: Być może zainteresuje Cię także umiejętność programowania . Chodzi o to, że możesz wszystko zaplanować i stopniowo uszczegółowić. Na przykład możesz powiedzieć, że twój program składa się z:

1. Pobieranie wiadomości od użytkownika
2. Konwertowanie tekstu na obraz
3. Zapisywanie powstałego obrazu na dysku

Następnie możesz zawęzić pomysł przekształcenia tekstu w obraz. Może to wyglądać następująco:

1. Określ liczbę wierszy, które powinien zająć tekst
2. Wybierz losowe kolory tekstu i tła
3. Przetwarzaj w odpowiednim formacie

Następnie możesz dopracować pomysł wybierania losowych kolorów, a wkrótce po prostu piszesz zwykły kod.

Dla mnie działalność związana z tworzeniem oprogramowania to seria coraz bardziej drobnoziarnistych projektów mających na celu rozwiązanie konkretnego problemu. Kiedy masz ogólne wyobrażenie o tym, co budujesz, twój projekt może być czymś bardzo wysokim, na przykład „będzie aplikacja internetowa, która komunikuje się z bazą danych SQL i wieloma usługami internetowymi” lub coś w tym rodzaju. Następnie, gdy wiercisz szczegóły każdego elementu, zyskujesz bardziej drobnoziarnisty wygląd. W zależności od złożoności rozwiązania będzie mniej lub więcej iteracji prac projektowych. Ostatnia iteracja polega na utworzeniu rzeczywistego kodu, który implementuje wyższe poziomy projektu.

Dla mnie różnica między architekturą a projektowaniem jest minimalna, a są to po prostu różne iteracje opisanego powyżej procesu. Linia między nimi jest rozmyta i różna dla różnych osób.

Istnieje umiejętność decydowania, na jakim poziomie szczegółów projektowych należy przejść, dla jakich części aplikacji i w jakich momentach cyklu życia projektu. W przypadku projektów o wysokim ryzyku i dużej złożoności możesz chcieć mieć bardzo szczegółowy projekt, zanim napiszesz wiersz kodu. W przypadku mniejszych projektów możesz oderwać się od robienia bardzo niewielkiego projektu i po prostu wymieszać trochę kodu, a następnie zobaczyć, co nie działa i przeprojektować te obszary. Tutaj nie ma tylko jednej odpowiedzi. Zwykle jest gdzieś pomiędzy tymi dwoma skrajnościami.

Mam wpis na blogu, który mówi o niektórych zasadach, które stosuję, gdy zbliżam się do architektury. Może ci się przydać myślenie w tym kierunku. Niektóre artykuły są specyficzne dla platformy .NET, ale większość z nich nie jest.

Zadawałem sobie to samo pytanie. Teraz po prostu ćwiczę programowanie oparte na testach i nie przejmuj się tym. W ogóle nie „planuję” kodu, poza przestrzeganiem standardów dla wybranej architektury. Kiedy rozpoczynam projekt, mam pojęcie o tym, co będzie potrzebne, ale w miarę rozwoju prac staram się zachować otwarty umysł. Śledząc rozwój oparty na testach i ciągle zmieniając kod, nie muszę „planować” kodu. Po prostu spełniam jeden przypadek testowy po drugim, a projekt wyłania się z refaktoryzacji. Jest to zawsze lepszy projekt niż jakiekolwiek plany, które mogłem zrobić przed kodowaniem.