Jak ważna jest modularyzacja projektów oprogramowania

Question

Modularyzacja jest oczywiście ważna w projektach programistycznych, ale chcę poznać opinie użytkowników na temat , jak ważne są i dla których ważne jest, aby powód. Oczywiście mam własne pomysły, ponieważ o to pytam, ale myślę o tym jak o "wspólnej burzy mózgów" z powodów, dla których należy modularyzować swoje projekty programowe ...

Answer 1

Moje główne powody umieszczania kodu w różnych modułach :

• Oddzielenie obawy: czuję, że łatwiej jest ograniczyć wiedzę o wewnętrznych zajęć na różnych poziomach lub z różnymi zadaniami, jeśli są one zorganizowane w oddzielnych modułach. Po prostu bardziej "brudne" jest poleganie na elementach wewnętrznych, jeśli są dobrze ukryte.
• Łatwiejsze w utrzymaniu mniejsze komponenty: Zazwyczaj środowisko programistyczne jest bardziej elastyczne, jeśli pracuję nad projektem z mniejszą liczbą plików kodu, niż w przypadku, gdy projekt zawiera setki i setki plików.
• Zapobieganie zderzeniom przestrzeni nazw: Po prawidłowej modularyzacji, np. używając przestrzeni nazw w Javie, możesz mieć tę samą nazwę funkcji dla tej samej funkcjonalności bez obawy, że funkcja printout() w komponencie Foo będzie kolidować z funkcją printout() w komponencie Bar.
• Rozdzielenie problemów związanych z bezpieczeństwem: Łatwiej jest zminimalizować potencjalne uszkodzenia, gdy jeden komponent wchodzi na palce innego komponentu. W zależności od używanej technologii można ograniczyć lokalizację każdego modułu w pamięci.

Answer 2

Myślę, że jednym z głównych aspektów jest ponowne użycie. Kiedy budujesz moduły, nie ma takich rzeczy jak: "Och, już to zrobiłem, ale żeby go użyć, będę musiał również uzyskać tę i tę funkcjonalność, która nie ma absolutnie nic wspólnego z moją aplikacją".

Ponadto, łatwiej jest zrozumieć, . Nie mogę zachować ton rzeczy w moim umyśle w tym samym czasie. Kiedy kod jest modułowy, łatwiej jest ustalić "obszar" rzeczy, które same w sobie są sensowne. A kiedy ten obszar jest zwykle mały, mogę go zrozumieć jako całość, a nie jego fragmenty.

Wreszcie, gdy rzeczy są mniejsze, jest łatwiej przetestować i utrzymać. Ponadto, twoje testy wskazują szybciej, gdzie występuje błąd, po przetestowaniu tylko niewielkiej części aplikacji.

Answer 3

My, ludzie, jesteśmy ograniczeni, jeśli chodzi o uchwycenie złożonych problemów naraz. Jednak jesteśmy zdolni do rozłożenia złożonego problemu na (prawdopodobnie bardzo dużą) liczbę indywidualnych problemów, które nie są zbyt skomplikowane, aby poradzić sobie z dużym problemem.

Zasadniczo stanowi to odpowiedź na pytania typu "ponowne użycie", "oddzielenie spraw", "łatwiejsza konserwacja".

Wszystkie te powody są prawdziwe, bez względu na to, czy to jedna osoba załamuje skomplikowany problem, by poradzić sobie z nim pojedynczo, czy też jest to zespół ludzi, którzy dzielą go, by rozłożyć złożoność.

Answer 4

Modularization i oddzielenie są ważne z wielu powodów, niektóre z nich są:

• Reuse: Jest to znacznie łatwiejsze do ponownego użycia moduły programowe, które są dedykowane do konkretnych celów
• Zarządzających Złożoność: Praca na oddzielone od produkcji modułów (pisanie kodowanie, debugowanie, utrzymywanie itd.) pozwala skupić się na pewnym problemie domeny, bez rozpraszania się przez inne aspekty aplikacji lub systemu oprogramowania.

Answer 5

może być również traktowana jako podstawowy aktywności Application Architecture których:

• zajmuje pewien obiekt funkcjonalne specyfikacji
• i grupę głównych funkcji do aplikacji podczas identyfikacji modułów niefunkcjonalne i czystych techniczne moduł poprzeczny

Dlatego właśnie "obliczenia portfela finansowego" zostaną podzielone na:

• moduł obliczeniowy
• moduł wysyłający (ponieważ portfel jest zbyt duży, aby być obliczane na jednym serwerze)
• moduł uruchamiający (pilotować wszystkie obliczenia)
• GUI (aby zobaczyć, co faktycznie dzieje)

Plus kilka poprzecznych nich:

• KPI rejestrowania
• zarządzanie Wyjątek

W leczeniu tego rodzaju wymogu funkcjonalnego jako jeden duży moduł monolitycznej zmusi rozwój wdrożyć wszystkie sub-rutyny w kolejności jak wszyscy.
Podczas gdy dzięki przejrzystej architekturze aplikacji można rozpocząć pracę nad bardziej ogólnymi i poprzecznymi modułami, a jednocześnie udoskonalić inne bardziej biznesowe moduły.

Zmusza również zdefiniowanie więcej interfejsów i analiza wzajemnych komunikacji wydaje się swoimi różne moduły będą musieli rozwiązać (bezpośredni autobus ?, n-do-n typologia ...?)