Czy ponowne użycie jest w przybliżeniu synonimem dobrego projektu?

Wielokrotnego użytku jest cechą dobrego projektowania oprogramowania .

Czy ponowne użycie jest akceptowalnym połyskiem („krótki zapis znaczenia”) dla dobrego projektowania oprogramowania? Dlaczego?

Nie.

Ponowne użycie jest wskaźnikiem dobrego projektu. Wskazuje, że sprzężenie systemu jest wystarczająco luźne, a spójność konkretnej jednostki jest wystarczająco wysoka, aby ułatwić ponowne użycie bez problemów związanych z zależnościami lub konieczności przepisania większości kodu.

Ponowne użycie jest w dużej mierze iluzją. Jest możliwe do zweryfikowania, że ​​nie można zmierzyć „możliwości ponownego użycia” urządzenia, nie wiedząc z góry, gdzie i jak będzie ono używane. Wielu programistów będzie próbowało zaprojektować komponenty „wielokrotnego użytku” i często dowiaduje się później, że konkretne aspekty, które starali się uczynić „elastycznymi”, były dokładnie tymi, które nie musiały być.

Użyłbym innego „połysku”: Testowalność.

Teraz nie jestem orędownikiem TDD, ani nie czuję potrzeby testowania jednostkowego czegokolwiek i wszystkiego. Ale pisanie testów dla komponentu daje bardzo dobre wyobrażenie o jego właściwościach sprzęgania / kohezji i to bardzo szybko. Jeśli zależy to od abstrakcji, to jest to luźne połączenie; przekonasz się o zależnościach, co sugeruje dobry projekt. Jeśli ma wyraźny cel (patrz także Zasada pojedynczej odpowiedzialności ), wówczas jego zachowanie będzie względnie intuicyjne, łatwo będzie ci się dowiedzieć, co przetestować, co ponownie sugeruje dobry projekt.

To oczywiście nie gwarantuje dobrego projektu; faktyczna implementacja lub nawet cała architektura może być całkowicie nieodpowiednia do określonego celu. Ale przynajmniej mówi ci, że nie pracujesz z kodem spaghetti lub God Objects.

Proszę, nie próbuj zgadywać, co do „możliwości ponownego użycia” danego elementu, zwłaszcza nie używaj go jako dowodu „dobrego projektu”. Jest to coś, co można ustalić tylko z perspektywy czasu, gdy zostanie ono ponownie wykorzystane, a do tego czasu projekt mógł się znacznie zmienić.

Nie.

Wielokrotnego użytku jest dobrą cechą, ponieważ może przyspieszyć przyszły rozwój. (Chociaż w praktyce bardzo niewiele organizacji uważa, że ​​przyszły rozwój jest przyspieszany prawie tak, jak się spodziewali). Jednak każde znaczące oprogramowanie zawiera części specyficzne dla tej aplikacji. Co więcej, gdy ludzie bez doświadczenia w domenie próbują napisać oprogramowanie wielokrotnego użytku, zwykle zaciemniają ten kawałek i zmniejszają wydajność bez faktycznego udoskonalenia go.

Dlatego dobry projekt ma budowę modułową i nadaje się do wielokrotnego użytku tylko wtedy, gdy widać, że element może być ponownie użyty, i gdzie masz wiedzę specjalistyczną, aby faktycznie wykorzystać go ponownie. Gdzie indziej powinieneś postarać się, aby wszystko było czyste, ale nie martw się o możliwość ponownego użycia. (Z wyjątkiem tylnej części głowy, gdzie robisz notatki, abyś w jakimś przyszłym systemie miał pomysł, jak zrobić to wielokrotnego użytku).

Wierzę (i to jest moje osobiste przekonanie), że związek między możliwością ponownego użycia a dobrym projektem nie jest zwrotny, więc podstawowa i prosta odpowiedź brzmi „ nie” . Jeśli interesują Cię dobre przewodniki po projektowaniu, sprawdź ten artykuł w Wikipedii.

Dobry projekt oprogramowania musi nadawać się do ponownego użycia, przynajmniej w niektórych podstawowych częściach. Myślę, że bardzo niewiele osób faktycznie używa kodu źródłowego, ponieważ bardzo skomplikowane jest zaprojektowanie rdzenia systemu tak, aby nadawał się do wielokrotnego użytku w wielu różnych kontekstach (I mówię to z doświadczenia)

Zastanów się nad klasą z ogromną odpowiedzialnością (znaną również jako Blob), która dobrze wykonuje wszystkie zadania, których potrzebujesz, ale bez żadnych rozważań projektowych, być może widziałeś już przypadek. Większość ludzi z taką klasą używałaby go w kółko i myślę, że będziemy musieli zgodzić się, że to ponowne użycie, ponowne użycie bez projektu.

Mam nadzieję, że nie zepsułem zbytnio moich wyjaśnień

Myślę, że lepszym wskaźnikiem dobrego projektu jest przestrzeganie podstawowych idei, takich jak zasada pojedynczej odpowiedzialności i utrzymanie spójności każdego elementu. Używając abstrakcji z przejrzystym i zwięzłym interfejsem oraz zachowując zgodność z zasadą substytucji Liskowa , zachęcamy do ponownego użycia, nie próbując przewidzieć, co będzie, a co nie będzie ponownie wykorzystane.

Przestrzeganie tych podstawowych zasad projektowania ułatwia testowanie kodu i ponowne użycie.

Dobry projekt == dobry projekt, możliwość ponownego użycia jest produktem ubocznym.

Ponowne użycie jest często domyślnym celem projektu. Jeśli możesz stworzyć komponent lub cały projekt w taki sposób, aby można go było ponownie wykorzystać później, wydaje się oczywiste, że powinieneś to zrobić. Nie zawsze oczywiste jest, że wykonanie czegoś wielokrotnego użytku może zająć dużo czasu i wysiłku (i pieniędzy), dlatego też korzyść z ponownego użycia musi zostać porównana z jego kosztem.

Projekt wielokrotnego użytku, który kosztuje dwa razy więcej i / lub zajmuje dwa razy więcej czasu niż jest to potrzebne klientowi, nie jest dobrym projektem z perspektywy klienta, szczególnie jeśli klient nie potrzebuje ponownego użycia.

Istnieje wiele podobnych atrybutów, które często uważa się za dorozumiane cele projektowe, ponieważ wydają się one oczywiście dobre:

• minimalizacja kosztów

• minimalizowanie czasu rozwoju

• minimalizowanie złożoności

• maksymalizacja niezawodności

Wszystkie te rzeczy są obiektywnie dobre, ale nie zawsze mogą być ważne dla konkretnego klienta w określonym czasie, dlatego ważne jest, aby w pełni zrozumieć, czego potrzebuje Twój klient (nawet jeśli ten klient jest tylko twoim szefem). Istnieje wiele aforyzmów, które mają nam przypominać o tym fakcie (np. „Gotowe jest lepsze niż idealne” i „Dobry, tani, szybki: wybierz dowolne dwa”), ale nadal łatwo wpaść w pułapkę próby tworzyć oprogramowanie, które jest świetne pod każdym względem, a tak naprawdę świetne pod każdym względem nie zawsze jest potrzebne.

Aby przejść do pytania tytułowego: Nie , ponowne użycie nie jest synonimem dobrego projektu. Wielokrotnego użytku może być użytecznym elementem konkretnego dobrego projektu, ale tylko wtedy, gdy jest to wymagane.

Niekoniecznie. Jeśli zrobisz coś wielokrotnego użytku, które najwyraźniej nigdy nie będzie ponownie użyte, to zły projekt.

Na przykład, jeśli piszesz plik pełen danych, który jest unikalny dla Twojej firmy, a dane te mają zostać zaimportowane raz w inne miejsce, po co męczyć się, aby można je było ponownie wykorzystać?

To powiedziawszy, jeśli twój framework jeszcze go nie ma, kod do zapisu do pliku może wymagać ponownego użycia. To byłby dobry projekt.

Powiedziałbym „nie”, głównie dlatego, że opisuje tylko mały segment kodu. Przekonałem się, że użyteczność jest najważniejsza w samym centrum i na zewnętrznych krawędziach obszaru użyteczności, a nie pomiędzy nimi. Podam kilka przykładów rzeczy, w których moim zdaniem ponowne użycie jest użytecznym miernikiem jakości projektowania.

Podstawowe rzeczy

• Szablony formularzy internetowych, które umożliwiają łatwe i spójne dodawanie strony (lub dowolnego interfejsu użytkownika)
• Pomocniki wzorców projektowych, takie jak podstawowa klasa ViewModel, które zostaną uwzględnione we wszystkich moich aplikacjach MVVM

Rzeczy użytkowe

• Klasa e-mail, która wysyła wiadomość SMTP (używaj jej cały czas)
• Klasa kalkulatora odległości GIS (używana w wielu naszych aplikacjach)

W przypadku elementów CRUD, które zajmują 70–80% większości aplikacji, po prostu nie sądzę, aby ponowne użycie było w ogóle cennym miernikiem.