Czy podczas projektowania systemu najlepszą praktyką jest dostosowanie projektu do środowiska, którego będziesz używać?

Przy opracowywaniu systemu lub aplikacji, której planujesz używać z określonym frameworkiem, najlepiej jest zaprojektować system bez uwzględnienia frameworka, czy lepiej jest zaprojektować system z nastawieniem „cóż, frameworki byłyby łatwiejsze z tym".

development-process systems

— Robert Pounder
źródło

O jakim frameworku mówisz? Czy masz na myśli jakąś niszową platformę biznesową, która ma na celu rozwiązywanie bardzo specyficznych problemów domenowych dla konkretnej branży? (np. medyczny, nuklearny, obronny, lotniczy itp.). A może mówisz o ramach ogólnego przeznaczenia zaprojektowanych w celu rozwiązywania problemów technicznych?

— Ben Cottrell,

frameworki ogólnego przeznaczenia zaprojektowane w celu rozwiązywania problemów technicznych

— Robert Pounder

Mała skala z powodu braku czasu (jestem w pracy, może rozwinąć się później): Piszę system, który generuje e-maile na podstawie projektów. - Gdybym to pisał w Laravel, prawdopodobnie użyłbym ich „ostrza” silnika szablonów do projektowania wiadomości e-mail, co znacznie uprościłoby projektowanie systemu. Musiałbym jednak zająć się pisaniem silnika szablonów, gdybym robił to waniliowy PHP lub znajdowałem inny odpowiedni alternatywny system szablonów. Zwiększyłoby to proces projektowania, do którego odnosi się również pytanie.

— Robert Pounder,

To pytanie wygeneruje szereg bardzo różnych odpowiedzi, ponieważ zarówno „framework”, jak i „design” to słowa przeciążone wieloma znaczeniami w naszej branży. Co więcej, nawet w przypadku jednej definicji ram jako „ram ogólnego przeznaczenia zaprojektowanych w celu rozwiązania problemów technicznych”, będzie to zależeć od konkretnych ram - niektóre ramy są bardziej opiniotwórcze niż inne.

— stannius

Szkoda, by autobus został potrącony w zamyśleniu podczas próby zaprojektowania kołowego pojazdu transportu publicznego.

Odpowiedzi:

Twój projekt powinien jak najlepiej zaspokajać potrzeby klientów. Pamiętaj, że projekt obejmuje małe rzeczy, takie jak:

Doświadczenie użytkownika
Funkcjonalność
Jak komunikują się fragmenty twojej aplikacji (ze sobą samym lub podmiotami zewnętrznymi)

Żadna z tych rzeczy nie powinna być podyktowana przez ramy. Jeśli jasne jest, że będziesz walczył ze swoim frameworkiem, aby osiągnąć te cele, wybierz nowy framework, który pomoże ci osiągnąć te cele, zanim zaczniesz pisać kod.

Po wybraniu odpowiedniego zestawu narzędzi (struktura jest narzędziem), zalecam korzystanie z narzędzi w sposób, w jaki zostały zaprojektowane. Im bardziej odejdziesz od projektu frameworka, tym bardziej zwiększasz krzywą uczenia się dla swojego zespołu i tym większa szansa, że coś pójdzie nie tak.

W skrócie

Projekt dla Twoich użytkowników
Wybierz odpowiednie narzędzia do wykonania swojego projektu
Używaj narzędzi w sposób, w jaki zostały zaprojektowane

Dalsze myśli:

Po ponad 20 latach inżynierii oprogramowania i korzystaniu z kilku platform, nauczyłem się kilku lekcji. Wszystkie ramy są obosiecznym mieczem: oba ograniczają i umożliwiają. Problemem przy podejmowaniu decyzji o swoim frameworku przed spojrzeniem na wielką 3, o której wspomniałem powyżej, jest to, że możesz narazić na szwank dobre wrażenia użytkownika dla przeciętnego (w najlepszym przypadku). Lub możesz być zmuszony do odejścia od projektowania frameworków, aby osiągnąć określoną funkcjonalność.

— Berin Loritsch
źródło

Następnie musisz przeprowadzić negocjacje z klientem. Wyjaśnij, co możesz, a czego nie możesz zrobić, z nałożonymi przez nie ograniczeniami. Zaproponuj, jak to może się zmienić, jeśli wybierzesz platformę X. Mogą nie być skłonni do zmiany i są gotowi żyć ze zdegradowanym doświadczeniem. Lub mogą zdecydować, że wiesz, co robisz i zaufać ci. To zależy od klienta. Na koniec dnia radzisz sobie z ich oczekiwaniami.

— Berin Loritsch

Wydaje się, że istnieje pewne zamieszanie między różnymi poziomami projektowania: projekt systemu i projekt szczegółowy. Dla mnie to pytanie dotyczyło szczegółowego projektu (metody implementacji), a nie systemu (interfejsy, współbieżność, ilość danych, interfejs użytkownika, typ użytkownika).

— Gusdor,

Jeśli pytanie dotyczy „projektu technicznego”, wówczas język i system operacyjny mogą mieć pewne wnioski w projekcie. Ale projekt nie jest implementacją. Jeśli myślisz o możliwościach Frameworka, to nie jest projekt, to implantacja. Jeśli opierasz swoje decyzje projektowe na mocnych ramach, przygotuj się na cierpienie jego słabości. A kiedy słabość spełnia wymagania, masz ogromny problem. Największe firmy nie budowały własnych ram dla przyjemności.

— Laiv

@Laiv Świetny komentarz! Naprawdę jest to „niektóre i niektóre”. Pistolet do paznokci i śrubokręt mogą zarówno mocować rzeczy, jedna jest bardziej odwracalna od drugiej, a także działa wolniej i jest bardziej złożona. Każdy wybór dokonywany przez ludzi jest nieuchronnie kompromisem. Płacisz pieniądze i ryzykujesz.

@RobertPounder, jest to narzędzie, które należy ustalić przy projektowaniu systemu pod kątem stosowności rozwiązania . Rozumiem, w jaki sposób ramy mogą wpływać na projekt, ale nie powinny tego dyktować.

— Berin Loritsch,

Szkielety w naturalny sposób wpływają na projektowanie określonych modułów i podsystemów (takich jak interfejs GUI). Jak wspomniano w innej odpowiedzi, będziesz miał trudności z walką z wybranymi przez siebie ramami.

Mówiąc bardziej ogólnie, powinieneś unikać pozwalania, aby jakakolwiek pojedyncza platforma lub technologia dyktowała lub kierowała „szerokim obrazem” całej architektury systemu. Większość frameworków aplikacji ogólnego przeznaczenia nie zachęca do tego, więc jeśli okaże się, że piszesz cały system wokół jednego frameworka, prawdopodobnie robisz coś, czego nie zamierzali autorzy tego frameworka.

Prawdopodobnie użyjesz wielu różnych ram do rozwiązania różnych problemów; gdy twój system staje się bardziej złożony, musisz uważać, aby nie zbudować The Big Ball Of Mud . Tam, gdzie to możliwe, utrzymuj swój system modułowy i luźno powiązany. Niektóre frameworki można lepiej ukryć za abstrakcjami, pisząc opakowania i adaptery, które „ukrywają” przepływy pracy specyficzne dla frameworka przed innymi komponentami. Zestawy narzędzi GUI zwykle obsługują tylko front-end GUI, więc te moduły GUI powinny być trzymane z dala od reszty systemu.

Struktury ogólnego przeznaczenia (takie jak frameworki interfejsu użytkownika, frameworki warstwy danych itp.) Nie istnieją w celu opisania pełnej architektury systemu - co najwyżej mogą zalecić projekt komponentu lub modułu; na przykład niektóre technologie GUI są ukierunkowane na określone wzorce MV *.

Ogólna architektura systemu powinna wynikać przede wszystkim z wymagań biznesowych . Możesz mocno opierać się na konkretnym narzędziu (na przykład narzędziu do przesyłania wiadomości lub oprogramowaniu ORM) w celu powiązania wszystkiego, ale jeśli obudowałeś środowisko abstrakcyjne, takie jak klasa „usługowa”, jest mniej prawdopodobne, że napotkają ograniczenia, gdy napotkasz jego ograniczenia.

Podczas projektowania dużego obrazu staraj się pamiętać o następujących kwestiach:

Cel budowy oprogramowania modułowego
Rozważ rozdzielenie obaw przy pisaniu każdego modułu i komponentu
Rozważ architekturę wielowarstwową, aby podzielić system na warstwy
Nie buduj Przeciekających Abstrakcji
Akronimy od tego pokrewnego pytania : Czym są DRY, KISS, SOLID itp.?

— Ben Cottrell
źródło

Czasami wydaje się, że niektórym autorom frameworka nie przeszkadza to, że użytkownicy piszą kod aplikacji w połączeniu z frameworkiem.

— PRZYJEDŹ Z

@COMEFROM - Programiści zachęcają do ścisłego połączenia twojego kodu ze strukturą, ponieważ zakładają, że wybrałeś ich strukturę, aby rozwiązać te same problemy, dla których ją zaprojektowali.

— JeffO

Odszedłeś trochę od tematu, przechodząc od zasad projektowania do zasad kodowania, ale ja mam świadomość tego, co mówisz, a jeśli wymaganiem biznesowym jest zastosowanie pewnych ram? (myśl, że outsourcing firmy i wewnętrzni deweloperzy znają tylko jeden język). Myślę, że powinienem to wyjaśnić w oryginalnym poście.

— Robert Pounder,

@RobertPounder Rzeczywisty punkt, do którego starałem się dojść (być może niezbyt dobrze), polega na tym, że ludzie mają tendencję do wykorzystywania określonych ram jako „podstawy” dla całej aplikacji - co nieuchronnie prowadzi do logiki biznesowej i innych niepowiązany kod jest niewłaściwie połączony z tym frameworkiem - np. logika biznesowa jest połączona z kontrolkami interfejsu użytkownika tylko dlatego, że było to wtedy łatwe i szybkie. Jest to bardzo łatwe, więc należy się wystrzegać

— Ben Cottrell,

Muszę się tutaj nie zgodzić z @nocomprende; nie można przewidzieć wszystkich przyszłych wymagań, ale czasami systemy są przepisywane tylko dlatego, że poprzednie oprogramowanie jest zbyt trudne do rozszerzenia / utrzymania .

— SeldomNeedy

Tak, powinieneś jak najściślej trzymać się tego, co „nakazuje” ci struktura.

Powodem jest po prostu to, że im bardziej trzymasz się ramowego sposobu „myślenia”, tym łatwiej będziesz mógł rozmawiać z innymi programistami o swoich problemach / pomysłach, które również korzystają z tego frameworka.

Zwiększasz interoperacyjność i łatwość użytkowania dla innych osób, które później z niej skorzystają, lepiej zrozumiesz i wprowadzisz samouczki lub popularne rozwiązania, jeśli będziesz trzymał się podstawowej filozofii tego, czego używasz.

Jedynym dobrym powodem, dla którego mogę wymyślić, dlaczego „złamałeś” strukturę, jest to, że absolutnie potrzebujesz czegoś, czego nie może ona zapewnić, biorąc pod uwagę jej „domyślną” konfigurację / stosowanie zasad. Ale z drugiej strony może to nie być właściwe ramy.

Zasadniczo może to dotyczyć również innych decyzji. Należy używać języka używasz tak ściśle, jak to ma być stosowane, ponieważ to sprawia, że rzeczy łatwiej , jeśli mówimy tym samym językiem, jak każdy inny.

— FP
źródło

Być może powinieneś przejrzeć swoją odpowiedź ze względu na zmiany pytania. Twoja odpowiedź w rzeczywistości nie odpowiada na pytanie PO.

— Laiv

@Laiv Nie wiem, jak nie odpowiada na pytanie, choć może nie pasować do twojej opinii na ten temat, to wciąż odpowiedź. Zachęcamy do napisania własnej odpowiedzi w celu wyświetlenia sprzecznego charakteru danego tematu.

— FP

Przepraszam, jeśli sam nie wyjaśniłem dobrze. Nie mówię tak dobrze po angielsku, jak bym chciał. Chciałem tylko powiedzieć, IMO, pytanie i twoja odpowiedź mówią o różnych sprawach. Jeśli uważasz, że nie, to jest w porządku. Nie będę się o to kłócić. to jest to!

— Laiv

To jest absolutnie to. Jest podobny do działania języków specyficznych dla domeny i podobnych pomysłów. Twoje produkty są kształtowane przez narzędzie (Framework), a nie na odwrót. Framework „wygrywa”. Jeśli nie możesz tego poślubić, wybierz inny. (Wskazówka: nie ma idealnego frameworka. Tylko

Twój projekt powinien wpływać na wybrane ramy (jeśli w ogóle!), A nie na odwrót.

— RubberDuck